31 Broker消息零丢失方案：同步刷盘 + Raft协议主从同步

1.使用事务消息机制，消息就一定不会丢失了吗

通过使用事务消息机制，可以保证生产消息环节的消息不丢失，并且保证了两个业务系统的数据一致性。

但是，这却不能保证数据一定不丢失。这里指的是MQ进程的数据丢失问题。

场景分析

假设订单系统通过事务消息的机制，通过half消息 + commit 的方式，把消息在MQ里提交了。也就是说，现在对于MQ来说，那条消息已经进入到它的存储层了，可以被红包系统看到了。

 订单系统生产的消息在commit之后，会从half topic里进入OrderPaySuccessTopic中，但是此时仅仅是消息进入了指定的Topic而已，虽然可以被红包系统看到，但是可能红包系统还没来得及去获取这条消息。

如果在此时，该消息仅仅停留在os cache中，还没进入到ConsumeQueue磁盘文件里去，一旦此时该机器突然宕机了，os cache中的数据全部丢失，必然会导致你的消息丢失，红包系统再也没机会读到这条消息了。

2.消息进了磁盘后丢失的情况

即使消息顺利进入了OrderPaySuccessTopic的ConsumeQueue磁盘文件了，但是也存在丢失的风险。

当消息进入磁盘文件中，此时若红包系统没来得及消费这条消息，然后此时这台机器的磁盘突然就坏了，就会一样导致消息丢失，而且可能消息再也找不回来了，同样会丢失数据。

3.保证消息写入MQ不代表不丢失

经过前面1、2的说明，可以得知，即使在前面通过同步发送消息+反复多次重试的方案或事务消息来保证了消息写入MQ成功。

但是在MQ进程中，仍然存在丢失消息的可能，要么就是在 OS CACHE 未写入磁盘时宕机丢失，要么就是磁盘已写入未消费前磁盘损坏导致丢失。

4. 异步刷盘 vs 同步刷盘

如何保证消息成功写入MQ后，MQ自己不随便丢失数据？

答：关键的第一点，将异步刷盘调整为同步刷盘。

所谓异步刷盘

异步刷盘，就是消息即使成功写入了MQ，它也就在机器的os cache中，没有进入磁盘里，要过一会儿等操作系统自己把os cache里的数据实际刷入磁盘文件中去。

 所以在异步刷盘的模式下，写入消息的吞吐量是极高的。消息只要进入os cache内存就可以了，写消息的性能就是写内存的性能，每秒可以写入的消息数量要更多，但也正是这种情况下，可能就会导致数据的丢失。

同步刷盘策略

调整MQ的刷盘策略，需要调整broker的配置文件，将其中的 flushDiskType配置设置为： SYNC_FLUSH，默认它的值是ASYNC_FLUSH，即默认是异步刷盘的。

如果调整为同步刷盘之后，我们写入MQ的每条消息，只要MQ告诉我们写入成功了，那么他们就是已经进入了磁盘文件了。

完整流程：

当我们发送half消息的时候，只要MQ返回响应是half消息发送成功了，那么就说明消息已经进入磁盘文件了，不会停留在os cache。

5.通过主从架构模式避免磁盘故障导致的数据丢失

这里要做的是，避免磁盘故障导致的数据丢失。方案是，对Broker使用主从架构的模式。

原理就是，让一个Master Broker有一个Slave Broker去同步它的数据，而且你一条消息写入成功，必须是让Slave Broker也写入成功，保证数据有多个副本的冗余。

 这样一来，一条消息但凡写入成功了，此时主从两个broker上都有这条数据了，此时如果Master Broker的磁盘坏了，但是Slave Broker上至少还是有数据的，数据是不会因为磁盘故障而丢失的。

在主从同步的架构，是基于DLedger技术和Raft协议的主从同步架构，采用这套架构后，所有的消息写入，只要他写入成功，那就一定会通过Raft协议同步给其他的Broker机器。

6.MQ确保数据零丢失的方案总结

（1）把Broker的刷盘策略调整为同步刷盘，从而保证不会因为机器宕机而丢失数据；

（2）采用主从架构的Broker集群，那么一条消息写入成功，就以为着多个Broker机器都写入了，此时任何一台机器的磁盘故障，数据也是不会丢失的。