RocketMQ 预防消息丢失
Producer保证消息不丢失
通过同步的方式阻塞式发送，校验消息的SendStatus状态，如果返回OK，说明投递到了Broker中
采用事务消息方式投递，即消息发送到Broker上，Broker存储之后会回调Producer发送ACK，只要
Producer收到ACK之后，就说明已经投递到Broker中了，如果没有收到ACK，Broker会存储到自己的commitLog中
RocketMQ支持 日志的索引，如果一条消息发送之后超时，也可以通过查询日志的API，来check是否在Broker存储成功
Broker保证消息不丢失
持久化到 commitLog 中，这样就算是宕机之后也能保证消息能够再次加载
同步刷盘，异步刷盘将消息持久化到本地内存中
Broker 集群操作同步复制，异步复制；保证多个备份，即便是 Master 崩溃消息在 Slave 中仍有备份
Consumer保证消息不丢失
消费者可以根据自身的策略批量Pull消息
Consumer身维护一个持久化的OFFSET，标记已经成功消费或者已经成功发回到broker的消息下标
如果Consumer消费失败，那么它会把这个消息发回给Broker，发回成功后，再更新自己的offset
如果Consumer消费失败，发回给broker时，broker挂掉了，那么Consumer会定时重试这个操作
如果Consumer和broker一起挂了，消息也不会丢失，因为consumer 里面的offset是定时持久化的，重启之后，继续拉取offset之前的消息到本地
什么是offset
记录 message queue 长度的下标，每一条消息都会有对应的offset，小于当前列表中最小下标的消息是无法被消费
什么是事务消息方式投递
Kafka 预防消息丢失
消费端保证消息不丢失
当消费者自动提交了offset 还没来得及消费宕机，会导致消息丢失，这个时候需要进行的手动提交offset，这样可以保证消费端消息不丢失，但是会导致消息重复消费，消费完了，手动提交的时候消费者宕机，还会再次消费
broker 保证消息不丢失
当leader 宕机，此时leader 中的数据还没有同步到 follower中，当再次冲follower中选举leader时，会导致消息丢失
给topic设置replication.factor参数：这个值必须大于1，要求每个partition必须有至少2个副本
在kafka服务端设置min.insync.replicas参数：这个值必须大于1，这个是要求一个leader至少感知到有至少一个follower还跟自己保持联系
在producer端设置acks=all：这个是要求每条数据，必须是写入所有replica之后，才能认为是写成功了
在producer端设置retries=极大值：这个是要求一旦写入失败，就无限重试，卡在这里了
生产者保证消息不丢失
如果按照上述配置，生产者不会丢失消息，没有返回acks 是会一直重试下去的