公司网站建设攻略,郑州网站模板,网站集约化建设试点,济南网站优化分析消息的可靠性是IM系统的典型技术指标#xff0c;对于用户来说#xff0c;消息能不能被可靠送达#xff08;不丢消息#xff09;#xff0c;是使用这套IM的信任前提。 换句话说#xff0c;如果这套IM系统不能保证不丢消息#xff0c;那相当于发送的每一条消息都有被丢失的…消息的可靠性是IM系统的典型技术指标对于用户来说消息能不能被可靠送达不丢消息是使用这套IM的信任前提。 换句话说如果这套IM系统不能保证不丢消息那相当于发送的每一条消息都有被丢失的概率对于用户而言一定会不会“放心”地使用它即“不信任”这套IM。
从产品经理的角度来说有这样的技术障碍存在再怎么费力的推广最终用户都会很快流失。所以一套IM如果不能保证消息的可靠性那问题是很严重的。
消息可靠性主要依赖2个逻辑来保障 1上行消息可靠性2下行消息可靠性。
1针对上行消息的可靠性可以这样的思路来处理
用户发送一个消息假设协议叫PIMSendReq用户要给这个消息设定一个本地ID然后等待服务器操作完成给发送者一个PIMSendAck本地ID一致告诉用户发送成功了。即时通讯聊天软件app开发可以加小蓝豆的vweikeyun24咨询
如果等待一段时间没收到这个ACK说明用户发送不成功客户端SDK要做重试操作。
2针对下行消息的可靠性可以这样的思路来处理
服务收到了用户A的消息要把这个消息推送给B、C、D 3个人。假设B临时掉线了那么在线推送很可能会失败。
因此确保下行可靠性的核心是在做推送前要把这个推送请求缓存起来。
这个缓存由存储系统来保证MsgWriter要维护一个离线消息列表用户的一条消息要同时写入B、C、D的离线消息列表B、C、D收到这个消息以后要给存储系统一个ACK然后存储系统把消息ID从离线消息列表里拿掉。 针对消息的可靠性问题具体的解决思路还可以从另一个维度来考虑即实时消息的可靠性和离线消息的可靠性。
消息的有序性问题是分布式IM系统中的另一个技术“硬骨头”。
因为是分布式系统客户端和服务器的时钟可能是不同步的。如果简单依赖某一方的时钟就会出现大量的消息乱序。
比如只依赖客户端的时钟A比B时间晚30分钟。所有A给B发消息然后B给A回复。
发送顺序是 客户端A“XXX” 客户端B“YYY”
接收方的排序就会变成 客户端B“YYY” 客户端A“XXX”
因为A的时间晚分钟所有A的消息都会排在后面。
如果只依赖服务器的时钟也会出现类似的问题因为2个服务器时间可能也不一致。虽然客户端A和客户端B时钟一致但是A的消息由服务器S1处理B的消息由服务器S2处理也会导致同样消息乱序。
为了解决这种问题我的思路是通过可以做这样一系列的操作来实现。
1服务器时间对齐
这部分就是后端运维的锅了由系统管理员来尽量保障没有别的招儿。
2客户端通过时间调校对齐服务器时间
比如客户端登录以后拿客户端时间和服务器时间做差值计算发送消息的时候考虑这部分差值。
在我的im架构里这个能把时间对齐到100ms这个级差值再小的话就很困难了因为协议在客户端和服务器之间传递速度RTT也是不稳定的网络传输存在不可控的延迟风险嘛。
3消息同时带上本地时间和服务器时间
具体可以这样的处理排序的时候对于同一个人的消息按照消息本地时间来排对于不同人的消息按照服务器时间来排这是插值排序算法。
已读未读功能对于一对一的单聊消息来说还比较好理解就是多加一条对应的回执息当用户阅读这条消息时发回。
回归到本节的主题“已读同步”的问题这显示难度又进一级因为已读未读回执不只是针对“账号”现在还要细分到“同一账号在不同端登陆”的情况对于已读回执的同步逻辑来说这就有点复杂化了。
在这里根据我这边IM架构的实践经验提供一些思路。
具体来说就是用户可能有多个设备登录同一个账户比如Web PC和移动端同时登陆这种情况下的已读未读功能就需要来实现已读同步否则在设备1看过的消息设备2看到依然是未读消息从产品的角度来说这就影响用户体验了。
对于我的im架构来说已读同步主要依赖2个逻辑来保证 1同步状态维护为用户的每一个Session维护一个时间戳保存最后的读消息时间2如果用户打开了某个Session且用户有多个设备在线发送一条PIMSyncRead消息通知其它设备。
IM系统架构中的数据安全比一般系统要复杂一些从通信的角度来说它涉及到socket长连接通信的安全性和http短连接的两重安全性。而随着IM在移动端的流行又要在安全性、性能、数据流量、用户体验这几个维度上做权衡所以想要实现一套完善的IM安全架构要面临的挑战是很多的。
IM系统架构中所谓的数据安全主要是通信安全和内容安全。
