31 Broker消息零丢失方案:同步刷盘 + Raft协议主从同步
Posted 鮀城小帅
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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机器都写入了,此时任何一台机器的磁盘故障,数据也是不会丢失的。
以上是关于31 Broker消息零丢失方案:同步刷盘 + Raft协议主从同步的主要内容,如果未能解决你的问题,请参考以下文章