南宁市保障住房建设管理服务中心网站,帮非法集资公司做网站违法吗,苏州市现代建设咨询管理公司,微信网站怎么开发如何确保IM 不丢消息是个相对复杂的话题#xff0c;从客户端发送数据到服务器#xff0c;再从服务器抵达目标客户端#xff0c;最终在 UI 成功展示#xff0c;其间涉及的环节很多#xff0c;这里只取其中一环「接收端如何确保消息不丢失」来探讨#xff0c;粗略聊下我接触…如何确保IM 不丢消息是个相对复杂的话题从客户端发送数据到服务器再从服务器抵达目标客户端最终在 UI 成功展示其间涉及的环节很多这里只取其中一环「接收端如何确保消息不丢失」来探讨粗略聊下我接触过的两种设计思路。 说到可靠抵达第一反应会联想到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存入 cacheUI 展示以及一些 edge cases断网用户 logoutdisk fullOOMcrash关机。。 等等项目的 feature 越多网络层往上的处理出错的可能性就越大。
举个最简单的场景为例子消息可靠抵达网络层之后写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 里的 LastReceivedSeqIDLastReceivedSeqID 即为上一条写入数据库消息的 Seq ID。
这么做的好处是每次从网络层收到消息时从db 里取出 LastReceivedSeqID如果 LastReceivedSeqID 新消息 Seq ID - 1那么说明应用层消息时连续的没有发生丢失。还可以对收到的批量消息做预检测检查消息队列里的 Seq ID 是否为联系的只要存在任何一种不连续的 Seq ID 情况就说明发送了丢失此时接收端可以用 LastReceivedSeqID 从 Server 重新获取准确的接受消息队列。即时通讯聊天软件app开发可以加小蓝豆的vweikeyun24咨询
这么做的好处是避免了每次都需要发送一条Ack 消息坏处是应用层逻辑复杂之后一旦出现 Seq ID 不连续的情况会过度依赖于 refetch难以分析问题出现的原因refetch 一旦过于频繁其流量损耗极有可能大于 Ack 消息的数据量。
消息的可靠抵达可以抽象为更一般意义上的可靠性问题工程上总会碰到需要解决各种形式可靠性问题的场景以经典计算机理论或者实践为基础来分析应用层的工程问题可以举一反三药到病除。
在工程上实践可靠性需要线了解工程的每一个环节以及数据如何在各个环节流动接下来才是分析每一个环节数据出错的可能性。检验可靠性的标准时「入袋为安」存入db 或者以其他方式持久化到 disk 当中这样才能保证客户端每次都能正确读取到消息。
另外可靠性可以理解为两方面
· 一是数据可靠抵达没有任何中间数据被丢失
· 二是正确抵达没有乱序或者数据更改。
其实理论上TCP 也不是 100% 可靠数据有可能在传输时改变而无法被检测到而是 100% 工程上可靠数据改变而不被检测到时个极小概率的事件这是另外一个有意思的话题其实理论上TCP 也不是 100% 可靠数据有可能在传输时改变而无法被检测到而是 100% 工程上可靠数据改变而不被检测到时个极小概率的事件这是另外一个有意思的话题。
