IM即时通讯分布式系统架构方法

一 独占鳌头的即时通讯架构兴许是这么着的

任凭IM音讯通信体系要么客户信息系统，其本质都是一套音信出殡与递送系统，或者说是一套网络通信体系，其本质两个词：贮存与转用。

推介：如有兴趣，本文作者的另一篇《一套高可用、易伸缩、高长出的IM群聊架构方案设计实践》，核符开展IM群聊架构设计的参照。

另外，之下几篇至于IM实则着手开支的文章也犯得着一读，有兴趣何尝不可探望：

《核符新手：从零开发一个IM服务端（依据Netty，有完整源码）》

《拿起键盘即使如此干：跟我一起徒手开支一套分布式IM系统》

《自已开销IM有那么难吗？手把手教你自撸一个Andriod版简易IM (有源码)》

《一种Android端IM智能心悸算法的计划性与奋斗以成探讨（含样例代码）》

《手把手教你用Netty贯彻网络通信次序的怔忡单式编制、断线重连机制》

《一个WebSocket实时聊天室Demo：据悉node.js+socket.io [附件下载]》

1携程异步音问系统前期架设

一套原创分布式即时通讯(IM)体系力排众议架设方案_im_ctrip1.png 

一套原创分布式即时通讯(IM)体系反驳架构方案_im_ctrip2.png 

上图所示兆示了携程家的消息体系的早期架构，图中架设径直用mongodb看作音尘序列，然后就把系统支付出去了，图中中何尝不可看出一个常见IT体系的接口层。

2京东冬冬前期架设

一套原创分布式即时通讯(IM)系统舌剑唇枪架设方案_im_jd.png 

上图颁发了京东家的消息系统的最初架设，其特点是“为了事务的快速上线，1.0 版本的技巧架构奋斗以成是非常径直且简单粗暴的”，与此同时后台系统用到.net据悉Redis就把一个IM系统支出出来了。

两家体系的最初架构证明，一套音讯系统对升级换代自家的服务质量是多么的重要，何尝不可觉着现代的服务型的互联网商社成人进程不怕一套IM体系的进化史。

二 本次方案的整体思绪

本文组合鄙人对IM体系的问询，也交到一套初具IM体系系统性状的音问系统架设模子。本文只着想IM系统的在线音信模子，不着想其离线音息系统[可知贮存IM音尘的体系]。

1据悉个体懂得，其理所应当的feature一般来说

A 通栏体系中Server端提供存储转发能力，随便一体化架构是B/S或者C/S；

B 音尘发送者力所能及成功发送信息给后端，且博得后端地认账；

C 接收端力所能及不重不漏地收到Server端转发来的远非逾越音尘生命周期和系统承载能力的信息；

D 一切系统只着想文牍短消息[即范围其长短]；

E 每条消息都有生命周期，如一天，且有长短限量如1440B【尽量不要跨越一个frame的size】，只着想在线信息的处理，不论过期的信息或者过量系统承载能力的音息[如键盘疯子要么键盘狂机器人时有发生的音信]都被觉着是"污染源音讯";

F 为简单起见，不给音信大队人马花色，如个人对民用消息，群音讯，讨论组信息等，都认为是一剧种[下文用channel指代之，也有人用Room其一词]音问门类；

G 为简单起见，其一群的另起炉灶与绝灭流水线本文不述及，也即音息流程始起的时分逐条音讯群都已经组装告竣，且工艺流程中从来不成员的增减；

H 账户申请、用户鉴权和天朝独有的黄反词检讨等IM无恙层等暂不设想。

2基于以上系统特征，先交给一套稍微完备的IM系统的框架图

一套原创分布式即时通讯(IM)体系答辩架设方案_im_model.jpg

3系统名词解释

1 PC: 单机型客户端，如windows端和mac端等等；

2 Web/h5: 网页客户端；

3 Android：大哥大挪动端，取其超群Android端，当然也有ios端[不过考虑到各家支出App都是安卓客户端最先上系统新版本，故用Android代表之]；

4 broker：公事音讯的有线抑或无线接口端，考虑到携程施用了其一词，我也姑且先用之，它提供了音尘的收到与投递效验；

5 Relay：图表/语音/视频 转速接口端，自此端得以是自家的劳务也何尝不可是第三方服务(如提供图形存储劳务的七牛、提供云视频解决方案的腾讯云等)；

6 msg chat server：信息逻辑甩卖端；

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：音尘逻辑甩卖层，[这层其实应有有系统最多的模块]；

14 DB：贮存层，储存了在线状态、消息id以及msg id序列和消息本末等；

15 http: 音尘殡葬和吸纳议商，IM商榷中形似理解为long polling音问处理方式，在web端多役使这种商谈；

16 Websocket: 另一种音讯发送和收下商计，在移位环境还是使唤html5开支的体系多采用这种情商；

17 TCP: 另一种消息发送和接过计议，在环境还是行使html5支出的系统多利用这种计议；

18 UDP: 另一种音息殡葬和收执协议，某个不承保提供风平浪静音问传输服务的厂家用到的情商，也许也是用户顶多施用的商榷，它的长处是甭管无线要么有线环境下都非常快，又鉴于http/Websocket的基础都是tcp商计，UDP筹商在环境围堵情况下由于不提供卡脖子宰制等退让算法，反而会去争用台网大路，为此在网络复杂的特别是生出台网风云突变的情况下它会剖示更快^ _ ^ & ^ _ ^【呵呵哒】；

