20 基于DLedger技术的Broker主从同步原理

小灰灰 2022-10-09 12:16 151阅读 0赞

### 1.Broker高可用架构原理 ###

producer写入消息到broker之后，broker会将消息写入本地CommitLog磁盘文件里去，然后还有一些ConsumeQueue会存储Topic下各个MessageQueue的消息的物理位置。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70][]

高可用架构中，必须有一个Broker组，里面有一个是Leader Broker可以写入数据，然后让Leader Broker可以写入数据，然后让Leader Broker接收到数据之后，直接把数据同步给其他的Follower Broker。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 1][]

这样的话，一条数据就会在三个Broker中有三个副本，如果Leader Broker宕机了，那么就让其中一个Follower Broker切换为Leader Broker，继续接收客户端的数据写入就可以了。

### 2.基于DLedger技术实现CommitLog持久化 ###

**基于DLedger技术实现CommitLog机制。**

基于DLedger技术来实现Broker高可用架构，实际上就是用DLedger先替换掉原来Broker自己管理的CommitLog，由DLedger来管理CommitLog。

**实现原来**：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 2][]

该机制，首先使用DLedger来管理CommitLog，然后Broker还是可以基于DLedger管理的CommitLog去构建出来机器上的各个ConsumeQueue磁盘文件。

### 3.DLedger基于Raft协议选举Leader Broker的原理 ###

**Leader Broker选举**

简单来说，DLedger是基于Raft协议来进行Leader Broker选举的。

**Raft协议选举场景说明原理**

当前场景中，有3台机器进行选举，这一选举过程，三台Broker机器启动的时候，他们都会投票自己作为Leader，然后把这个投票发送给其他Broker。

**第一轮选举：**

此时，Broker01是投票给自己的，Broker02是投票给自己的，Broker03是投票给自己的，他们都把自己的投票发送给了别人。

在这第一轮选举中，Broker01会受到别人的投票，他发现自己是投票给自己，但是Broker02投票给Broker02自己，Broker03投票给Broker03自己，此时各自持有一票，第一轮选举失败。

**随机休眠:**

接着每个人会进入一个随机事件的休眠，比如说Broker01休眠3秒，Broker02休眠5秒，Broker03休眠4秒。

**第二轮选举：**

Broker01先苏醒过来，它苏醒过来后，会先尝试投票给自己，并且发送自己的选票给别人。

接着Broker03休眠4秒后苏醒过来，他发现Broker01已经发送来了一个选票是投给Broker01自己的，此时他自己因为没有投票，所以就直接把票投给Broker01了，同时把自己的投票发送给别人。

接着Broker02苏醒了，他收到了Broker01投票给Broker01自己，收到了Broker03也投票给了Broker01，那么他此时自己是没投票的，直接就会尊重别人的选择，直接就投票给Broker01，并且把自己的投票发送给别人。

**票数汇总出结果：**

最后，所有人都会收到三张选票，都是投给Broker01的，那么Broker01就会当选为Leader。

**多数通过选票条件**

在选举中，只要有（3台机器 / 2）+ 1个人投票给某个人，就会选举它当Leader，这个（机器数量/2）+1 就是大多数的意思。

简单来说，就是票数过半的那台机器被成功选举为Leader Broker。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 3][]

总结：Raft协议中选举leader算法的核心机制是，一轮选举不出来Leader的话，就让大家随机休眠一下，先苏醒过来的人会投票给自己，其他人苏醒后发现自己收到选票了，就会直接投票给那个人。依靠这个随机休眠的机制，基本上几轮投票过后，一般都是可以快速选举出来一个Leader。

### 4. DLedger基于Raft协议进行多副本同步的原理 ###

**Raft协议中的多副本同步机制**

该机制中，数据同步分为两个阶段，一个是uncommited阶段，一个是commited阶段。

**两阶段同步原理**

首先Leader Broker上的DLedger收到一条数据之后，会标记为uncommited状态，然后他会通过自己的DLedgerServer组件把这个uncommited数据发送给Follower Broker的DLedgerServer。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 4][]

接着Follower Broker的DLedgerServer收到uncommitted消息之后，必须返回一个ack给Leader Broker的DLedgerServer，然后如果Leader Broker收到超过半数的Follower Broker返回ack之后，就会将消息标记为commited状态。

然后Leader Broker上的DLedgerServer就会发送committed消息给Follower Broker机器的DLedgerServer，让他们也把消息标记为committed状态。

**返回生产者commit**

必须要超过一半的Follower Broker的DLedger对uncommitted消息返回ack，此时Leader Broker才能返回ACK给生产者，说明这次写入成功了。

以上，就是基于Raft协议实现的两阶段完成的数据同步机制。

### 5.基于Raft协议的数据同步场景对Leader Broker的写入性能的影响？以及各个场景是否适用？ ###

答1：原来是写broker的commitLog就会返回，现在是还要通知followers进行存储，等到过半返回ack才会返回给生产者写入成功。这样的操作严重影响了TPS。

答2：日志之类的统计信息可以容忍消息的丢失，不需要过半才成功。但，如果是支付业务这种场景，就需要保证消息的0丢失。

### 6.如果Leader Broker崩溃了怎么办？ ###

如果Leader Broker挂了，此时剩下的两个Follower Broker就会重新发起选举，他们会基于DLedger机制采用Raft协议的算法，去选举出来一个新的Leader Broker继续对外提供服务，而且会对没有完成的数据同步进行一些恢复性的操作，保证数据不会丢失。

### 7. 扩展： ###

（1）DLedger管理的那个commitLog就是Broker的commitLog；

（2）多个Slave Broker进行选举时，**committed index靠后**的优先选举为Leader Broker，因为数据最完整；

（3）如果leader消息标记为committed状态，没来得及通知follower就挂了。那么，新选举的时候，检查到多数节点都有这个uncommitted消息，就会把这个消息编程已提交状态，这样选举出来leader，下次同步时候就会把这条数据同步给新加入集群的broker。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70]: /images/20221005/df6d756910224c24a8e60dcd794788d8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 1]: /images/20221005/b3cd77d0cfc0443db4681edfc38f7e07.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 2]: /images/20221005/d06199c557de4310953cc8a2f225e0c7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 3]: /images/20221005/2cff14a1e0b14817bbb2552e1f11ce20.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 4]: /images/20221005/24b1d6e1c73e41969917821aef0de14b.png