为什么说 Raft 原生系统是流式数据的未来？

一、前言

共识是一致性分布式系统的基础。为了在不可避免的崩溃事件中保证系统可用性，系统需要一种方法来确保集群中的每个节点保持一致，以便在发生故障的情况下，工作可以在节点之间无缝切换。Paxos、Raft 和 View Stamped Replication（VSR）等共识协议通过为领导者选举（leader election）、原子配置更改和同步等流程提供逻辑，帮助提高分布式系统的弹性。

与所有设计要素一样，不同的分布式共识方法具有不同的利弊。Paxos 是最古老的共识协议，被用于许多系统，比如 Google Cloud Spanner、Apache Cassandra、Amazon DynamoDB 和 Neo4j。Paxos 通过三个阶段、无领导者、多数获胜的协议达成共识。虽然 Paxos 在力求正确性方面很有效，但理解、实施和推理起来困难重重。这一方面是由于它掩盖了达成共识方面的许多挑战（比如领导者选举和重新配置），使其难以分解成子问题。

Raft（面向可靠、复制、冗余和容错）可以被认为是 Paxos 的一种进化版，专注于可理解性。Raft 可以实现与 Paxos 相同的正确性，但在现实世界中更容易理解和实施，因此常常可以提供更好的可靠性保证。比如说，Raft 使用一种稳定的领导机制，简化了复制日志管理，其领导者选举过程更高效。

又由于 Raft 分解了共识问题的不同逻辑组件，比如通过使领导者选举成为复制之前的一个不同步骤，因此它是一种灵活的协议，可以适应复杂的现代分布式系统，这类系统需要在扩展到 PB 级吞吐量的同时保持正确性和性能，对于处理代码库的新工程师来说又更容易理解。

由于这些原因，Raft 已被迅速采用于今天的分布式云原生系统，比如 MongoDB、CockroachDB、TiDB 和 Redpanda，以实现更高的性能和事务效率。

二、Redpanda 是如何实施 Raft 的？

当 Redpanda 的创始人 Alex Gallego 认为世界需要一种新的流数据平台来支持导致 Apache Kafka 崩溃的 GBps+工作负载时，他决定从头开始重写 Kafka。

Redpanda 的需求是：

1）需要简单、轻量级，以减少大规模可靠运行 Kafka 集群的复杂性和低效率；

2）需要最大限度地提高现代硬件的性能，以便为大型工作负载提供低延迟；

3）即使对于非常大的吞吐量，也需要保证数据安全性。

实施 Raft 为这三个需求提供了坚实的基础：

1. 简单性。每个 Redpanda 分区都是一个 Raft 组，所以平台上的所有东西都围绕 Raft 进行推理，包括元数据管理和分区复制。这与 Kafka 的复杂性形成对比：在 Kafka 中，数据复制由 ISR（同步副本）处理，元数据管理由 ZooKeeper（或 Kraft）处理，您有两个必须相互推理的系统。

2. 性能。Redpanda Raft 实现可以容忍对少数副本的干扰，只要领导者和大多数副本是稳定的。在少数副本出现延迟响应的情况下，领导者不必等待它们响应即可进行下一步，从而减轻了对延迟的影响。因此，Redpanda 具有更高的容错性，可以在大规模环境下提供可预测的性能。

3. 可靠性。当 Redpanda 摄取事件时，它们被写入到主题分区，并附加到磁盘上的日志文件中。然后，每个主题分区形成一个 Raft 共识组，由领导者和许多追随者组成，由主题的复制因子指定。如果有 2f +1 个节点，Redpanda Raft 组可以容忍 f 次故障；比如在有五个节点的集群和复制因子为 5 的主题中，两个节点可能失效，而主题将保持运行。Redpanda 利用 Raft 联合共识协议，即使在重新配置期间也能提供一致性。

