Redpanda：用C++重写的Kafka到底有多牛逼。。。

本文首发微信公众号：飞总聊IT

今天聊聊我最近看到的一个东西：Redpanda。这家公司用C++重写实现了一下Kafka，做到了API的兼容。

所以Kafka社区的各种生态理论上来说雨刮可以无缝的对接到Redpanda里面来。

软件属于社区版开源在GitHub上，但是很多高级功能则需要去买付费的企业版。有点类似Kafka和Confluent的企业版之间的区别。

下面的讨论涉及到Kafka的一些知识，我就假设各位多多少少懂这些基础知识了。不然的话解释起来比较麻烦。

Redpanda的C++实现，按照它们官网的说法，由于用了C++避免了JVM，以及其他一堆的优化，性能提高了好多倍。

这话我是相信的。毕竟Java这个东西做分布式系统，除了容易开发以外，好处少少。C++才是这种需要性能的软件的大利器。

只不过C++双刃刀，找到合适的开发人员的难度比Java大多了。万一软件有Bug，调试起来的难度也大很多。

撇开这些东西不讲，Redpanda和Kafka的具体实现上，有两个特别不同的地方。

第一个是对内存和文件的管理。Kafka特别强调了，它的设计都是尽最大系统的利用系统对文件的缓存，从而来提高系统的效率。包括使用Linux系统特定的API来操作文件等等。

而Redpanda的做法正好相反，Redpanda启动的时候就会分配走机器的绝大多数的内存，然后自己去管理这些内存的使用。

同时Redpanda对文件系统的操作也完全回避掉所有的系统缓存，而是自己来处理如何进行磁盘操作。资源的分配和隔离也完全通过Cgroup来管理。

这种完全依赖操作系统，和完全自己来的操作理念上的差别，也体现了Java和C++的语言差别。C++具备了这种完全不依赖系统自己进行操作和管理的能力，而Java想做到这种精细的操控是很难的。还不如最大限度的依赖系统。

如果操作得好，C++的应用是可以做得比操作系统的管理更高效率。很多商业化的数据库系统，都是自己管理内存和磁盘文件的。

第二个区别是Redpanda对replication的处理方式。在今天的Kafka里，我们要么选择ZooKeeper来维护metadata要么通过KRaft来维护metadata。

如果说metadata用了Zookeeper的话，Data的replication依赖follower去pull leader。实际上这种实现是Kafka里面最糟糕的地方之一。Data需要通过follower显式的pull leader产生了各种各样的问题，这些问题非常的不好解决。比如说这个著名的KIP501：Avoid out-of-sync or offline partitions when follower fetch requests are not processed in time

链接如下：

https://cwiki.apache.org/confluence/display/KAFKA/KIP-501+Avoid+out-of-sync+or+offline+partitions+when+follower+fetch+requests+are+not+processed+in+time

这个问题就是天然的系统设计的问题导致怎么修都不能从根本上解决问题的尴尬局面。链接里面有一些深度的讨论，背后的原因，我就不展开讲了。

Redpanda对replication的处理就很简单了，data放在不同的Raft Group里面，Raft Group自己就能够实现对leader的自动维护，和数据在这个group之间的复制。

有人会问，Kafka不知道这样做更好吗？当然，这样做肯定更好，毕竟很多大厂的系统都是这样做的。但是同样的实现起来也更难啊。

又有人会问Kafka不也实现了KRaft了吗？只不过很抱歉此Raft非彼Raft。KRaft只是一个非常轻量级的服务，它的目标就是取代ZooKeeper去管理metadata，比如说现在谁是leader谁是follower这样的信息。

它并没有去取代系统现有的Leader/Follower之间数据怎么复制的这个实现。后者取代起来，对Raft的实现上的效率要求就比较高了。我其实挺怀疑Confluent能不能基于Java做出一个这样的实现来的。

所以，单纯的从技术角度来看，我觉得Redpanda确实是解决了Kafka长久以来的一些架构上的弊端，实现有其非常可取的地方。如果C++的实现够可靠的话，又能兼容Kafka的API，不失为一个有竞争力的产品。

当然，问题来了。问题有两个。第一是能够找到合格的C++程序员去实现这种系统级别的软件，那比找同样的Java 程序员要难很多。如果有Bug，调试解决起来也难度大很多。这很取决于Redpanda的码农水平到底多牛逼。

第二是类似MapR的文件系统和HDFS的区别，一个系统要对另外一个系统保持API兼容，而另外一个系统自己又是在不断发展的，这种兼容性的维系，是需要付出很大代价的。

但是不管怎么样，从我个人角度来看，Redpanda的技术路线和实现方案，的的确确是有其竞争力的。

也顺便聊几句写技术文章的事情吧。有人催我多写技术文章，少瞎逼逼。说真的，我是挺喜欢写技术文章，也挺爱研究各种新技术新东西的。但是现在工作忙了，自己花时间学习新东西的时间少了。所以我写的也就少了。

还有一个因素，我的技术文章阅读量和其他文章比起来，少很多。所以每次我兴高采烈写了一篇，就被打击了，一段时间就没什么动力写第二篇了，需要很长时间恢复。

所以，喜欢我的技术文的粉丝，大家努力多读读，让我技术文阅读量没那么难看，给我多点写的动力吧。