整体流程如上图所述：
1. B拉取A发送给ta的离线消息；
2. server从DB中拉取离线消息；
3. server从DB中把离线消息删除；
4. server返回给用户B想要的离线消息；
想到这一步，也不难。
那么问题来了，B登录微信的时候，不止要拉取A发给他的离线消息，还需要拉取所有其他好友发给他的离线消息，这该如何实现呢？
如果用户B有很多好友，登录后客户端需要对所有好友进行离线消息拉取。
客户端伪代码：
如果有10000个好友，难道要拉取10000次？
画外音：我的微信好友已满员，大家猜微信好友上限是多少？
有没有减少拉取次数的优化方法呢？
按需拉取：先拉取各个好友的离线消息数量，真正查看离线消息时，才往服务器发送拉取请求。
除了减少流量的“按需拉取”优化，还有减少拉取次数的优化方案么？
一次性拉取：可以一次性通过receiver_uid即接收方ID，拉取所有好友发送给B的离线消息，把登录时与服务器的交互次数降低为了1次。到客户端本地再根据sender_uid进行计算。
问题又来了，用户B一次性拉取所有好友发给ta的离线消息，消息量很大时，一个请求包很大，速度慢怎么办？
分页拉取：根据业务需求，先拉取最新的一页消息，再按需一页页拉取。
新的问题又来了，离线消息会不会丢失，用户会不会收不到呢？
例如，上述步骤第三步执行完毕之后（删除了离线消息），第四个步骤离线消息返回给客户端过程中，服务器挂掉，路由器丢消息，或者客户端crash了，那离线消息岂不是丢了么。
画外音：数据库已删除，用户却还没看到。
如何保证离线消息的可达性？
加入ACK机制：如同在线消息的应用层ACK机制一样，离线消息拉时，不能够直接删除数据库中的离线消息，而必须等应用层的离线消息ACK，等客户端真的收到离线消息，才能删除数据库中的离线消息。
新的问题又来了，如果用户B拉取了一页离线消息，却在ACK之前crash了，下次登录时会拉取到重复的离线消息么？
拉取了离线消息却没有ACK，服务器不会删除之前的离线消息，故下次登录时系统层面还会拉取到。和在线消息投递一样，接收方通过msgid去重，系统层面会收到重复消息，但在业务层面，用户却无感知。
另一个问题，假设有N页离线消息，现在每个离线消息需要一个ACK，那么岂不是客户端与服务器的交互次数又加倍了？有没有优化空间？
其实，不用每一页消息都ACK，在拉取第二页消息时相当于第一页消息的ACK，此时服务器再删除第一页的离线消息即可，最后一页消息再ACK一次。这样的效果是，不管拉取多少页离线消息，只会多一个ACK请求，与服务器多一次交互。
稍作总结
离线消息的可靠投递，关键技术有：
1. 对于同一个用户B，一次性拉取所有用户发给ta的离线消息，能大大减少服务器交互次数；
2. 按需拉取，是无线端的常见优化；
3. 分页拉取，是一个请求次数与包大小的折衷；
4. 应用层的ACK，应用层的去重，才能保证离线消息的不丢不重；
5. 下一页的拉取，同时作为上一页的ACK，能够极大减少与服务器的交互次数；
知其然，知其所以然。
思路比结论更重要。返回搜狐，查看更多