🔥 如何保障分布式IM聊天系统的消息可靠性（即消息不丢）原创

如何保障分布式I'M聊天系统的消息可靠性及消息不丢？聊天消息总是丢，不是网络差，是设计没兜底。本文主要聚焦分布式Adam聊天系统消息可靠性问题，即如何保证消息不丢失。一、重点拆解。产品做着做着，用户开始投诉我明明发了消息，对方怎么没收到？你查日志发现消息真丢了，但更可怕的是你也不知道他什么时候丢的。问题本质不是快不快，而是宁可慢点也不能丢，就算重发也不能重复。这就是我们常说的可靠消息投递。一个看似简单的需求，这是高可用I'M即时通讯聊天系统的分水岭。二、解决方案三层兜底光靠发一次肯定不行，我们要给关键消息上三重保险，一、客户端本地存二、服务端落盘加副本。三、超时重试、加密等去虫。每一层都不贵，合起来却能扛住99%的异常，下面看每层怎么落地。3、第一层客户端都低。记住一句话，只要没收到ack，也就当没发成功。

所以第一步不是联网，而是先把消息塞进手机本地数据库，比如Les，再加上客户端sky re try采用阶梯式重试策略，只有等到服务端明确说我收到了，才把这条消息从本地删掉，这样哪怕APP崩溃，手机重启，下次打开照样继续发，用户体验无缝衔接。而如果不做这一步，一旦断网或崩溃，消息直接蒸发，用户永远不知道。4第二层服务端兜底。客户端发来了，服务端能不能直接处理完就返回？绝对不行，如果此时机器宕机消息还在内存里，没来得及持久化，那就真的丢了。正确做法是两步走，1、收到消息立刻写入rockie temp qll支持刷盘集群同步。2、同步复制到至少三个副本节点，确保单点故障不丢数据。这一步的关键是ECK必须在落盘之后发，否则就是虚假确认，等于片客户端我收到了，其实自己也没保住。5、第三层密等性射箭。前面两层解决了存得住的问题，但这还不够，现实是网络可能超时，包可能丢失，AK可能没传回来，于是客户端必须重试，但重试带来新问题，我已经处理过了，再来一遍怎么办？解决办法是用唯一键加密等控制每个消息生成全局唯一的。

D如SESSION10IDMSGID服务端通过reddi的原子操作判断是否已处理。

六本文小结。上面三层如何联动一张？整条链路形成闭环，任何环节出问题都有对应兜底机制接管。