19 RPC: 一种远道历程调用协和，提供分布式环境下的函数调用能力；

20 Restful: 一种远距离服务提供的架设风格，跟RPC比突起类同更高级点。

三 具体音息殡葬工艺流程

在引见音息出殡流水线之前，先引见有点儿基本概念。

1pub/sub、UIN和session

一个信息系统，从千上的话，不怕一个PUB/SUB系统，有音问变卦者publisher[or producer]，有消息倒车者broker，有音息处理者msg server，以及音信顾客subscriber[or consumer]。信息顾主何尝不可是一个人，也可以是一群人，在pub/sub系统其间producer&consumer一块结成了一个channel，抑或名为room，或者叫做group。

任由producer还是consumer，每个具体单位都要由体系分红给一个id，名为UIN[副词门源icq]。

后端的if层的broker机器可以在环球或者某部区域分布多个，UIN根据dns系统得以到手if层有所的机器列表，倘若dns层由于机器坏掉抑或是被攻击时力所不及劳务，这就是说客户端应该基于饮水思源[随便上次成功登陆的机器或者被厂家置放的机具列表]清楚一点机器的ip&port地点，下一场基于测速结实来选料一个离其不久前的broker。

UIN介于broker之间拓展一段时间内有效的对话劳务，誉为一个session。其一session万古长存于一个长累年里，也何尝不可翻过几个长连日来要么短连续不断，即session自身倚赖的网子链接是不长治久安的。session有效之间内，Server觉得UIN在线，session有效期内客户端要定时地给broker出殡心跳包。本文觉得的session方可是不康乐的，即session有效期内下发放客户端的信息方可遗失，然则得以经过一些其他手段包管音讯被递送给客户端。

2四 殡葬流水线

消息的制造者[producer]一般是IM体系的最基本单元UIN[即一个自然人]，既然是一个自然人，就觉着其发送能力有限，不或许一秒内发出多于一条的信息，即其音讯频率最高为： 1条msg / s。出乎以此效率，都被认为是键盘狂人或者狂躁机器人，客户端抑或服务端理当有了拒谏饰非给这种人提供服务抑或抛弃其由于疯了呱几而产生的音息。

根据方面这个设若，producer生出的音息乞求被称呼msg req，服务器给客户端返回的消息一呼百应斥之为msg ack。全体消息工艺流程为：

A client以绿灯办法产生msg req，req = {producer uin, channel name, msg device id, msg time, msg content}；

B broker收取音信后，以uin为hash抑或经过另一个hash办法把信息转发给之一msg chat server；

C msg chat server收取音讯后以key = Hash{producer uin【发送者id】 + msg device id【设备id】+ msg time【音信发送岁时，精确到秒】}到地头音息缓存中查询音息是否已经设有，倘或设有则终止音信流水线，给broker赶回"duplicate msg"其一msg ack，不然后续；

D msg chat server到Counter模块以channel name为key查询其最新的msg id，把msg id自增一后看作这条音问的id；

E msg chat server把分配好id的音息插入本地msg cache和msg DB[mysql/mongoDB]中；

F msg chat server给broker赶回msg ack, ack = {producer uin, channel name, msg device id, msg time, msg id}；

G broker把msg ack下发放producer；

H producer吸收ack包后偃旗息鼓音问工艺流程，万一在殡葬流程脱班后仍未吸收音问则转到手续1开展重试，并计算重试次数；

I 要是重试次数超过两次依然成不了则提醒“体系繁忙” or “台网环境不佳，请所有者稍后再品味发送”等，偃旗息鼓音问殡葬工艺流程。

上头宏图到了一个模块图中绝非的概念：msg cache，就此从未有过绘制出去，是因为msg cache的大大小小是可预估的，它只是用来消息去重看清，就此只需存下去重msg key即可。如果msg chat server的劳务食指是40 000人，音讯殡葬效率是1条/s，音尘的生命周期是24 hour，音讯key长度是64B，那么以此cache轻重缓急 = 64B * (24 * 3600)s * 40000 = 221 184 000 000B，这个数字兴许有点恐怖，一经是真实小买卖环境其一数目字只会更小，因为并未人一天一夜不吃不喝不停发消息嘛。其本质是一个hashset(C++中照应的是unordered_set)，物理存储介质当然是共享内存了。

[2016/03/10日：透过沉凝，msg cache只需存下某某UIN在某部device上的最新的音讯流光即可，msg cache的结构应为hashtable，以{UIN + device id}为key，以其最新的音息的殡葬岁时(客户端殡葬音信的工夫)为value，不再考虑音讯的生命周期。msg chat server每吸纳一条新信息就把新音问中记录的发送岁月与缓存中著录的音尘工夫比较即可，要是新音息的时间自愧不如本条msg pool记录的时间即作证其为双重音尘，超乎则为新消息，并用新音尘的msg time当作msg cache中前呼后应kv的value的最新值。倘或UIN为4B，device id为4B，岁时为4B，则msg cache的数额的size（不精打细算hashtable数据结构本身霸占的内存size）为12B * 40000 = 480 000B，新msg pool全然与每条消息的lifetime无关，这就大大减退了其内存占用。

那么还有一个题目，假如用户改改了部手机的地头流光怎么办？那就换做另一个参数：地面手机钟表一股脑儿周转时长，手