Raft协议是经典的Crash Fault Tolerance共识协议，这个协议为了易于理解性将简化了共识协议的内容，牺牲了协议的性能。Raft协议采取单Leader架构，整体算法的瓶颈在于充当Leader的节点的CPU、内存和带宽。在极限情况下Raft的吞吐量跟常见的其他CFT共识协议（例如Multi-Paxos）不会有太大差距，理论上Multi-Paxos协议的吞吐量会更高一些，但是在工程实践中这种差距几乎感觉不出来。

在极端TPS情况下，采用Leaderless架构的EPaxos、WPaxos协议能做到更高的TPS，但是EPaxos工程实现难度远高于Raft协议，EPaxos协议需要处理复杂的请求之间的依赖关系以实现并行处理请求。在常规分布式系统中，稳定简单的Raft协议完全够用。

在工程实践中，以下因素更能影响协议最后的吞吐量：

  • 网络延迟，RTT（Round Trip Time）：这是大部分共识协议最大的瓶颈。
  • 使用批处理（Batch Processing）：领导者可以将短时间内收到的数百甚至数千个请求打包成一个大的日志条目进行复制，极大地分摊了网络往返的开销。任何生产级的共识实现都会使用批处理。
  • 管道化 (Pipelining)：领导者不需要等待前一个日志项的复制完成，就可以继续发送下一个日志项。这充分利用了网络带宽。
  • 实现质量：选用什么网络通信协议，以及什么序列化和反序列化的手段。

任何一个工业化的软件都实现了以上技巧，来提升整体系统的可用性。