这家公司的码农有多牛，用C++重写Kafka，还能与其API兼容

国外公司Redpanda实现了对 Kafka 的 C++ 重写，而且提供与Kafka API的100%兼容性。

由于用了C++不再需要Zookeeper和JVM，性能提高了好多倍，且生产操作更加简单。

毕竟Java这个东西做分布式系统，除了容易开发以外，没啥其他优势，C++才是这种需要性能软件的大利器。

Redpanda和Kafka的具体实现上，有两个特别不同的地方。第一个是对内存和文件的管理，第二个区别是Redpanda对replication的处理方式。

01

Redpanda 对文件和内存的管理

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

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

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

这种完全依赖操作系统，和完全自己来的操作理念上的差别，也体现了Java和C++的语言差别。

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

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

02

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做出一个这样的实现来的。

03

Redpanda 的问题

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

当然，也有两个问题。

第一是能够找到合格的C++程序员去实现这种系统级别的软件，那比找同样能力级别的Java 程序员要难很多。

如果出现Bug，调试解决起来也麻烦困难许多。所以：Redpanda的码农水平有这么牛吗？

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

以上已经盘点了Redpanda的技术路线、实现方案以及问题所在，大家觉得Redpanda会占领市场，成为一匹黑马吗？欢迎在评论区讨论。（内容来自“飞总聊IT”）