2019-09-04有了 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给服务端。
2 55
2019-09-04两个ack的作用不同，tcp的ack表征网络层消息是否送达；业务层ack是真正的业务消息是否送达和是否正确处理，达到不丢消息，消息不重复的目的，即我们要保证的消息可靠性作者回复: 👍
14
2019-09-10老师您好，服务A向客户端B发送消息，第一次发送msg1，timestamp假设为 01（简写），序号为 01，这条消息因为某种原因，未存储时间戳和序号01，也未发送ack通知。A第二次发送msg2，timestamp为 02，序号为02，它做了存储，保存了最新的时间戳和序号。A第三次发送 msg3，此时B宕机了。 等B重启时，向A发送最新的时间戳和序号 02， 那么A发送大于02序号的消息，即 msg3， 那么 msg1如何保证不丢失呢？作者回复: 是的，如果只是时间戳或者“只是有序但不连续的序号”的话，是只能保证消息的时序性，不能保证消息的连续性。这种情况可以通过版本号机制来解决，通过两个版本号组成的链表（推送的每条消息携带前一条消息的版本号和当前这条消息的版本号）来检测消息的连续性和时序性。
8
2019-09-04您好，我在读到在消息完整性检查那里时有些疑惑，如果服务端将msg2发出之后，服务端和客户端断链，导致客户端无法接收消息，那么重新连接之后，是可以发送时间戳检测进行重传的。
但是，如果在服务端存储了发送方客户端发送的消息后，正准备将该消息推送给接收方客户端时发生宕机，那么当接收方客户端和服务端重新连接之后，服务端该如何知道自己要将之前存储的消息发送给接收方的客户端呢？作者回复: 用户上线的时候携带本地最新一条消息的时间戳给服务端，服务端从离线缓存里取比这个时间戳大的消息发给客户端就行了呀
4
2019-09-041、回答老师的问题：TCP层的ACK只是TCP包分片的ACK，并不能代表整个应用层的消息得到应答。理论上操作系统的TCP栈肯定是知道整个TCP消息得到对方的ACK了，但是操作系统好像并没提供这种接口。发送成功的接口返回成功通常都表示为操作系统发送成功了，至于链路上有没有问题就不知道了。
2、向老师请教下其他问题，恳请解答。
A、如果接收方本地保存了所有曾经接收过的消息id，接收方是很方便去重，但是，如果用户clear了本地消息该怎么办，是要一直存储所有已经接收的消息id吗
B、对于防范服务器宕机的时间戳机制，其实本质是序号，但是网络传输并不能保证服务器按序号发送的消息，低序号的就一定先于高序号的被接收方接收。所以如果高序号的已经被接收方处理且应答，而某个低序号的消息还没得到接收方应答的场景，通过序号保证完整性貌似不可取。展开作者回复: A. 接收方本地去重只需要针对本机已经接收到的存在的消息来做就可以了，服务端接收时实际上已经会做一次存储层的去重了，只会存在没有回ack的消息导致接收方重复接收的情况，这种两次之间一般时间间隔都比较短的。
B. 如果低序号的消息还没到，由于没有收到客户端的ack服务端会有超时重传机制会重传这条低序号的消息，另外即使这个时候用户关机不等那条消息了，再次上线时，采用版本号机制的话客户端也是可以知道消息不完整，可以触发服务端进行重推。 3 4- 2019-09-29老师，您好！
文中提到：用户 A 等待 IM 服务器返回超时，用户 A 被提示发送失败。但可以通过重试等方式来弥补。
我有个疑问：客户端在超时时间内没有收到响应然后重试，但实际上，请求已经在服务端成功处理了。这时用户 A 和 IM 服务器的状态就不一致了，用户 A 看到的是发送失败，而 IM 服务器却是处理成功的。
同样的，IM 服务器在等待 ACK 通知也存在这样的问题：IM 服务器在有限的重试次数内，一直没收到 ACK 通知，而消息却成功推送给了用户 B，IM 服务器和用户 B 的状态也不一致了。
在有限的重试次数内（线上不可能无限重试吧？），无法得到确定的返回结果，导致客户端和服务端的状态不一致，如何解决这个问题吖？
展开作者回复: 是的，对于重试不可能保证一定会成功，这些情况一般会以服务端中真实处理为准，通过多终端消息同步机制来让客户端有机会重新同步状态。比如发消息服务端处理成功，但是客户端接收响应超时'这种情况，服务端在成功处理完后会给发送方的发送设备推送当前消息的版本号，如果发送方设备没收到这个版本号，下次上线时会重新同步服务端的状态，用服务端消息进行覆盖。对于你说的第二种情况也比较简单，接收方b需要对重复接收的消息进行去重处理就可以了。
3 
2019-09-04老师，请问消息落地的话传统的redis+mysql是否会有性能瓶颈？是否会考虑leveldb（racksdb）这种持久化kv存储呢？作者回复: 看量级吧，我们自己的场景里mysql和hbase做为永久存储，pika作为离线消息的buffer存储 没有碰到瓶颈。
2
2019-09-04保证消息不丢失的做法：
1、发送消息阶段通过客户端的发送重试机制，和服务端的去重，保证发送时消息不丢失不重复
2、服务端推送阶段通过ACK确认机制和客户端去重保证推送时消息不丢失不重复
3、最后使用时间戳的同步机制来保证消息的完整性，这个应该要在服务端无法触发重推消息时才进行的一个操作作者回复: 👍
2
2019-09-04有了 TCP 协议本身的 ACK 机制为什么还需要业务层的 ACK 机制？
1.TCP属于传输层，而IM服务属于应用层，TCP的ACK只能保证传输层的可靠性，即A端到B端的可靠性，但是不能保证数据能够被应用层正确可靠处理，比如应用层里面的业务逻辑导致消息处理失败了，TCP层是不知道的。
2.TCP虽然是可靠性传输协议，但是如果传输过程中，假如数据报文还没被接收端接收完毕，接收端进程服务崩溃了，而用户又不再立刻启动这个应用程序，这也会导致消息丢失的吧。
所以不能只依靠TCP的ACK机制的。作者回复: 1没问题哈，对于2的话如果出现接收端进程崩溃，一般这个时候接收端APP也是处于不可用状态了，这种情况实际上也没法通过这个ACK机制来避免丢消息。可以在用户再次上线时进行完整性检查的确认，如果有消息没有被正确接收，再由服务补推。
3 2
2019-12-12如果客户端B离线了一段时间，当重连的时候服务器端已经积累了大量B的消息，比如999+条聊天记录，那么服务器端要逐条推送并且逐一更新时间戳么？还是可以批量推送，批量推送又如何保证客户端B的时间戳是最后一条的？作者回复: 离线消息可以采取批量方式进行下推。文中有提到时间戳只能保证时序性，要确保消息不丢还需要进一步采取链表校验方式来验证一致性。对于时间戳方式客户端可以简单按时间戳进行排序。
1
2019-10-09老师 从客户端到服务端，服务端要对客户端发送的消息去重， 用哪个字段呀。 这个字段应该是客户端发送消息由客户端产生的吧。 那如何能保证这个字段全局唯一，而不是客户端A 产生了和客户端B 同样的这个字段？ 去重的步骤是什么呢？ 是去数据库查找是否有这个字段的内容嘛？作者回复: 一般可以通过业务层的多个字段一起来排重：比如接收方uid和内容，发送时间等，不需要客户端额外生成一个字段。去重实现上可以通过上面字段组合成生成一个hash然后根据消息收到的时间加上一个比较短的过期时间来写入到一个中央存储里。
1
2019-09-26消息ID要求全局唯一且时间趋势递增吗？如果是这样，像微信和QQ这样体量的系统，要构建一个多大的消息序列集群才能满足需求？另外，微信和QQ的消息序列集群是全球唯一一个，还是多个集群并行部署？如果是全球唯一1个集群，跨半球的消息发送会不会延时很大，如果是多个集群，又如何保证时间趋势递增？作者回复: 消息ID要求全局唯一且时间相关，这个时间相关的精度是可以自行控制的，比如说是毫秒级有序还是秒级有序，通过内存级资源是能够实现每秒百万级发号能力的。我了解到的，类似微信这种IM，不需要支持多终端消息同步的场景，不需要通过拉取来对消息进行排序，所以实际上这个消息ID全局有序的必要性就很小了，只需要保证每个人的维度消息有序就可以，所以发号可以做到人维度。整体实现上也不需要时间相关了，只需要保证序号递增就能在接收端进行排序。腾讯整体据对外的分享，是采用多机房Set架构，其中包括海外机房，每个用户消息发送只会到所属的Set，然后通过多机房同步工具进行同步，所以消息发送方面延迟控制上应该也是有保障的。
1- 2019-09-20用户B，只用一个时间戳的话，是否会出现这样的问题：
服务器给用户B 推送两条消息：消息1，消息2。用户B 收到了消息2，未收到消息1，然后下线了。
重新上线之后，由于记录了消息2 的时间戳，用于跟服务端比较，服务端只会推比消息2 更晚的消息。
消息1 就丢失了。作者回复: 是的，单纯的时间戳只能解决时序性问题，并不能解决丢消息的问题，这个可以采用链表式版本号方式或者保证连续递增序号推送。
1 
2019-09-20老师，服务端消息重发，是需要单独开一个定时器是吧，多少秒一次合适呢？一次拉取多少条消息进行重发呢？谢谢作者回复: 每次下推都需要重开定时器的，一般重启几次仍然失败就放弃不推了。超时这个一般我们是几十秒，太长了也没必要，太短的话会出现重复推送比较多。重推都是针对单条消息的。
1
2019-09-12思考题：TCP和业务层做在的维度不一样，故虽然两者的ACK机制原理一样，但不能相互替代。TCP的ACK完成只能说明数据包已经正确传输完毕，但不代表数据包里的数据已经被正确处理完毕。业务层的ACK就是来保证数据包里的数据正确处理完毕的。TCP的ACK完成是业务层ACK的前提，业务层ACK完成是业务规则上的保证。作者回复: 👍
1
2019-09-09有2个问题
1 服务端发消息给客户端，没收到ack重试有最大次数吗？是像tcp那样一直重试直到收到ack吗？
如果客户端有bug导致处理消息一直失败，是否会导致服务端一直在重试，然后队列就满了。
2 收到消息后处理失败了要怎么处理，是不做等待服务端重发吗？展开作者回复: 1. 会有重试次数，毕竟即使收不到还有离线消息来补充。
重试多次仍然失败服务端可以主动断连来避免资源消耗。
2. 一般等着服务端重推就好了。 1
2019-09-07如果客户端一直连接不上，IM服务器会怎么处理，缓存一段时间的数据?作者回复: 对，一般至少会缓存到离线消息的buffer中。
1
2019-09-04Tcp的ack机制可以保证通过tcp传输的数据被对端内核接受并放入对应的socket接受缓存区里面，但是接下来进程读取缓存区以及进行逻辑处理可能会出现问题，所以需要应用层的ack机制保证数据包被进程读取并正确的处理。 1
2019-09-04请问一下老师：如果im服务器发给用户的第一条消息，用户b没有给业务层ack，但是im服务器紧接着又收到了第二条消息往用户b发送，此时用户b返回了正常ack。那么第一条消息在超时的时候会从队列里拿出来重传，假设用户b收到且返回ack成功，这个时候第一条消息作者回复: 留言没完整哈，如果是重复接收的问题，需要客户端来进行去重的。
1
2019-09-04老师您好，我想问下服务端IM先后推送两条消息msg0、msg1、msg2到客户端B，如果msg0、msg2先到达，此时客户端B应该不会更新到msg2的发送时间戳吧，而是等待msg1到达。如果此时陆续msg3、msg4消息到达，msg1还没到达，客户端是否也可像tcp一样，发送3个msg0消息到服务端IM，而不需要等待超时就让IM服务端立即重发msg1，这样可以降低延时，等到msg1到达客户端B后，可以直接将时间戳更新至最新到达消息的时间戳吧，而不是msg1的时间戳，不知道的理解的对不对，老师有时间看看作者回复: 首先这里要能让客户端知道有一条消息msg1还没到，所以单纯使用时间戳可能是不够的，时间戳只能代表时序，并不能判断出完整性，所以可能还需要配合连续的序号来实现感知（比如每次建连，服务端针对这条连接的所有推送从0开始自增，随消息一起下推）。至于你说的类似tcp的重传机制，这个理论上是可以这么实现的，就是复杂度上会高一些。
1