一、前言
RocketMQ能够理解成一个特别的存储体系，这个存储体系特别之处数据是一般只会被运用一次，这种状况下，怎么确保这个被消费一次的音讯不丢掉是非常重要的。本文将分析RocketMQ从哪些方面来确保音讯的不丢掉。
二、音讯什么状况会丢掉？
因为音讯从生产者，到broker,最后被顾客消费，中心最少经历了3个应用，2次rpc调用，因为rpc调用会存在成功失败外的第三种状况，因而音讯会存在不可靠性。
那么，咱们有哪些手法来提升音讯的可靠性呢？本文将分别从生产者端，顾客端，broker端来分析确保音讯不丢掉的手法。
三、怎么保障音讯不丢掉？
1、生产者端
生产者发送音讯，有同步发送和异步发送到Broker。
咱们假如对音讯可靠性要求比较高，咱们能够挑选同步发送。在RocketMQ的客户端，同步发送自带重试机制，假如同步形式发送失败，则轮转到下一个Broker。
假如重试都发送失败了怎么办呢？
这时候咱们要考虑发送失败的兜底计划-事务体系自己完成，事务体系能够将音讯存储起来，运用定时使命等机制来重发音讯。
2、Broker端
作为Broker，他的主要职责便是将音讯耐久化存储起来，同时最少把音讯投递到顾客端一次。
因为音讯是存在磁盘上的，因而耐久化机制就会涉及到刷盘机制。RocketMQ支持同步刷盘和异步刷盘机制。
RocketMQ处理发送音讯恳求时默许写入缓冲区，不会当即同步落盘，通过定时5s进行刷新落盘
SYNC_FLUSH，同步刷盘，刷盘完成再返回给客户端，超时5s
ASYNC_FLUSH，异步刷盘，200ms刷新一次，功能高
上面的机制能够确保存储可靠性，Broker除了确保存储音讯可靠外，broker还需求确保音讯能够投递给顾客消费一次。Broker怎么确保音讯一定会投递给顾客呢？
Broker端设计了重试机制。假如音讯消费失败了，会将音讯写到重试topic下的行列，会最大重试16次发送到顾客端。
假如16次之后，音讯仍是没有消费成功，Broker端会将音讯写入死信行列。
3、顾客端
音讯投递到了顾客端，顾客假如消费不成功，不能给broker端返回ack。一般需求设置为手动提交ack机制，顾客消费音讯不成功，不返回CONSUME_SUCCESS，返回RECONSUME_LATER表示需求broker再次投递该音讯。
这儿需求注意的是，因为broker确保音讯不丢掉有重试机制，或许导致音讯重复投递，因而顾客端需求做幂等性处理，一般会依据事务规则处理。
四、总结
音讯体系将不同的体系进行解耦，在提高了体系的高吞吐量和异步功能的同时，也对体系稳定性带来了应战，音讯确保可靠性不丢掉便是非常关键的一个稳定性应战，本文分别从生产者，Broker，顾客端三端来考虑对应计划来处理音讯不丢掉的手法。
