使用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实现了实时的分析和图形化。”