审校 | 重楼
共识是一致性分布式系统的基础。为了在不可避免的崩溃事件中保证系统可用性，系统需要一种方法来确保集群中的每个节点保持一致，以便在发生故障的情况下，工作可以在节点之间无缝切换。Paxos、Raft和View Stamped Replication（VSR）等共识协议通过为领导者选举（leader election）、原子配置更改和同步等流程提供逻辑，帮助提高分布式系统的弹性。
与所有设计要素一样，不同的分布式共识方法具有不同的利弊。Paxos是最古老的共识协议，被用于许多系统，比如Google Cloud Spanner、Apache Cassandra、Amazon DynamoDB和Neo4j。Paxos通过三个阶段、无领导者、多数获胜的协议达成共识。虽然Paxos在力求正确性方面很有效，但理解、实施和推理起来困难重重。这一方面是由于它掩盖了达成共识方面的许多挑战（比如领导者选举和重新配置），使其难以分解成子问题。
Raft（面向可靠、复制、冗余和容错）可以被认为是Paxos的一种进化版，专注于可理解性。Raft可以实现与Paxos相同的正确性，但在现实世界中更容易理解和实施，因此常常可以提供更好的可靠性保证。比如说，Raft使用一种稳定的领导机制，简化了复制日志管理，其领导者选举过程更高效。
图1
又由于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分区处理元数据和集群管理，但复制由代理处理，因此您仍然有这两个不同的平台以及固有的复杂性引起的低效率。
图2
结合Raft与性能工程
正如CockroachDB、MongoDB、Neo4j和TiDB等数据行业领导者所展示的那样，基于Raft的系统提供了一种更简单、更快速和更可靠的分布式数据环境。Raft正成为当今分布式数据系统的标准共识协议，因为它与性能工程结合得特别好，可以进一步提高数据处理的吞吐量。
比如说，Redpanda将Raft与快速架构要素结合在一起，在处理1GBps的工作负载时，在尾部延迟（p99.99）上比Kafka快至少10倍，仅需三分之一的硬件，而不影响数据安全性。传统上，GBps+的工作负载对Apache Kafka来说历来是一大负担，但Redpanda可以以两位数的毫秒延迟支持它们，同时保留Jepsen验证的可靠性。
这是如何实现的呢？Redpanda是用C++编写的，使用每核心线程架构来最大限度地发挥现代芯片和网卡的性能。这些要素共同提升了Raft对于分布式流数据平台的价值。
图3
比如说，由于Redpanda绕过了Kafka的页面缓存和Java虚拟机（JVM）依赖，它可以将硬件级知识嵌入到Raft实现中。每次您在Raft中写入数据时，通常都必须刷新，以保证磁盘上写入内容的持久性。在Redpanda乐观的Raft方法中，较小的间歇刷新被丢弃，改为调用结束时进行较大的刷新。虽然这在每次调用时引入了一些额外的延迟，但减少了总体系统延迟，并增加了总体吞吐量，因为它减少了刷新操作总数。
虽然有许多有效的方法来确保分布式系统的一致性和安全性（区块链用工作量证明和权益证明协议做得很好），但Raft是一种经过验证的方法，足够灵活，可以像Redpanda一样进行改进，以适应新挑战。随着我们进入到一个数据驱动的新世界——这一方面受人工智能和机器学习用例的驱动，未来掌握在能够利用实时数据流的开发人员手中。
基于Raft的系统以及C++和每核心线程架构之类的性能工程要素，正在推动数据流在未来的关键任务应用程序中派上大用场。
原文Why Raft-native systems are the future of streaming data，作者：Doug Flora
