IM群消息投递可靠性的技术方案探讨（欢迎讨论）

在讨论群消息的解决方案之前，我们假定6报本 + 离线消息是写扩散的背景下进行探讨

常规流程

我们联想一个场景：一个999人的群，500人在线，499人不在线，用户X在群里发送一条消息。流程如下
1、消息发送到服务器中（生成消息Id、序号ID）
2、根据群ID，查询群用户ID
3、查询该群所有用户的在线信息，得到在线用户列表、离线用户列表
4、设置fallback = 500数，发送消息
    4-1：给所有在线用户发实时消息
    4-2、给所有离线用户写入离线消息
    4-3、给所有离线用户写入推送消息
5、接收反馈（在线其他群成员的ack:R，或者的接入层发送失败反馈）
6、反馈处理
    6-1、收到ack:R（客户端发给接入层，接入层在发给服务层），fallback--
    6-2、收到发送失败反馈（接入层反馈给服务层ack），写入离线消息，fallback--
    6-3、fallback处理之后，如果结果fallback为0，则给用户X发送ack:N
7、等待用户X的客户端重发

存在问题和解决思路

1、给500个在线用户发送消息，服务层到接入层的500次IO
2、给499个不在线用户写入离线消息，发送push，涉及到499 * 2 次IO
3、如果有个别用户处理失败，如有一个接收端的ack:R没有收到，重发时又需要把所有流程走一遍。
4、写扩散指数（这里是999）越大，处理出现故障的概率就越大。重试的次数将特别多次。
那么存在的问题分为两个方面：IO次数写扩散，重试成本高

实时消息写扩散优化

       关于实时消息的发送，由于给socket层面是一定要写500次的，这个无法规避；我们可以规避的是服务层到接入层这里的IO次数。假设我们的接入层节点有10个，这500个用户分散在接入这10个节点下。我们拿到这500个用户的在线信息时，同时拿到对应的接入节点信息，进行合并发送。最终达到的效果：发送10次RPC

离线消息写扩散优化

       我们的离线消息是采用redis的zset进行存储，但key是基于用户ID进行隔离的，所以无法通过lua这种方式进行处理。这里我们采用分批 + 异步 + pipeline（redis）的方式进行优化。举例：499个用户，我们分成10批用户，然后打包成10个任务，每任务的逻辑是通过redis的pipeline进行写操作。
推送的优化手段也是类似，但是它的一致性要求就没离线消息高。允许处理失败。

重试优化

        每次重试，所需要触发的流程都一样，假如998个用户都处理成功，只有一个用户失败了。真的是一颗老鼠屎！我们的解决方案是，只给失败的用户进行重试。针对实时消息举例：
fallback从计数的结构改成zset，member是接收端的唯一标识。第一次发送消息时，记录的全量数据。当收到接收者的ack时，进行remove操作，删掉其中的member，并且判断fallback长度，为0标识全都接收完毕。如果运气不好，有个别ack丢失了。在重试的时候，复用当前fallback即可，只针对当前fallback的member进行重发。

优化之后的流程

一个999人的群，500人在线，499人不在线，用户X在群里发送一条消息。流程如下
1、消息发送到服务器中（生成消息Id、序号ID）
2、根据群ID，查询群用户ID
3、查询该群所有用户的在线信息，得到在线用户列表、离线用户列表
4、生成fallback_online, fallback_offline
    4-1：在线用户消息合并发到接入层，接入层逐个发送（根据fallback_online）
    4-2、离线消息批量并行处理（根据fallback_offline）
    4-3、离线推送异步处理（根据fallback_offline）
5、设置客户端消息Id和服务端消息的绑定关系（设置过期时间10min），接收反馈。
6、反馈处理
    6-1、收到ack:R（客户端发给接入层，接入层在发给服务层），删除fallback_online中的member
    6-2、收到发送失败反馈（接入层反馈给服务层ack），写入离线消息，删除fallback_offline中的member
    6-3、fallback处理之后，如果结果fallback长度为0，则给用户X发送ack:N
   