Redpanda 还在一些关键方面扩展了 Raft 的核心功能，以实现现代云原生解决方案所需的可扩展性、可靠性和速度。基于 Raft 的创新包括对选举过程所做的更改、心跳生成以及对 Apache Kafka ACKS 的重要支持。这些创新确保了在所有场景下有最佳性能，这使得 Redpanda 在保证数据安全的同时能够比 Kafka 快得多。实际上，Jepsen 测试已经证实 Redpanda 是一个安全的系统，没有已知的一致性问题，是可靠的基于 Raft 的共识层。

三、但是 Kraft 又如何呢？

虽然 Redpanda 采用了 Raft 原生方法，但传统的流媒体数据平台在采用现代共识方法方面一直落后。Kafka 本身是一个复制的分布式日志，但它过去依赖另一个复制的分布式日志：Apache Zookeeper 进行元数据管理和控制器选举。这是有问题的，原因如下：

1. 管理多个系统带来了管理负担；

2. 由于低效率的元数据处理和双重缓存，可扩展性受到限制；

3. 集群可能变得非常臃肿和资源密集；实际上，ZooKeeper 和 Kafka 节点数量相等的集群并不罕见。

这些限制并没有被 Apache Kafka 的提交者和维护者所忽视，他们正在用一种自我管理的元数据仲裁：Kafka Raft（KRaft）来取代 ZooKeeper。这种基于事件的 Raft 减少了 Kafka 元数据管理的管理挑战，有望表明 Kafka 生态系统正朝着现代共识和可靠性方法的方向发展。

遗憾的是，Kraft 并没有解决 Kafka 集群中有两个不同的共识系统这一问题。在新的 KRaft 范例中，KRaft 分区处理元数据和集群管理，但复制由代理处理，因此您仍然有这两个不同的平台以及固有的复杂性引起的低效率。

四、结合 Raft 与性能工程

正如 CockroachDB、MongoDB、Neo4j 和 TiDB 等数据行业领导者所展示的那样，基于 Raft 的系统提供了一种更简单、更快速和更可靠的分布式数据环境。Raft 正成为当今分布式数据系统的标准共识协议，因为它与性能工程结合得特别好，可以进一步提高数据处理的吞吐量。

比如说，Redpanda 将 Raft 与快速架构要素结合在一起，在处理 1GBps 的工作负载时，在尾部延迟（p99.99）上比 Kafka 快至少 10 倍，仅需三分之一的硬件，而不影响数据安全性。传统上，GBps+的工作负载对 Apache Kafka 来说历来是一大负担，但 Redpanda 可以以两位数的毫秒延迟支持它们，同时保留 Jepsen 验证的可靠性。

这是如何实现的呢？Redpanda 是用 C++编写的，使用每核心线程架构来最大限度地发挥现代芯片和网卡的性能。这些要素共同提升了 Raft 对于分布式流数据平台的价值。

比如说，由于 Redpanda 绕过了 Kafka 的页面缓存和 Java 虚拟机（JVM）依赖，它可以将硬件级知识嵌入到 Raft 实现中。每次您在 Raft 中写入数据时，通常都必须刷新，以保证磁盘上写入内容的持久性。在 Redpanda 乐观的 Raft 方法中，较小的间歇刷新被丢弃，改为调用结束时进行较大的刷新。虽然这在每次调用时引入了一些额外的延迟，但减少了总体系统延迟，并增加了总体吞吐量，因为它减少了刷新操作总数。

虽然有许多有效的方法来确保分布式系统的一致性和安全性（区块链用工作量证明和权益证明协议做得很好），但 Raft 是一种经过验证的方法，足够灵活，可以像 Redpanda 一样进行改进，以适应新挑战。随着我们进入到一个数据驱动的新世界——这一方面受人工智能和机器学习用例的驱动，未来掌握在能够利用实时数据流的开发人员手中。

基于 Raft 的系统以及 C++和每核心线程架构之类的性能工程要素，正在推动数据流在未来的关键任务应用程序中派上大用场。