04 | ACK机制：如何保证消息的可靠投递？
该思维导图由 AI 生成，仅供参考
消息丢失有哪几种情况？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了即时消息系统中的消息可靠投递机制，重点关注了保证消息不丢失和不重复的挑战。从用户角度出发，强调了消息的可靠投递需要保证消息不丢失和不重复。通过分析服务端路由中转类型的IM系统，详细讨论了消息丢失的可能情况，并提出了针对这些情况的解决方案，包括客户端超时重发、服务端去重机制以及业务层ACK机制。在业务层ACK机制中，介绍了消息重传和消息重复推送的解决方案，包括维护超时计时器和使用Sequence ID进行去重。文章还提出了消息完整性检查的实现机制，如“时间戳比对”，以及对消息可靠投递的小结和思考题。整体来说，本文通过具体案例和技术原理，深入浅出地介绍了消息可靠投递的技术特点和解决方案，对于即时消息系统的设计和实现具有一定的参考价值。
《即时消息技术剖析与实战》，新⼈⾸单¥59
全部留言(80)
- 最新
- 精选
王棕生有了 TCP 协议本身的 ACK 机制为什么还需要业务层的ACK 机制？ 答：这个问题从操作系统(linux/windows/android/ios)实现TCP协议的原理角度来说明更合适： 1 操作系统在TCP发送端创建了一个TCP发送缓冲区，在接收端创建了一个TCP接收缓冲区； 2 在发送端应用层程序调用send()方法成功后，实际是将数据写入了TCP发送缓冲区； 3 根据TCP协议的规定，在TCP连接良好的情况下，TCP发送缓冲区的数据是“有序的可靠的”到达TCP接收缓冲区，然后回调接收方应用层程序来通知数据到达； 4 但是在TCP连接断开的时候，在TCP的发送缓冲区和TCP的接收缓冲区中可能还有数据，那么操作系统如何处理呢？ 首先，对于TCP发送缓冲区中还未发送的数据，操作系统不会通知应用层程序进行处理（试想一下：send()函数已经返回成功了，后面再告诉你失败，这样的系统如何设计？太复杂了...），通常的处理手段就是直接回收TCP发送缓存区及其socket资源； 对于TCP接收方来说，在还未监测到TCP连接断开的时候，因为TCP接收缓冲区不再写入数据了，所以会有足够的时间进行处理，但若未来得及处理就发现了连接断开，仍然会为了及时释放资源，直接回收TCP接收缓存区和对应的socket资源。 总结一下就是： 发送方的应用层程序，调用send()方法返回成功的时候，数据实际是写入到了TCP的发送缓冲区，而非已经被接收方的应用层程序处理。怎么办呢？只能借助于应用层的ACK机制。作者回复: 👍，嗯，即使数据成功发送到接收方设备了，tcp层再把数据交给应用层时也可能出现异常情况，比如存储客户端的本地db失败，导致消息在业务层实际是没成功收到的。这种情况下，可以通过业务层的ack来提供保障，客户端只有都执行成功才会回ack给服务端。
2019-09-045114
小可两个ack的作用不同，tcp的ack表征网络层消息是否送达；业务层ack是真正的业务消息是否送达和是否正确处理，达到不丢消息，消息不重复的目的，即我们要保证的消息可靠性作者回复: 👍
2019-09-0442
影随老师您好，服务A向客户端B发送消息，第一次发送msg1，timestamp假设为 01（简写），序号为 01，这条消息因为某种原因，未存储时间戳和序号01，也未发送ack通知。A第二次发送msg2，timestamp为 02，序号为02，它做了存储，保存了最新的时间戳和序号。A第三次发送 msg3，此时B宕机了。 等B重启时，向A发送最新的时间戳和序号 02， 那么A发送大于02序号的消息，即 msg3， 那么 msg1如何保证不丢失呢？作者回复: 是的，如果只是时间戳或者“只是有序但不连续的序号”的话，是只能保证消息的时序性，不能保证消息的连续性。这种情况可以通过版本号机制来解决，通过两个版本号组成的链表（推送的每条消息携带前一条消息的版本号和当前这条消息的版本号）来检测消息的连续性和时序性。
2019-09-10321- 墙角儿的花1、回答老师的问题：TCP层的ACK只是TCP包分片的ACK，并不能代表整个应用层的消息得到应答。理论上操作系统的TCP栈肯定是知道整个TCP消息得到对方的ACK了，但是操作系统好像并没提供这种接口。发送成功的接口返回成功通常都表示为操作系统发送成功了，至于链路上有没有问题就不知道了。 2、向老师请教下其他问题，恳请解答。 A、如果接收方本地保存了所有曾经接收过的消息id，接收方是很方便去重，但是，如果用户clear了本地消息该怎么办，是要一直存储所有已经接收的消息id吗 B、对于防范服务器宕机的时间戳机制，其实本质是序号，但是网络传输并不能保证服务器按序号发送的消息，低序号的就一定先于高序号的被接收方接收。所以如果高序号的已经被接收方处理且应答，而某个低序号的消息还没得到接收方应答的场景，通过序号保证完整性貌似不可取。
作者回复: A. 接收方本地去重只需要针对本机已经接收到的存在的消息来做就可以了，服务端接收时实际上已经会做一次存储层的去重了，只会存在没有回ack的消息导致接收方重复接收的情况，这种两次之间一般时间间隔都比较短的。 B. 如果低序号的消息还没到，由于没有收到客户端的ack服务端会有超时重传机制会重传这条低序号的消息，另外即使这个时候用户关机不等那条消息了，再次上线时，采用版本号机制的话客户端也是可以知道消息不完整，可以触发服务端进行重推。
2019-09-0448 
飞翔老师 从客户端到服务端，服务端要对客户端发送的消息去重， 用哪个字段呀。 这个字段应该是客户端发送消息由客户端产生的吧。 那如何能保证这个字段全局唯一，而不是客户端A 产生了和客户端B 同样的这个字段？ 去重的步骤是什么呢？ 是去数据库查找是否有这个字段的内容嘛？作者回复: 一般可以通过业务层的多个字段一起来排重：比如接收方uid和内容，发送时间等，不需要客户端额外生成一个字段。去重实现上可以通过上面字段组合成生成一个hash然后根据消息收到的时间加上一个比较短的过期时间来写入到一个中央存储里。
2019-10-0947- null老师，您好！ 文中提到：用户 A 等待 IM 服务器返回超时，用户 A 被提示发送失败。但可以通过重试等方式来弥补。 我有个疑问：客户端在超时时间内没有收到响应然后重试，但实际上，请求已经在服务端成功处理了。这时用户 A 和 IM 服务器的状态就不一致了，用户 A 看到的是发送失败，而 IM 服务器却是处理成功的。 同样的，IM 服务器在等待 ACK 通知也存在这样的问题：IM 服务器在有限的重试次数内，一直没收到 ACK 通知，而消息却成功推送给了用户 B，IM 服务器和用户 B 的状态也不一致了。 在有限的重试次数内（线上不可能无限重试吧？），无法得到确定的返回结果，导致客户端和服务端的状态不一致，如何解决这个问题吖？
作者回复: 是的，对于重试不可能保证一定会成功，这些情况一般会以服务端中真实处理为准，通过多终端消息同步机制来让客户端有机会重新同步状态。比如发消息服务端处理成功，但是客户端接收响应超时'这种情况，服务端在成功处理完后会给发送方的发送设备推送当前消息的版本号，如果发送方设备没收到这个版本号，下次上线时会重新同步服务端的状态，用服务端消息进行覆盖。对于你说的第二种情况也比较简单，接收方b需要对重复接收的消息进行去重处理就可以了。
2019-09-295 
隰有荷您好，我在读到在消息完整性检查那里时有些疑惑，如果服务端将msg2发出之后，服务端和客户端断链，导致客户端无法接收消息，那么重新连接之后，是可以发送时间戳检测进行重传的。 但是，如果在服务端存储了发送方客户端发送的消息后，正准备将该消息推送给接收方客户端时发生宕机，那么当接收方客户端和服务端重新连接之后，服务端该如何知道自己要将之前存储的消息发送给接收方的客户端呢？作者回复: 用户上线的时候携带本地最新一条消息的时间戳给服务端，服务端从离线缓存里取比这个时间戳大的消息发给客户端就行了呀
2019-09-0425
阳仔保证消息不丢失的做法： 1、发送消息阶段通过客户端的发送重试机制，和服务端的去重，保证发送时消息不丢失不重复 2、服务端推送阶段通过ACK确认机制和客户端去重保证推送时消息不丢失不重复 3、最后使用时间戳的同步机制来保证消息的完整性，这个应该要在服务端无法触发重推消息时才进行的一个操作作者回复: 👍
2019-09-045
L老师你好，关于完整性检查我有个问题。 下次会话时用户重装了软件/清空缓存/甚至更换了设备导致本地没有上次会话的时间戳了，这时候岂不是无法获取丢失的那些消息？作者回复: 嗯，是个好问题，如果上线时不携带时间戳或者版本号这种情况服务端默认会返回最新的n条消息给端上，后续旧消息用户再通过翻页来触发自动拉取。
2019-10-3034
小伟思考题：TCP和业务层做在的维度不一样，故虽然两者的ACK机制原理一样，但不能相互替代。TCP的ACK完成只能说明数据包已经正确传输完毕，但不代表数据包里的数据已经被正确处理完毕。业务层的ACK就是来保证数据包里的数据正确处理完毕的。TCP的ACK完成是业务层ACK的前提，业务层ACK完成是业务规则上的保证。作者回复: 👍
2019-09-123
