这个吞吐量比Kafka还高的Confluo是个什么鬼?

伯克利RISE实验室真是个神奇的地方!今年年初的时候RISE实验室推出了据称可以秒杀Redis和Cassandra的键值存储系统

Anna

,十个月之后,又开源了另一个系统——Confluo。官方将Confluo描述为一个用于实时监控和分析数据的系统,并指出了三个主要的应用场景,其中之一就是作为发布和订阅消息系统。

现在市场上有已经有很多消息系统产品,虽然Confluo并非主要作为消息系统而生,但作为一个实时数据分析系统,消息的摄取和消费仍然是一个不可或缺的功能。官方指出,在发布和消费消息方面,Confluo的吞吐量是Kafka的4到10倍。

很自然,肯定会有人提出疑问:

对于这个问题,我们先来看一组Confluo官方提供的吞吐量测试基准:

以上数据来自Confluo官方网站

基准测试使用了单个r3.8xlarge实例、单个主题和单个分区。读取和写入的消息都为64字节,消费者属于不同的消费者群组,也就是说,它们对分区的读取是独立的,不会互相干扰。为了公平起见,让两个系统完全运行在内存上,Kafka的存储也被挂载到了内存盘(RAM Disk)上。

从上图可以看出,不管是写入吞吐量还是读取吞吐量,Confluo都比Kafka高。在使用批次时(16K大小),写入吞吐量是Kafka的4倍,读取吞吐量是Kafka的10倍(图中蓝线是指不使用批次的Kafka,绿线表示不使用批次的Confluo,黄线是使用批次的Kafka,橙线是使用批次的Confluo)。

所以,这组数据就可以回答刚才提出的疑问:它们都使用了闪存盘,但是Confluo的吞吐量仍然比Kafka高。

于是,又有人表示:

现在很多人一提到性能,就把它归结为编程语言问题。因为Java是解释型的,所以在性能方面一定会比C++差。但问题是,如果是在以前,或许可以这么说,但现在的JVM经过无数次的迭代优化,再拿这个说事可就站不住脚了。那么,导致Confluo吞吐量比Kafka高的真正的原因是什么呢?

Confluo官方给出的解释是这样的:

在实现我们的消息系统时,我们借鉴了Kafka的接口和数据模型。Confluo也提供了主题,主题消息保存在很多分片中。每个分片暴露了读写接口,消息发布者将消息批次写入分片,消息订阅者异步从分片上拉取消息批次。与Kafka一样,消息订阅者需要跟踪消息的objectId(类似于偏移量)。与Kafka不一样的地方在于:

1. 不存在读写锁竞争,也不存在写入锁竞争。

2. Confluo提供了一种非常高效的方式来获取整个主题的快照,这点与Kafka非常不同。

3. 除了发布和订阅消息,Confluo还提供了针对消息流的在线和离线查询。

现在再让我们回过头看看之前的测试基准数据。

为了同步并发写入,Kafka使用了锁,所以写入吞吐量受到了写入竞争锁的影响。而Confluo使用了无锁的解决方案,极大提升了吞吐量。在使用批次时,Kafka受锁竞争的影响有所减少,但仍然不足以与无锁的Confluo相媲美,从图中可以看出,Confluo的吞吐量几乎接近了网络饱和。在读取数据时,两个系统都不存在竞争,但因为Kafka在系统开销方面较大,对吞吐量造成一定的影响。从图中可以看出,Confluo的读取吞吐量仍然接近了网络饱和。

综上所述,Confluo的吞吐量比Kafka高,并不是因为使用了更好的硬件,也不是因为编程语言的问题,主要是因为Confluo使用了无锁的并发解决方案。

Confluo:https://ucbrise.github.io/confluo/

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181215G0SJFT00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券