在散布式体系中不行避免的会遇到网络毛病，机器宕机，磁盘损坏等问题，为了向用户不中止且正确的供给服务，要求体系有必定的冗余与容错才干。RocketMQ 在日志，统计剖析，在线买卖，金融买卖等丰厚的出产场景中发挥着至关重要的效果，而不同环境对基础设施的本钱与牢靠性提出了不同的诉求。在 RocketMQ v4 版别中有两种干流高可用规划，别离是主备办法的无切换架构和依据 Raft 的多副本架构（图中左边和右侧所示）。出产实践中咱们发现，两副本的冷备办法下依据大都派的供认机制在扩展只读副本时不行灵敏，无法很好的支撑两机房对等布置，异地多中心等杂乱场景。RocketMQ v5 版别交融了上述计划的优势，提出 DLedger Controller 作为管控节点（中心部分所示），将推举逻辑插件化并优化了数据仿制的完结。
在 Primary-Backup 架构的散布式体系中，一份数据将被仿制成多个副原本避免数据丢掉。处理相同数据的一组节点被称为副本组（ReplicaSet），副本组的粒度可所以单个文件等级的（例如 HDFS），也可所以分区级 / 行列级的（例如 Kafka），每个实在存储节点上能够包容若干个不同副本组的副本，也能够像 RocketMQ 相同粗粒度的独占节点。独占能够明显简化数据写入时确保耐久化成功的杂乱度，因为每个副本组上只需主副本会呼应读写恳求，备机一般装备只读来供给均衡读负载，推举这件事儿等价于让副本组内一个副本持有独占的写锁。
一个副本组内，节点间同享数据的办法有多种，资源的同享程度由低到高来说一般有 Shared Nothing，Shared Disk，Shared Memory，Shared EveryThing。典型的 Shared Nothing 架构是 TiDB 这类纯散布式的数据库，TiDB 在每个存储节点上运用依据 RocksDB 封装的 TiKV 进行数据存储，上层经过协议交互完结事务或许 MVCC。比较于传统的分库分表战略来说，TiKV 易用性和灵敏程度很高，更简略处理数据热门与弹性时数据打散的一系列问题，但完结跨多节点的事务就需求涉及到屡次网络的通讯。另一端 Shared EveryThing 的事例是 AWS 的 Aurora，Aliyun 的 PolarStore，旁路 Kernal 的办法使运用彻底运转于用户态，以最大程度的存储复用来削减资源耗费，一主多备彻底共用一份底层牢靠的存储，完结一写多读，快速切换。
大大都 KV 操作都是经过要害字的共同性哈希来核算所分配的节点，当这个节点地点的主副本组产生存储颤动，主备切换，网络分区等状况下，这个分片所对应的一切键都无法更新，部分会有一些操作失利。音讯体系的模型有所不同，流量大但跨副本组的数据交互很少，无序音讯发送到预期分区失利时还能够向其他副本组（分片）写入，一个副本组的毛病不影响大局，这在全体服务的层面上额定供给了跨副本组的可用性。此外，考虑到 MQ 作为 Paas 层产品，被广泛布置于 Windows，Linux on Arm 等各种环境，只需削减和 Iaas 层产品的深度绑定，才干供给更好的灵敏性。这种部分毛病阻隔和轻依靠的特性是 RocketMQ 选则 Shared Nothing 模型重要原因。
副本组中，各个节点处理的速度不同，也就有了日志水位的概念。Master 和与其距离不大的 Slave 一起组成了同步副本集（SyncStateSet）。怎么界说距离不大呢？衡量的方针可所以日志水位（文件巨细）距离较小，也可所以备落后的时刻在必定范围内。在主宕机时，同步副本会集的其他节点有时机被提高为主，有时需求对体系进行容灾演练，或许对某些机器进行保护或灰度晋级时期望定向的切换某一个副本成为新主，这又产生了优先副本（PriorityReplica）的概念。挑选优先副本的准则和战略许多，能够动态挑选水位最高，参加时刻最久或 CommitLog 最长的副本，也能够支撑机架，可用区优先这类静态战略。
从模型的视点来看，RocketMQ 单节点上 Topic 数量较多，假定像 kafka 以 topic / partition 粒度保护状况机，节点宕时机导致上万个状况机切换，这种惊群效应会带来许多潜在危险，因而 v4 版别时 RocketMQ 挑选以单个 Broker 作为切换的最小粒度来办理，比较于其他更细粒度的完结，副自身份切换时只需求重分配 Broker 编号，对元数据节点压力最小。因为通讯的数据量少，能够加速主备切换的速度，单个副本下线的影响被约束在副本组内，削减办理和运维本钱。这种完结也一些缺陷，例如存储节点的负载无法以最佳状况在集群上进行负载均衡，Topic 与存储节点自身的耦合度较高，水平扩展一般会改动分区总数，这就需求在上层附加额定的处理逻辑。
RTO（Recovery Time Objective）康复时刻方针，一般表明事务中止到康复的时刻。
RPO（Recovery Point Object）康复点方针，用于衡量事务连续性。例如某个硬盘每天备份，毛病时丢掉最近备份后的一切更新。
SLA（Service-Level Agreement）服务等级协议，厂商以合约的办法对用户进行服务质量许诺，SLA 越高一般本钱也越高。
节点数量与牢靠性关系密切，依据不同出产场景，RocketMQ 的一个副本组或许会有 1，2，3，5 个副本。
1.单副本本钱最低，保护最简略，宕机时其他副本组接纳新音讯的写入，但已写入的数据无法读取，形成部分音讯消费推延。底层硬件毛病还或许导致数据永久丢掉，一般用于非要害日志，数据收集等低牢靠性本钱诉求较强的场景。
2.两副本较好的权衡了数据冗余的本钱与功能，RocketMQ 跨副本组容灾的特性使得两副本办法适用于绝大部分 IOPS 比较高的场景。此刻备机能够分摊必定的读压力（尤其是主副本因为内存严峻或许产生冷读时）。两副本因为不满意大都派（quorum）准则，没有外部体系的参加时，毛病时无法进行推举切换。
3.三副本和五副本是业界运用最为广泛的，精心规划的算法使得大都状况下体系能够自愈。依据 Paxos / Raft 归于献身高可用性来确保共同性的 CP 型规划，存储本钱很高，简略遭到 IO 散布不均匀和水桶效应的影响。每条数据都需求半数以上副本呼应的规划在需求写透（write through）多副本的音讯场景下不行灵敏。
怎么确保副本组中数据的终究共同性？那肯定是经过数据仿制的办法完结，咱们该挑选逻辑仿制仍是物理仿制呢？
逻辑仿制：运用音讯来进行同步的场景也许多，各种 connector 完本钱质上便是把音讯从一个体系挪到别的一个体系上，例如将数据导入导出到 ES，Flink 这样的体系上进行剖析，依据事务需求挑选特定 Topic / Tag 进行同步，灵敏程度和可扩展性十分高。这种计划跟着 Topic 增多，体系还会有服务发现，位点和心跳办理等上层完结形成的功能丢掉。因而关于音讯同步的场景，RocketMQ 也支撑以音讯路由的办法进行数据搬运，将音讯仿制作为事务消费的特例来看待。
物理仿制：大名鼎鼎的 MySQL 关于操作会记载逻辑日志（bin log）和重做日志（redo log）两种日志。其间 bin log 记载了句子的原始逻辑，比方修正某一行某个字段，redo log 归于物理日志，记载了哪个表空间哪个数据页改了什么。在 RocketMQ 的场景下，存储层的 CommitLog 经过链表和内核的 MappedFile 机制笼统出一条 append only 的数据流。主副本将未提交的音讯按序传输给其他副本（相当于 redo log），并依据必定规矩核算供认位点（confirm offset）判别日志流是否被提交。这种计划仅运用一份日志和位点就能够确保主备之间预写日志的共同性，简化仿制完结的一起也提高了功能。
为了可用性而规划的多副本结构，很明显是需求对一切需求耐久化的数据进行仿制的，挑选物理仿制愈加节约资源。RocketMQ 在物理仿制时又是怎么确保数据的终究共同性呢？这就涉及到数据的水位对齐。关于音讯和流这样近似 FIFO 的体系来说，越近期的音讯价值越高，音讯体系的副本组的单个节点不会像数据库体系相同，保存这个副本的全量数据，Broker 一方面不断的将冷数据规整并转入低频介质来节约本钱，一起对热数据盘上的数据也会由远及近滚动删除。假定副本组中有副本宕机较久，或许在备份重建等场景下就会呈现日志流的不对齐和分叉的杂乱状况。鄙人图中咱们将主节点的 CommitLog 的首尾位点作为参阅点，这样就能够划分出三个区间。鄙人图中以蓝色箭头表明。排列组合一下就能够证明备机此刻的 CommitLog 必定满意下列 6 种状况之一。
1-1 状况下满意备 Max = 主 Min，一般是备新上线或下线较久，备越过存量日志，从主的 Min 开端仿制。
1-2，2-2 两种状况下满意 主 Min 备 Max = 主 Max，一般是因为备网络闪断导致日志水位落后，经过 HA 衔接跟随主即可。
1-3，2-3 两种状况下备 Max 主 Max，或许因为主异步写磁盘宕机后又成为主，或许网络分区时双主写入形成 CommitLog 分叉。因为新主落后于备，少数未供认的音讯丢掉，非正常办法的推举（RocketMQ 将这种状况称为 unclean 推举）是应该尽量避免的。
3-3 理论上不会呈现，备的数据善于主，原因或许是主节点数据丢掉又叠加了非正常推举，因而这种状况需求人工介入处理。
前文说到 RocketMQ 每个副本组的主副本才承受外部写恳求，节点的身份又是怎么决议的呢？
散布式体系一般分为中心化架构和去中心化架构。关于 MultiRaft，每个副本组包含三个或许五个副本，副本组内能够经过 Paxos / Raft 这样的共同协议来进行选主。典型的中心化架构，为了节约数据面资源本钱会布置两副本，此刻依靠于外部 ZK，ETCD，或许 DLedger Controller 这样的组件作为中心节点进行推举。由外置组件判决成员身份涉及到散布式中两个重要的问题：1. 怎么判别节点的状况是否正常。2. 怎么避免双主问题。
关于第一个问题，kubernetes 的处理计划相对高雅，k8s 对与 Pod 的健康检查包含存活检测（Liveness probes）和安排妥当检测（Readiness probes），Liveness probes 主要是勘探运用是否还活着，失利时重启 Pod。Readiness probes 来判别勘探运用是否承受流量。简略的心跳机制一般只能完结存活检测，来看一个比方：假定有副本组中有 A、B、C 三个副本，还有一个节点 Q（岗兵） 担任观测节点状况，一起承当了大局推举与状况保护的责任。节点 A、B、C 周期性的向 Q 发送心跳，假定 Q 超越一段时刻（一般是两个心跳距离 ）收不到某个节点的心跳则以为这个节点反常。假定反常的是主副本，Q 将副本组的其他副本提高为主并播送奉告其他副本。
在工程实践中，节点下线的或许性一般要小于网络颤动的或许性。咱们假定节点 A 是副本组的主，节点 Q 与节点 A 之间的网络中止。节点 Q 以为 A 反常。从头挑选节点 B 作为新的 Master，并告诉节点 A、B、C 新的 Master 是节点 B。节点 A 自身作业正常，与节点 B、C 之间的网络也正常。因为节点 Q 的告诉事情抵达节点 A、B、C 的次序是不知道的，假定先到达 B，在这一时刻，体系中一起存在两个作业的主，一个是 A，另一个是 B。假定此刻 A、B 都接纳外部恳求并与 C 同步数据，会产生严峻的数据过错。上述 双主 问题呈现的原因在于尽管节点 Q 以为节点 A 反常，但节点 A 自己不以为自己反常，在旧主新主都承受写入的时分就产生了日志流的分叉，其问题的实质是因为网络分区形成的体系关于节点状况没有达到共同。
租约是一种避免双主的有用手法，租约的典型意义是现在中心节点供认哪个节点为主，并答应节点在租约有用期内正常作业。假定节点 Q 期望切换新的主，只需等候前一个主的租约过期，则就能够安全的颁布新租约给新 Master 节点，而不会呈现双主问题。这种状况下体系对 Q 自身的可用性诉求十分高，或许会成为集群的功能瓶颈。出产中运用租约还有许多完结细节，例如依靠时钟同步需求颁布者的有用期设置的比接纳者的略大，颁布者自身的切换也较为杂乱。
在 RocketMQ 的规划中，期望以一种去中心化的规划下降中心节点宕机带来的大局危险，（这儿以为中心化和是否存在中心节点是两件事）所以没有引进租约机制。在 Controller （对应于 Q ）溃散康复期间，因为 Broker 对自己身份会进行永久缓存，每个主副本会办理这个副本组的状况机，RocketMQ Dledger Controller 这种办法能够尽量确保在大部分副本组在岗兵组件不行用时仍然不影响收发音讯的中心流程。而旧主因为永久缓存身份，无法降级导致了网络分区时体系有必要忍受双主。产生了多种处理计划，用户能够经过预装备挑选 AP 型可用性优先，即答应体系经过短时分叉来确保服务连续性（下文还会持续谈谈为什么音讯体系中分叉很难避免），仍是 CP 型共同性优先，经过装备最小副本 ack 数超越集群半数以上节点。此刻发送到旧主的音讯将因为无法经过 ha 链路将数据发送给备，向客户端回来超时，由客户端将建议重试到其他分片。客户端阅历一个服务发现的周期之后，客户端就能够正确发现新主。
特别的，在网络分区的状况下，例如旧主和备，Controller 之间产生网络分区，此刻因为没有引进租约机制，旧主不会主动降级，旧主能够装备为异步双写，每一条音讯需求经过主备的两层供认才干向客户端回来成功。而备在切换为主时，会设置自己只需求单个副本供认的同步写盘办法。此刻，客户端短时刻内仍然能够向旧主发送音讯，旧主需求两副本供认才干回来成功，因而发送到旧主的音讯会回来 SLAVE_NOT_AVAILABLE 的超时呼应，经过客户端重试将音讯发往新的节点。几秒后，客户端从 NameServer / Controller 获取新的路由时，旧主从客户端缓存中移除，此刻完结了备节点的提高。
外置的组件能够对节点身份进行分配，上图展现了一个两副本的副本组上线.多个 Controller 经过推举和对 Broker 的恳求进行重定向，终究由一个 Controller 做为主节点进行身份分配。
2.假定 RocketMQ 副本组存在多个副本且需求选主，节点默许以备的身份发动，备节点会将自己注册到 Controller。
a.若分配的身份为备，解分出主节点的对外服务的地址并衔接，完结日志切断后进行 HA 同步。
b.若分配的身份为主，等候备机衔接到自身的 HA 端口，并向 NameServer 再次宣告自己是主节点。
4.主节点保护整个副本组的信息，向备建议数据仿制，周期性的向 Controller 报告主备之间水位距离，仿制速度等。
除了网络分区，许多状况导致日志数据流分叉。有如下事例：三副本选用异步仿制，异步耐久化，A 为旧主 B C 为备，切换瞬间 B 日志水位大于 C，此刻 C 成为新主，B C 副本上的数据会产生分叉，因为 B 还多出了一段未供认的数据。那么 B 是怎么以一个简略牢靠的办法去判别自己和 C 数据分叉的位点？
一个直观的主意便是，直接将主备的 CommitLog 早年向后逐步字节比较，一般出产环境下，主备都有数百 GB 的日志文件流，读取和传输很多数据的计划费时吃力。很快咱们发现，承认两个大文件是否相同的一个好办法便是比较数据的哈希值，需求比照的数据量一会儿就从数百 GB 下降为了几百个哈希值，关于第一个不相同的 CommitLog 文件，还能够选用部分哈希的办法对齐，这儿仍然存在一些核算的价值。还有没有优化的空间呢，那便是运用任期 Epoch 和偏移量 StartOffset 完结一个新的切断算法。这种 Epoch-StartOffset 满意如下准则：
2.备从后向前找到任期-起始点相同的那个点作为分叉任期，在上述事例里是 8,2250
3.挑选这个任期里主备完毕位点的最小值（假定主副本没有切换且为最大任期，则主副本的完毕位点是无穷大）
在完结数据切断的进程中，有一个很特别的动作，当备切主的时分要把 ConsumeQueue 的 Confirm Offset 提高到 CommitLog 的 MaxPhyOffset，即便这一部分数据在主上是否被提交是不知道的。回想起几年前看 Raft 的时分，当一条日志被传输到 Follower，Follower 供认收到这条音讯，主再把这条日志运用到自己的状况机时，告诉客户端和告诉一切的 follower 去 commit 这条日志这两件事是并行的，假定 leader 先回复 client 处理成功，此刻 leader 挂了，因为其他 follower 的供认位点 confirm offset 一般会略低于 leader，中心这段未决日志还没运用到 follower 的状况机上，这时就呈现了状况机不共同的状况
a.本地提交（apply） [40-100] 区间的数据，用后台的 dispatch 线程异步构建这段数据的索引
所以当备切换为主的时分，假定直接以 40 进行切断，意味着客户端现已发送到服务端的音讯丢掉了，正确的水位应该被提高至 100。可是备还没有收到 2.3 的 confirm = 100 的信息，这个行为相当于要提交了未决音讯。事实上新 leader 会恪守Leader Completeness 的约好
那么备切换成功的标志是什么，什么时分才干接纳 producer 新的流量呢？关于 Raft 来说一旦切换就能够，关于 RocketMQ 来说这个阶段会被稍稍推延，即索引现已彻底构建完毕的时分。RocketMQ 为了确保构建 consume queue 的共同性，会在 CommitLog 中记载 consume queue offset 的偏移量，此刻 confirm offset 到 max offset 间的数据是副本作为备来接纳的，这部分音讯在 consume queue 中的偏移量现已固定下来了，而 producer 新的流量时因为 RocketMQ 预核算位点的优化，比及音讯实践放入 CommitLog 的再实在的数据分发（dispatch）的时分就会发现对应方位的 consume queue 现已被占用了，此刻就形成了主备索引数据不共同。实质原因是 RocketMQ 存储层预构建索引的优化对日志有一些侵入性，但切换时时刻短等候的价值远远小于正常运转时提速的收益。
现在 RocketMQ 关于元数据是在内存中独自办理的，备机距离 5 秒向当时的主节点同步数据。例如当时主节点上创立了一个暂时 Topic 并承受了一条音讯，在一个同步周期内这个 Topic 又被删除了，此刻主备节点元数据或许不共同。又比方位点更新的时分，关于单个行列而言，多副本架构中存在多条消费位点更新链路，Consumer 拉取音讯时更新，Consumer 主意向 broker 更新，管控重置位点，HA 链路更新，当副本组产生主备切换时，consumer group 一起产生 consumer 上下线，因为路由发现的时刻差，还或许形成同一个消费组两个不同 consumer 别离消费同一副本组主备上同一个行列的状况。
，这有必定概率会形成脏数据。因为 RocketMQ 单个节点上 Topic / Group 数量较多，经过日志的完结会导致耐久化的数据量很大，在杂乱场景下依据日志做回滚依靠 snapshot 机制也会添加核算开支和康复时刻。这个问题和数据库很像，MySQL 在履行 DDL 修正元数据时经过会创立 MDL 锁，堵塞用户其他操作拜访表空间的拜访。备库同步主库也会加锁，元数据修正开端点和完毕点所代表的两个日志并不是一个原子操作，这意味着主库上在修正元数据的进程中假定宕机了，备库上持有的 MDL 锁就无法开释。MySQL 的处理计划是在主库每次溃散康复后，都写一条特别的日志，告诉一切衔接的备库开释其持有的一切 MDL 排他锁。对一切操作都走日志流进行状况机仿制要求存储层有多种日志类型，完结也愈加杂乱。RocketMQ 挑选以另一种同步的办法操作，即相似 ZAB 这样二阶段协议，例如位点更新时的能够挑选装备 LockInStrictMode 让备都同步这条修正。事实上 RocketMQ 为了优化上述位点跳动的现象，客户端在未重启时，遇到服务端主备切换还会用优先选用本位置点的办法获取音讯，进一步削减重复消费。
同步仿制的意义是用户的一个操作在多个副本上都现已提交。正常状况下，假定一个副本组中的 3 个副本都要对相同一个恳求进行供认，相当于数据写透 3 个副本（简称 3-3 写），3-3 写供给了十分高的数据牢靠性
异步仿制办法下，没有仿制到从节点的写恳求都会丢掉。向客户端供认的写操作也无法确保被耐久化。异步仿制是一种毛病时 RPO 不为 0
的装备办法，因为不必考虑从节点上的状况，总是能够持续呼应写恳求，体系的推延更低，吞吐功能更好。为了权衡两者，一般只需其间一个从节点是同步的，而其他节点是异步的办法。只需同步的从节点变得不行用或功能下降，则将另一个异步的从节点提高为同步办法。这样能够确保至少有两个节点（即主节点和一个同步从节点）具有最新的数据副本。这种办法称为 2-3 写，能协助避免颤动，供给更好的推延稳定性，有时分也叫称为半同步。
在 RocketMQ 的场景中，异步仿制也被广泛运用在音讯读写比极高，从节点数量多或许异地多副本场景。同步仿制和异步仿制是经过 Broker 装备文件里的 brokerRole 参数进行设置的，这个参数能够被设置成 ASYNC_MASTER、SYNC_MASTER、SLAVE 三个值中的一个。实践运用中要结合事务场景合理设置耐久化办法和主从仿制办法，一般，因为网络的速度高于本地 IO 速度，选用异步耐久化和同步仿制是一个权衡功能与牢靠性的设置。
同步仿制的意义是一条数据一起被主备供认才回来用户操作成功，能够确保主宕机后音讯还在备中，合适牢靠性要求较高的场景，同步仿制还能够约束未同步的数据量以削减 ha 链路的内存压力，缺陷则是副本组中的某一个备呈现假死就会影响写入。异步仿制无需等候备供认，功能高于同步仿制，切换时未提交的音讯或许会丢掉（参阅前文的日志分叉）。在三副本乃至五副本且对牢靠性要求高的场景中无法选用异步仿制，选用同步仿制需求每一个副本供认后才会回来，在副本数多的状况下严峻影响功率。关于一条音讯需求被多少副本供认这个问题，RocketMQ 服务端会有一些数量上的装备来进行灵敏调整：
在 RocketMQ v4.x 版别的完结中，Broker 周期性的（距离 30 秒）将自身的一切 Topic 序列化并传输到 NameServer 注册进行保活。因为 Broker 上 Topic 的元数据规划较大，带来了较大的网络流量开支，Broker 的注册距离不能设置的太短。一起 NameServer 对 Broker 是选用推延阻隔机制，避免 NameServer 网络颤动时或许瞬间移除一切 Broker 的注册信息，引发服务的雪崩。默许状况下反常主宕机时超越 2 分钟，或许备切换为主从头注册后才会替换。容错规划的一起导致 Broker 毛病搬运缓慢，RocketMQ v5.0 版别引进轻量级心跳（参数liteHeartBeat），将 Broker 的注册行为与 NameServer 的心跳进行了逻辑拆分，将心跳距离减小到 1 秒。当 NameServer 距离 5 秒（可装备）没有收到来自 Broker 的心跳恳求就对 Broker 进行移除，使反常场景下自愈的时刻从分钟级缩短到了秒级。
最早的时分，RocketMQ 依据 Master-Slave 办法供给了主备布置的架构，这种办法供给了必定的高可用才干，在 Master 节点负载较高状况下，读流量能够被重定向到备机。因为没有选主机制，在 Master 节点不行用时，这个副本组的音讯发送将会彻底中止，还会呈现推延音讯、事务音讯、Pop 音讯等二级音讯无法消费或许推延。此外，备机在正常作业场景下资源运用率较低，形成必定的资源糟蹋。为了处理这些问题，社区提出了在一个 Broker 进程内运转多个 BrokerContainer，这个规划相似于 Flink 的 slot，让一个 Broker 进程上能够以 Container 的办法运转多个节点，复用传输层的衔接，事务线程池等资源，经过单节点主备穿插布置来一起承当多份流量，无外部依靠，自愈才干强。这种办法下阻隔性弱于运用原生容器办法进行阻隔，一起因为架构的杂乱度添加导致了自愈流程较为杂乱。
另一条演进道路则是依据可切换的，RocketMQ 也尝试过依托于 Zookeeper 的散布式锁和告诉机制进行 HA 状况的办理。引进外部依靠的一起给架构带来了杂乱性，不简略做小型化布置，布置运维和确诊的本钱较高。另一种办法便是依据 Raft 在集群内主动选主，Raft 中的副自身份被透出和复用到 Broker Role 层面去除外部依靠，但是强共同的 Raft 版别并未支撑灵敏的降级战略，无法在 C 和 A 之间灵敏调整。两种切换计划都是 CP 规划，献身高可用优先确保共同性。主副本下线时选主和路由守时更新战略导致整个毛病搬运时刻仍然较长，Raft 自身对三副本的要求也会面对较大的本钱压力，RocketMQ 原生的 TransientPool，零仿制等一些用来避免削减 IO 压力的计划在 Raft 下无法有用运用。
RocketMQ DLedger 交融办法是 RocketMQ 5.0 演进中结合上述两条道路后的一个体系的处理计划。中心的特性有以下几点：
1.运用可内嵌于 NameServer 的 Controller 进行选主，无外部依靠，对两副本支撑友爱。
3.音讯在进行写入时，供给了灵敏的装备来协调体系关于可用性仍是共同性优先的诉求。
Kafka 的 Controller 是 Broker 推举产生，这需求有一个存储节点间的服务发现机制。RocketMQ 的 Controller 能够作为管控节点独自存在。对 Kafka，Pulsar 而言有必要挑选主副本进行写入，跟着时刻的运转节点之间负载需求经过杂乱的计划进行再均衡。对 RocketMQ 的交融架构而言，因为选主是可选的，静态布局的计划（例如无需依靠杂乱的动态调度就能够较为均衡的完结跨机架跨可用区），而且无切换与切换架构能够彼此转化。
RocketMQ Broker 的同步副本集保护是 Master Broker 节点上报，因为不强依靠中心节点来供给租约，controller 宕机时尽管无法为一起有主毛病的副本组推举，但不影响绝大部分副本组可用性。Pulsar 中经过 fencing 机制避免有多个 writer（pulsar 中的核算节点称为 broker）一起写同一个 partition，是对外部有依靠的。
Kafka 的存储笼统粒度是 Partition，对每个分区进行保护多副本，扩容需求进行数据仿制，关于冷读支撑更好。
Kafka 和 RocketMQ 都支撑灵敏的装备单条音讯的 ack 数，即权衡数据写入灵敏性与牢靠性。RocketMQ 在向云原生演进的进程期望简化客户端 API 与装备，让事务方只需关怀音讯自身，挑选在服务端装备一致装备这个值。
Pulsar 选用星型写：数据直接从 writer 写到多个 bookeeper。合适客户端与存储节点混部场景。数据途径只需求 1 跳，推延更低。缺陷是当存储核算别离时，星型写需求更多的存储集群和核算集群间网络带宽。RocketMQ 和 Kafka 选用 Y 型写：client 先写到一个主副本，由其再转发给别的 Broker 副本。尽管服务端内部带宽富余，但需求 2 跳网络，会添加推延。Y 型写利于处理文件多客户端写的问题，也更简略运用 2-3 写战胜毛刺，供给更好的推延稳定性。
仔细阅读 RocketMQ 的源码，其实我们也会发现 RocketMQ 在各种边际问题处理上细节满满，节点失效，网络颤动，副本共同性，耐久化，可用性与推延之间存在各种纤细的权衡，这也是 RocketMQ 多年来在出产环境下所堆集的中心竞争力之一。跟着散布式技能的进一步开展，更多更有意思的技能，如依据 RDMA 网络的仿制协议也呼之欲出。RocketMQ 将与社区协同前进，开展为 “音讯，事情，流” 一体化的交融渠道。