我们联想一个场景:一个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的客户端重发
一个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,此后就都一样了。
来源:即时通讯网 - 即时通讯开发者社区!
轻量级开源移动端即时通讯框架。
快速入门 / 性能 / 指南 / 提问
轻量级Web端即时通讯框架。
详细介绍 / 精编源码 / 手册教程
移动端实时音视频框架。
详细介绍 / 性能测试 / 安装体验
基于MobileIMSDK的移动IM系统。
详细介绍 / 产品截图 / 安装体验
一套产品级Web端IM系统。
详细介绍 / 产品截图 / 演示视频
引用此评论
引用:JackJiang 发表于 2023-06-13 20:56 不是很理解这句:“3、如果有个别用户处理失败,如有一个接收端的ack:R没有收到,重发时又需要把所有流程走 ...
引用:黄小贱 发表于 2023-06-13 22:25 嗯,在重发优化小节中确实通过fallback进行了优化,但第一次写,不知道是否是常规的操作。也想学习下Jack ...
引用:JackJiang 发表于 2023-06-14 11:04 对于每一条要发给群成员的实时消息来说,都是原子化的消息,可以对单条消息进行重发和应答管理,跟是不是 ...
引用:黄小贱 发表于 2023-06-14 12:07 嗯,Jack的意思我明白。那是不是可以这样理解:服务器接收到消息之后,群消息的必达,是依赖服务器的重试 ...
引用:JackJiang 发表于 2023-06-14 15:08 对,发送者只管送到服务器,余下的分段,由服务器去保证
引用:黄小贱 发表于 2023-06-14 16:22 原来如此,我这个方案背景是由发送者重发来解决的。构思来源于Jack这边的6报文流程,所以思路是 确保群消 ...
引用:JackJiang 发表于 2023-06-14 17:46 文章里的那篇6报文太啰嗦了,那篇不是我写的,我其实是不赞同的
精华主题数超过100个。
连续任职达2年以上的合格正式版主
为论区做出突出贡献的开发者、版主等。
Copyright © 2014-2024 即时通讯网 - 即时通讯开发者社区 / 版本 V4.4
苏州网际时代信息科技有限公司 (苏ICP备16005070号-1)
Processed in 0.125000 second(s), 36 queries , Gzip On.