使用 Kafka 处理高并发数据流

  • 孙镜涛

2014 年 11 月 25 日

话题:语言 & 开发架构

如果我们需要持续地处理大约 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 万次请求。这是一个非常酷的项目,所有的事情都优化到了极致,同是我们还使用ElasticSearchKibana实现了实时的分析和图形化。”


感谢崔康对本文的审校。

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

语言 & 开发架构