目前来看，底层深究越来越被弱化。去底层化、简单化是各DB厂商、云服务厂商的发展方向。
来自豆包
Paxos和Raft都是常见的分布式一致性协议。它们的部分区别和优缺点如下：
- 区别：
- 角色：Paxos没有明确的领导者角色，而Raft协议中有一个明确的领导者，负责处理客户端请求和协调一致性。
- 复杂度：Paxos协议比较复杂，理解和实现难度较高；Raft协议相对简单，更容易理解和实现。
- 优缺点：
- Paxos适用于需要高度一致性和容错性的场景，如[分布式数据库、分布式文件系统等。
- Raft适用于需要简单、高效的一致性协议的场景，如云计算、区块链等。
Paxos 和 Raft 协议在实际应用中的性能会受到多种因素的影响，包括网络延迟、节点数量、数据传输量、计算复杂度等。因此，无法简单地给出一个一般性的性能比较。
一般来说，Raft 协议相对于 Paxos 协议在一些方面可能具有更好的性能，原因如下：
- 简单性：Raft 协议的设计相对简单，更容易理解和实现。这有助于减少错误和提高性能。
- 领导者选举：Raft 协议通过明确的领导者选举机制来提高效率和性能。领导者负责处理客户端请求，减少了协调和通信开销。
- 可理解性：Raft 协议的概念和原理相对容易理解，使得开发和维护更加容易。
然而，性能评估还需要考虑具体的应用场景和系统需求。在一些情况下，Paxos 协议可能更适合，例如在对容错性和一致性要求极高的场景中。
要准确评估 Paxos 和 Raft 协议的性能，需要在具体的环境中进行测试和分析。这包括考虑网络拓扑结构、节点性能、数据分布等因素，并根据实际需求进行优化和调整。
无论选择哪种协议，都需要仔细考虑系统的要求、性能权衡和可扩展性等因素，并进行适当的性能测试和优化来满足具体应用的需求。
Paxos是一致性协议的鼻祖，Raft是从Paxos衍生出来的更工程化的算法。Paxos是爸爸，Raft是儿子。
2 个赞
后发优势
1 个赞
欢迎来论坛发帖，常来啊~
在原生分布式数据库中，数据的多个副本采用一致性协议实现同步，其中OceanBase（简称OB）采用了Paxos协议，TiDB和Cockroachdb（简称CRDB）采用了Raft协议。
其实，到今天我们还去研究原生Raft和Paxos有什么区别，哪个协议更好时已经没有什么意义了…
虽然两种协议在原生定义中实现方式有很大不同，但是分布式数据库要确保副本数据一致性和性能体验的目标是一致的，所以经过厂商一系列工程实现，两者在产品中都有比较趋同的表现效果（所以我们应该关注的应该是采用这些协议的产品在应用这些协议时有什么不同的表现！），大部分功能都已经一样，展现出来的已经没什么差异了。
但Paxos和Raft协议的应用效果上还有一个很大的不同点，就是对并发事务的支持上：
1）Raft的实现流程比较简单，因此为了保证一致性，日志复制的过程是严格按照log-index顺序执行的。
即同一个Raft-group（region）内部如果有多个并发事务修改数据，那么这些数据在多个副本之间同步日志时是串行进行的，所以这样的并发事务如果很多，那么就会产生很大的性能阻碍；
所以，我们看到用Raft协议的数据库，数据都是按range（范围）进行切片的（另外也支持hash切分，其实hash也是一样的，把数据划分到不同的hash桶以后，每个桶内还是会按range再次切分）。
Range切分的原理就是对数据以主键进行排序，然后尽量切分成大小均匀的多个切片（切片的大小可以通过参数控制）。
每个切片的多个副本之间构成一个Raft-group，如此就把大量数据尽可能分割成更多细小的切片，通过增加Raft-group的数量来提高并行事务的支持能力。
通过对Raft这一特性的了解，我们在日常应用的时候，如果发现性能问题是region（分片）内部并发事务出现了瓶颈，那么就可以把region切的更小，以尝试解决这个问题。这就是DBA/运维人员学习理论知识的价值。
小强（crdb）有一个自动优化的功能：当某个region的qps（每秒访问量）达到2500次以后就会自动切分成多个region，tidb也有类似自动优化机制。
所以，当你听到某个分布式数据库使用Raft机制时，那么你应该能基本确认它是按range切分数据的，这也算是应用Raft协议的无奈之举，但这并非全是坏处。
2）Paxos内部是允许日志乱序同步的，所以能够支持并行事务。
例如ob即便用partition切分数据，每个分区切片的数据量可能很大，并发事务的日志复制一般也不会成为瓶颈。所以Paxos相比Raft，确实在某些场景中能够提升性能；
但这也不能说明Paxos就完全优于Raft，Raft逻辑简单、工程实现方便，研发掌握也能轻松，这样研发人员对产品的可控能力就更强。
另外在分布式系统中，切片是物理分割的最小单位，一个切片必然只能存储在一个节点上。数据库在进行存储均衡、扩缩容时，都是以切片为最小单位进行移动数据的，所以按range切分的数据库，其切片会更细小，也就意味着存储会更均衡、不容易发生数据倾斜，扩缩容时数据迁移能够更方便；
另外切片越小，越方便缩小热点数据的范围，方便将热点数据再次打散、迁移；而这些特性是基于partition切分数据所无法实现的。
同时，基于range切分数据，无论一张表中的数据量增长到如何程度，最终它都会切分成指定大小的众多切片，均匀分散在集群中，所以理论上这样的系统对单表数据容量是没有限制的，性能和容量不足时，增加服务器节点数量就可以了。而基于partition进行分布，那么显然单个partition的数据量是有限制的；如果数据量很大时，那么开发、运维人员就必须既掌握业务数据特性，又要理解分布式数据库部署架构，才能设计出合理的partition规则，实现存储均匀和消除可能的数据热点。
总结一下，Paxos（OB）因为支持单分片内事务日志并发同步，所以性能更好一些。Raft（crdb/tidb）因为将数据切分的更细小，从而能够使存储更均衡、能提供数据库内部自动优化机制（热点数据处理）、能存储更大的数据量。
所以，从一致性协议角度分析，如果对开发、运维人员能力比较自信，并且追求极致性能，可以选择OB；如果业务数据量较大，且运维开发精力有限，那么选择应用Raft的产品（tidb/crdb…）就没错了。
（以上大部分内容转自公众号：天下观查）
1 个赞
这块有点复杂，是paxos 工程实现不太容易的，所以出现raft ，共识算法可以系统看一下，
水一下 
可以看看这个科普。
也可以看看这个论文的原文：
https://dl.acm.org/doi/pdf/10.1145/3380787.3393681
paxos总是说自己的日志不怕乱序提交。而raft依赖网络不抖动以保证日志的顺序提交。
可问题是，大部分分布式系统在工程要求上，需要工作在抖动如此严重的网络状态下嘛？
如果答案是否定的，就等于在paxos协议下，每一次日志提交都有额外的计算量以保证乱序提交的正确性。显而易见的是，支持乱序提交不可能没有任何额外的代价。仅在网络严重抖动的环境下，paxos才会胜出raft。
从某种程度上，我觉得这就是越来越多的工程开始选择raft协议的原因。
学习了，两者区别之一还有一个是选主的机制，raft更简单高效一些。但是实际在各自产品中应用时，都会对这些算法进行改进，导致两者没什么大的区别。
但是你说的这个“仅在网络严重抖动的环境下，paxos才会胜出raft”，我理解似乎并不准确。
假设网络都是健康的，并且同时发生了10个并发事务同时修改不同行数据，但这些数据都在同一个raft-group/paxos-group内。
raft在底层数据复制时，单个事务一行数据复制时间为8，paxos因为多了协议，所以单行数据复制用时 10；
但是raft 10个事务的数据，是串行复制的，那在raft层最短时间也需要：8*10=80；
如果paxos10个事务的数据，是并行复制的，那在paxos层时间最短可能其中复制时间最长的那个数据的时间，可能就10几而言；
…
1 个赞
受教了。找了些资料，确实如此，甚至是pingcap员工写的这块介绍。 
当事人发言
可以研究一下源码，最终结果都是保持一致性
原来两个分布式协议，还有这么多差异，原本以为，都差不多呢
1 个赞
长见识了