哪些环节会有丢消息的可能
跨网络环节
生产者发消息到MQ<br>
MQ到消费者
MQ主从同步的时候
MQ存盘环节<br>
通常MQ存盘时都会先写入操作系统的缓存page cache中，然后再由操作系统异步的将消息写入硬盘<br>
在这个时间差内，就可能会造成消息丢失：如果服务挂了，缓存中还没有来得及写入硬盘的消息就会丢失<br>
消息零丢失方案
RocketMQ的事务消息机制就是为了保证零丢失来设计的<br>
half消息用处<br>
确认RocketMQ的服务是否正常
嗅探下RocketMQ服务是否正常，并且通知RocketMQ，我马上就要发一个很重要的消息了，你做好准备
half消息如果写入失败了
half消息如果写入失败，我们就可以认为MQ的服务是有问题的，这时，就不能通知下游服务了
可以在下单时给订单一个状态标记，然后等待MQ服务正常后再进行补偿操作，等MQ服务正常后重新下单通知下游服务
订单系统写数据库失败了
写数据库失败(可能是数据库崩了，需要等一段时间才能恢复)。那我们可以另外找个地方把订单消息先缓存起来
RocketMQ返回一个UNKNOWN状态。这样RocketMQ就会过一段时间来回查事务状态
在回查事务状态时再尝试把订单数据写入数据库，<br>如果数据库这时候已经恢复了，那就能完整正常的下单，再继续后面的业务。这样这个订单的消息就不会因为数据库临时崩了而丢失<br>
同步刷盘+Dledger主从架构保证MQ主从同步时不会丢消息
把RocketMQ的刷盘方式 flushDiskType配置成同步刷盘就可以保证消息在刷盘过程中不会丢失了<br>
Dledger会通过两阶段提交的方式保证文件在主从之间成功同步<br>
uncommitted阶段<br>
Leader Broker上的Dledger收到一条数据后，会标记为uncommitted状态，然后他通过自己的DledgerServer组件把这个uncommitted数据发给Follower Broker的DledgerServer组件
commited阶段
接着Follower Broker的DledgerServer收到uncommitted消息之后，必须返回一个ack给Leader Broker的Dledger。然后如果Leader Broker收到超过半数的Follower Broker返回的ack之后，就会把消息标记为committed状态
Leader Broker上的DledgerServer就会发送committed消息给Follower Broker上的DledgerServer，让他们把消息也标记为committed状态。这样，就基于Raft协议完成了两阶段的数据同步
消费者端不要使用异步消费机制<br>
NameServer挂了如何保证消息不丢失<br>
只能设计一个降级方案来处理这个问题
多次尝试发送RocketMQ不成功，那就只能另外找给地方(Redis、文件或者内存等)把订单消息缓存下来，然后起一个线程定时的扫描这些失败的订单消息，尝试往RocketMQ发送
RocketMQ的服务恢复过来后，就能第一时间把这些消息重新发送出去
