分类： 云计算
2023-03-02 10:02:29
如何确保IM 不丢消息是个相对复杂的话题，从客户端发送数据到服务器，再从服务器抵达目标客户端，{BANNED}最佳终在 UI 成功展示，其间涉及的环节很多，这里只取其中一环「接收端如何确保消息不丢失」来探讨，粗略聊下我接触过的两种设计思路。
说到可靠抵达，{BANNED}中国第一反应会联想到TCP 的 reliability。数据可靠抵达是个通用性的问题，无论是网络二进制流数据，还是上层的业务数据，都有可靠性保障问题，TCP 作为网络基础设施协议，其可靠性设计的可靠性是毋庸置疑的，我们就从 TCP 的可靠性说起。
在TCP 这一层，所有 Sender 发送的数据，每一个 byte 都有标号（Sequence Number），每个 byte 在抵达接收端之后都会被接收端返回一个确认信息（Ack Number）， 二者关系为 Ack = Seq + 1。简单来说，如果 Sender 发送一个 Seq = 1，长度为 100 bytes 的包，那么 receiver 会返回一个 Ack = 101 的包，如果 Sender 收到了这个Ack 包，说明数据确实被 Receiver 收到了，否则 Sender 会采取某种策略重发上面的包。
数据可靠抵达网络层之后，还需要一层层往上移交处理，可能的处理有：安全性校验，binary 解析，model 创建，写 db，存入 cache，UI 展示，以及一些 edge cases（断网，用户 logout，disk full，OOM，crash，关机。。） 等等，项目的 feature 越多，网络层往上的处理出错的可能性就越大。
举个{BANNED}最佳简单的场景为例子：消息可靠抵达网络层之后，写db 之前 App crash（不稀奇，是 App 都会 crash），虽然数据在网络层可靠抵达了，但没存进 db，下次用户打开 App 消息自然就丢失了，如果不在业务层再增加可靠性保障，网络层面不会重发，那么意味着这条消息对于 Receiver 永远丢失了。
这个方案可以简单理解为，将TCP 的 Ack 流程再走一遍，在应用层也构建一个 Ack 消息，在应用层可靠性得到确认（一般以存入 db 为准，更准确说是事务提交成功的回调函数）之后再发送这个 Ack 消息，Server 收到应用层 Ack 消息之后才认为 Receiver 已收到，否则也采取某种策略重发消息。
具体到IM App 当中，接收端接受到 Server 的 Message，将 Message 存入 db，在确认回调里发送 Ack Receive 消息，Server 收到 Ack Receive 即认为消息已经可靠抵达，否则会在某个时机重新推送（比如客户端重连服务器时候 Pull，比如有新消息时 Server Push）。
这个方案和上面不同，但也是在应用层操作。我们个每个Message 分配一个 Seq ID，这个 Seq ID 对于单个用户的接受消息队列来说是连续的，如果 Message A 和 Message B 是相邻的，那么 MsgBSeqID = MsgASeqID + 1。每次存入 db 的时候更新 db 里的 LastReceivedSeqID，LastReceivedSeqID 即为上一条写入数据库消息的 Seq ID。
这么做的好处是，每次从网络层收到消息时，从db 里取出 LastReceivedSeqID，如果 LastReceivedSeqID = 新消息 Seq ID - 1，那么说明应用层消息时连续的没有发生丢失。还可以对收到的批量消息做预检测，检查消息队列里的 Seq ID 是否为联系的，只要存在任何一种不连续的 Seq ID 情况，就说明发送了丢失，此时接收端可以用 LastReceivedSeqID 从 Server 重新获取准确的接受消息队列。
这么做的好处是避免了每次都需要发送一条Ack 消息，坏处是应用层逻辑复杂之后，一旦出现 Seq ID 不连续的情况，会过度依赖于 refetch，难以分析问题出现的原因，refetch 一旦过于频繁，其流量损耗极有可能大于 Ack 消息的数据量。
消息的可靠抵达可以抽象为更一般意义上的可靠性问题，工程上总会碰到需要解决各种形式可靠性问题的场景，以经典计算机理论或者实践为基础来分析应用层的工程问题，可以举一反三，药到病除。即时通讯聊天软件app开发可以加小蓝豆的v：weikeyun24咨询
在工程上实践可靠性，需要线了解工程的每一个环节以及数据如何在各个环节流动，接下来才是分析每一个环节数据出错的可能性。检验可靠性的标准时「入袋为安」，存入db 或者以其他方式持久化到 disk 当中，这样才能保证客户端每次都能正确读取到消息。
另外，可靠性可以理解为两方面：
· 一是数据可靠抵达（没有任何中间数据被丢失）；
· 二是正确抵达（没有乱序或者数据更改）。
其实理论上TCP 也不是 100% 可靠（数据有可能在传输时改变而无法被检测到），而是 100% 工程上可靠（数据改变而不被检测到时个极小概率的事件），这是另外一个有意思的话题其实理论上TCP 也不是 100% 可靠（数据有可能在传输时改变而无法被检测到），而是 100% 工程上可靠（数据改变而不被检测到时个极小概率的事件），这是另外一个有意思的话题。
