消息的可靠性是IM系统的典型技术指标，对于用户来说，消息能不能被可靠送达（不丢消息），是使用这套IM的信任前提。

 

换句话说，如果这套IM系统不能保证不丢消息，那相当于发送的每一条消息都有被丢失的概率，对于用户而言，一定会不会“放心”地使用它，即“不信任”这套IM。

从产品经理的角度来说，有这样的技术障碍存在，再怎么费力的推广，最终用户都会很快流失。所以一套IM如果不能保证消息的可靠性，那问题是很严重的。

消息可靠性主要依赖2个逻辑来保障：

    1）上行消息可靠性；2）下行消息可靠性。

1）针对上行消息的可靠性，可以这样的思路来处理：

用户发送一个消息（假设协议叫PIMSendReq），用户要给这个消息设定一个本地ID，然后等待服务器操作完成给发送者一个PIMSendAck（本地ID一致），告诉用户发送成功了。即时通讯聊天软件app开发可以加小蓝豆的v：weikeyun24咨询

如果等待一段时间，没收到这个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系统架构中，所谓的数据安全，主要是通信安全和内容安全。