零基础即时通讯IM开发入门(三)：什么是IM聊天系统的可靠性？原创

零基础I'M即时通讯系统开发入门的第三篇什么是爱用聊天系统的可靠性应消息可靠性通常指聊天消息投递的可靠性。从用户行为来讲，消息可靠性分为在线消息的可靠性和离线消息的可靠性。从具体的技术表现来讲，消息可靠性包含两层含义，消息不丢和消息不重。对于消息不，它又包含两重含义，仅明确被对方收到和已明确未被对方收到。对于已明确未被对方收到的，意思是说，当对方没有成功收到时，你的应用系统也必须要感知到，否则它同样属于被丢范畴。总之，一个成型的应用系统必须包含这两种消息可靠性逻辑才能开用，缺一不可。消息的可靠性无疑是I'M系统的重要指标，也是I'M系统实现中的难点之一等。以下文字将从。

在线消息的可靠性和离线消息的可靠性进行讨论。先看下面这张典型的应消息收发流程，这是一个典型的服务端中转型I'M架构。所谓服务端中转型I'M架构是指一条消息从客户端A发出后，需要先经过I'M服务器来进行中转，然后再由I'M服务器推送给客户端B。这种模式也是目前最常见的I'M系统的消息分发架构。你可能会说I'M不可以是P2P模式的吗？是的，目前来说主流I'M基本都是服务器中转这种方式，P2P模式在I'M系统中用的很少。话题有点跑偏，我们回到正题，在上面这张图例，客户A发送消息到服务端，服务端中转消息给客户B。假设这两条数据链接中使用的通信协议是TCP。你认为在TCP所谓。

可靠传输协议加持下，真的能保证I'M聊天消息的可靠性吗？答案是否定的。在一个典型的服务端中转型I'M架构中，即使使用可靠的传输协议TCP也不能保证聊天消息的可靠性。为什么这么说？我们从客户端角度来理解为什么使用了可靠传输写ATCP的情况下I'M聊天消息仍然不可靠的问题。看下图，一目了然。一句话总结图上的含义，网络层的可靠性不等同于业务层的可靠性，项目的功能特性越多，网络层网上的处理出错的可能性就越大。举个最简单的场景为例子，消息可靠抵达网络层之后，写DB之前IAPP崩溃不稀奇，是APP都有崩溃的可能。虽然数据在网络层可靠抵达了，但没存进DB，下次用户打开APP，消息自然就丢失了。如果不在用。

不曾再增加可靠性保障，那么意味着这条消息对于接收端来说就永远丢失了，也就自然不存在可靠性了。那么，怎样在应用层增加可靠性保障呢？有一个现成的机制可供我们借鉴，TCP协议的超时重传确认机制增加了确认机制的消息收发过程如下图所示。具体来说就是，1、在应用层构造一种AC消息，当接收方正确处理完消息后，向发送方发送ack 2、假如发送方在超时时间内没有收到a CCK, 则认为消息发送失败，需要进行重传或其他处理。说完在线消息的可靠性问题，我们该了解一下离线消息了，离线消息的收发也存在不可靠性。下图是一张典型的I'M离线消息流程图，显然，离线消息收发过程同样存在。

在消息丢失的可能性。那么离线消息的可靠性保障如何实现呢？与在线消息收发流程类似，我们同样需要在应用层增加可靠性保障机制。下图是增加了可靠性保障后的离线消息收发流程。当然，上述的保障机制还存在性能优化空间。当离线消息的量较大时，如果对每条消息都回复ACK，无疑会大大增加客户端与服务器的通信次数。这种情况我们通常使用批量a CCK的方式对多条消息仅回复一个ACK。在某此后I'M、的实现中，是将所有但离线消息按会话进行分组，每组回复一个a CCK, 假如某个a CCK丢失，则只需要重传该会画的所有离线消息。前面通过在应用层加入重传确认机制后，我们确实是杜绝了消息丢失的可能性，但由于重试机制的存在，我们会遇到一个新的问题，那就是同一条消息可能被重复发送。消息去重的方式其实非常简单，一般是根据消息的唯一标志ID进行过滤。关于消息的去重问题，在一对一聊天的情况下逻辑并不复杂，但在群聊模式下会将问题复杂化。有关群聊消息不丢和去虫的详细讨论可以深入阅读。IM群聊消息如此复杂，如何保证不丢不中？保证消息的可靠性是I'M系统设计中很重要的一环。能不能做到消息不丢、消息不重，对用户的体验影响极大。所谓可靠的传输协议TCP也并不能保障消息在应用层的可靠性。我们一般通过在应用层的ack应答和重传机制来。

实现I'M消息的可靠性保障，但由此带来的消息重复问题需要我们额外进行处理，最简单的方法就是通过消息ID进行密等驱虫。关于IM系统消息可靠性的理论基础，我们就探讨到这里，有疑问的读者可以在评论区留言，欢迎积极讨论。