重发流程：
1、消息发送到服务器中（根据客户端消息Id判断是重发）
2、根据群ID，查询群用户ID
3、查询该群所有用户的在线信息，得到在线用户列表、离线用户列表
4、查询fallback_online, fallback_offline，此后就都一样了。

等我仔细看完后回复你，稍等

不是很理解这句：“3、如果有个别用户处理失败，如有一个接收端的ack:R没有收到，重发时又需要把所有流程走一遍。”。

为啥一条消息失败，所有的用户都要重推？

引用：JackJiang 发表于 2023-06-13 20:56
不是很理解这句：“3、如果有个别用户处理失败，如有一个接收端的ack:R没有收到，重发时又需要把所有流程走 ...

感谢阅读和回复。这里是有两个方案吧，后续确实有做优化处理，但不知道是否合理

引用：JackJiang 发表于 2023-06-13 20:56
不是很理解这句：“3、如果有个别用户处理失败，如有一个接收端的ack:R没有收到，重发时又需要把所有流程走 ...

在重试优化环节的做法是否正确？想和Jack这样的经验大佬交流下

引用：JackJiang 发表于 2023-06-13 20:56
不是很理解这句：“3、如果有个别用户处理失败，如有一个接收端的ack:R没有收到，重发时又需要把所有流程走 ...

嗯，在重发优化小节中确实通过fallback进行了优化，但第一次写，不知道是否是常规的操作。也想学习下Jack这边使用的方案

引用：JackJiang 发表于 2023-06-13 20:56
不是很理解这句：“3、如果有个别用户处理失败，如有一个接收端的ack:R没有收到，重发时又需要把所有流程走 ...

未收到“一个接收端的ack:R” 针对的是服务器来说（在6个报文的背景下接收者未给服务器发送ack:R)，被视为消息有人未收到。
触发了发送者的重发流程

引用：黄小贱 发表于 2023-06-13 22:25
嗯，在重发优化小节中确实通过fallback进行了优化，但第一次写，不知道是否是常规的操作。也想学习下Jack ...

对于每一条要发给群成员的实时消息来说，都是原子化的消息，可以对单条消息进行重发和应答管理，跟是不是群消息无关。你发送端的逻辑，应该是该条消息成功发给服务器，ack应答由服务器回发给发送者即可。这样逻辑就简单多，因为职责进行了分段。

引用：JackJiang 发表于 2023-06-14 11:04
对于每一条要发给群成员的实时消息来说，都是原子化的消息，可以对单条消息进行重发和应答管理，跟是不是 ...

嗯，Jack的意思我明白。那是不是可以这样理解：服务器接收到消息之后，群消息的必达，是依赖服务器的重试，而不是依赖发送端的重试？

引用：黄小贱 发表于 2023-06-14 12:07
嗯，Jack的意思我明白。那是不是可以这样理解：服务器接收到消息之后，群消息的必达，是依赖服务器的重试 ...

对，发送者只管送到服务器，余下的分段，由服务器去保证

引用：JackJiang 发表于 2023-06-14 15:08
对，发送者只管送到服务器，余下的分段，由服务器去保证

原来如此，我这个方案背景是由发送者重发来解决的。构思来源于Jack这边的6报文流程，所以思路是 确保群消息的写扩散完全处理完毕，服务器再回复发送者ack:N。

http://www.52im.net/forum.php?mo ... B%CF%A2%CB%CD%B4%EF

引用：黄小贱 发表于 2023-06-14 16:22
原来如此，我这个方案背景是由发送者重发来解决的。构思来源于Jack这边的6报文流程，所以思路是 确保群消 ...

文章里的那篇6报文太啰嗦了，那篇不是我写的，我其实是不赞同的

引用：JackJiang 发表于 2023-06-14 17:46
文章里的那篇6报文太啰嗦了，那篇不是我写的，我其实是不赞同的

理解了，那方案上可以进化成4报文。而且服务器只要消息前期处理成功，就可以回复发送者处理成功了。接收者的消息可达方案， 我能想到的是起一个延迟任务，失败了再起延迟任务，直达成功或者次数限制。

Jack这边的重试发起一般建议如何处理？

其实我一直觉得，群这种消息模型，读扩散比较好，没这么多复杂的问题