和大家分享一套分布式即时通讯(IM)系统理论架构

无论是IM消息通信系统还是客户消息系统，其本质都是一套消息发送与投递系统，或者说是一套网络通信系统，其本质两个词：存储与转发。

根据个人理解，其应有的feature如下

    A 整个系统中Server端提供存储转发能力，无论整体架构是B/S还是C/S；
    B 消息发送者能够成功发送消息给后端，且得到后端地确认；
    C 接收端能够不重不漏地接收Server端转发来的没有超过消息生命周期和系统承载能力的消息；
    D 整个系统只考虑文本短消息[即限制其长度]；

    E 每条消息都有生命周期，如一天，且有长度限制如1440B【尽量不要超过一个frame的size】，只考虑在线消息的处理，无论是超时的消息还是超出系统承载能力的消息[如键盘狂人或者键盘狂机器人发出的消息]都被认为是"垃圾消息";

    F 为简单起见，不给消息很多类型，如个人对个人消息，群消息，讨论组消息等，都认为是一种群[下文用channel替代之，也有人用Room这个词]消息类型；
    G 为简单起见，这个群的建立与销毁流程本文不述及，也即消息流程开始的时候各个消息群都已经组建完毕，且流程中没有成员的增减；
    H 账户申请、用户鉴权和天朝独有的黄反词检查等IM安全层等暂不考虑。

系统名词解释

    1 PC: 单机型客户端，如windows端和mac端等等；
    2 Web/h5: 网页客户端；
    3 Android：手机移动端，取其典型Android端，当然也有ios端[但是考虑到各家开发App都是安卓客户端{BANNED}最佳先上系统新版本，故用Android代表之]；
    4 broker：文本消息的有线或者无线接口端，考虑到携程采用了这个词，我也姑且先用之，它提供了消息的接收与投递功能；
    5 Relay：图片/语音/视频 转发接口端，其后端可以是自家的服务也可以是第三方服务(如提供图片存储服务的七牛、提供云视频解决方案的腾讯云等)；

    6 msg chat server：消息逻辑处理端；即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询

    7 Router: 在线状态服务端，存储在线的用户以及其登录的broker接口机的id以及一些心跳包时间等数据；
    8 Counter: 消息计数器，为每个text等类型的消息分配MSG id；
    9 Msg Queue: 每个channel消息的msg id队列，存储每个client未接收的且未超时的且未超出队列大小的msg id集合；
    10 Mysql/mongodb: 消息存储服务、用户资料数据、以及channel成员列表服务数据库，因为二者比较典型，所以取用了这个名字，当然你可以在其上部署一层cache服务；
    11 Client：客户端层；
    12 Interface/If(下文简称If)：服务接口层；
    13 Logic：消息逻辑处理层，[这层其实应该有系统{BANNED}最佳多的模块]；
    14 DB：存储层，存储了在线状态、消息id以及msg id队列和消息内容等；
    15 http: 消息发送和接收协议，IM协议中一般理解为long polling消息处理方式，在web端多采用这种协议；
    16 Websocket: 另一种消息发送和接收协议，在移动环境或者采用html5开发的系统多采用这种协议；
    17 TCP: 另一种消息发送和接收协议，在环境或者采用html5开发的系统多采用这种协议；
    18 UDP: 另一种消息发送和接收协议，某个不保证提供稳定消息传输服务的厂家采用的协议，也许也是用户{BANNED}最佳多使用的协议，它的优点是无论是无线还是有线环境下都非常快，又由于http/Websocket的基础都是tcp协议，UDP协议在环境拥塞情况下由于不提供拥塞控制等退让算法，反而会去争用网络通道，所以在网络复杂的特别是发生网络风暴的情况下它会显得更快^ _ ^ & ^ _ ^【呵呵哒】；
    19 RPC: 一种远程过程调用协议，提供分布式环境下的函数调用能力；
    20 Restful: 一种远程服务提供的架构风格，跟RPC比起来貌似更高级点。

在介绍消息发送流程之前，先介绍一些基本概念。

一个消息系统，从宏观上来说，就是一个PUB/SUB系统，有消息生成者publisher[or producer]，有消息中转者broker，有消息处理者msg server，以及消息消费者subscriber[or consumer]。消息消费者可以是一个人，也可以是一群人，在pub/sub系统之中producer&consumer一起构成了一个channel，或者称之为room，或者称之为group。

无论是producer还是consumer，每个具体单位都要由系统分配给一个id，称之为UIN[名词来源于icq]。

那么还有一个问题，如果用户修改了手机的本地时间怎么办？那就换做另一个参数：本地手机时钟累计运行时长，手机出厂后其运行累计时长只会一直增加不会减小。

这个流程牵涉到一个比较重要的模块：Counter，这个模块其实都可以用Redis充当，怎么做你自己想^ _ ^。这个模块自身的实现就是一个分布式的计数器，直接使用Redis也没什么问题，但是{BANNED}最佳好的方法是采用消息id批发器的方式，msg chat server到Counter每次批发一批id回来,然后分配给每个msg，当使用完毕的时候再接着去Counter申请一批回来，以减轻Counter的压力，具体的设计请参考专利《即时消息的处理方法和装置》[参考文档9]。

上面还有一个概念未叙述到：发送端的消息邮箱{有人称为消息盒子，或者某大厂称之为客户端消息db}，它存储了所有本地发送出去的消息，其中没有服务端分配的msg id的消息都被认为是发送失败的消息，待用户主动尝试发送或者网络环境重新稳定后可以有客户端尝试重新发送流程。

用户查看消息邮箱中的本地历史消息的时候，就要依据msg id把消息排序好展现给用户。至于用户发送过程中看到的消息可以认为是本地消息的一个cache，每个channel{BANNED}最佳多给他展现100条，这100条消息的排序要依照每条消息的发出时间或者是消息的接收时间[这个接收到的消息时间以消息到达本机时的本地时钟为依据]。当用户要查看超出数目如100条消息之外的消息，客户端要引导用户去走历史消息查看流程。