这个吞吐量比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/