使用 Kafka 处理高并发数据流

如果我们需要持续地处理大约 20 万条 / 秒的消息量，同时还需要保证数据的可用性和冗余，我们应该怎么做呢？最近 Tadas Vilkeliskis 在自己的博客上发表了一篇题为《数据流基础设施》的文章，分享了他们是如何应对这种场景的。

Tadas Vilkeliskis 在文章中提到，他们每秒钟大约会收到来自于世界各地的 20 万次 HTTP 请求，这些请求包含了用户的行为信息，平均每一条消息的大小约为 0.8KB，每秒钟的总数量在 150MB 左右。为了应对如此高的流量，Tadas Vilkeliskis 说他们的方案是 Kafka ：将这些 HTTP 请求当成一个事件流，先把接收到的所有请求都推动到 Kafka 消息队列中，然后再依次进行处理。其中，事件流中的所有请求都可以包含一些会随时间变化的信息，而 Kafka 消息队列的作用则是保证请求的顺序以及数据的持久化和复制。

之所以会选择 Kafka，Tadas Vilkeliskis 认为：

“RabbitMQ 和 ZeroMQ 这样的消息系统要么没有如此高的写能力，要么需要牺牲持久性以便获得更好的写性能。数据库也有类似的限制，它们通常都针对特定场景做了优化，但是这样在其他的场景下就难有良好的表现。”

Tadas Vilkeliskis 的话可能比较模糊，对于 Kafka 与其他的消息队列系统之间的比较，InfoQ 之前也曾发布过一篇文章《 Apache Kafka：下一代分布式消息系统》，其中就从生产和消费两个方面对 Kafka、Apache ActiveMQ V5.4 和 RabbitMQ V2.4 的性能做了比较，结果是 Kafka 遥遥领先，或许这才是支撑 Tadas Vilkeliskis 使用 Kafka 的原因。

另外，Tadas Vilkeliskis 还在这篇文章中分享了 Kafka 的数据分发机制，磁盘存储空间的分配、消息格式的处理、服务器选择以及数据压缩等方面的内容，感兴趣的读者可以阅读英文原文。

对于 Tadas Vilkeliskis 分享的方案，也有部分用户提出了自己的想法，Ryan 回复说：

“这些都是不错的性能数据。在 VoltDB ，我们发现有很多人在应对这种速度时会把数据从 Kafka 转移到 VoltDB 上。VoltDB 能够处理这种速率的流量，同时能够使用内置的输出特性将其推动到下游系统。它可以在 Kafka 和最终的仓库磁盘之间增加实时的数据抽取、转换、加载、过滤、决策和分析的阶段。”

Tristan Turêves 回复说：

“这是为了处理实时竞价（RTB）么？我也做了相似的事情，但是使用了完全不同的技术。我们的架构是基于 NodeJS 的，这种情况下我们清楚地知道请求来源于哪个地理位置。我们租用了高性能的专用服务器（最少 8 核，有充足的 RAM），有一个本地 node 集群监听“内核数量”的端口。然后在这之上有一个 HAProxy 负责同一台机器端口间的负载均衡。在保持平均响应时间为 1 秒的情况下，我们的每一台主机每秒钟大约能够处理 14 万次请求。这是一个非常酷的项目，所有的事情都优化到了极致，同是我们还使用 ElasticSearch 和 Kibana 实现了实时的分析和图形化。”

感谢崔康对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。