基于Netty，搭建高性能IM即时通讯集群

Posted 2022-10-03 wecloud1314

整个系统是一个C/S系统，客户端没有做复杂的图形化界面而是用Java终端开发的（黑窗口），服务端IM实例是Netty写的socket服务。

 

ZK作为服务注册中心，Redis用来做分布式会话的缓存，并保存用户信息和轻量级的消息队列。

服务端的工作原理

在上述架构中：NettyServer启动，每启动一台Server节点，都会把自身的节点信息，如：ip、port等信息注册到ZK上（临时节点）。

正如上节架构图上启动了两台NettyServer，所以ZK上会保存两个Server的信息。

同时ZK将监听每台Server节点，如果Server宕机ZK就会删除当前机器所注册的信息（把临时节点删除），这样就完成了简单的服务注册的功能。

客户端的工作原理

Client启动时，会先从ZK上随机选择一个可用的NettyServer（随机表示可以实现负载均衡），拿到NettyServer的信息（IP和port）后与NettyServer建立链接。

链接建立起来后，NettyServer端会生成一个Session（即会话），用来把当前客户端的Channel等信息组装成一个Session对象，保存在一个SessionMap里，同时也会把这个Session保存在Redis中。

这个会话特别重要，通过会话，我们能获取当前Client和NettyServer的Channel等信息。

Session的作用

我们启动多个Client，由于每个Client启动，都会先从ZK上随机获取NettyServer的的信息，所以如果启动多个Client，就会连接到不同的NettyServer上。

熟悉Netty的朋友都知道，Client与Server建立接连后会产生一个Channel，通过Channel，Client和Server才能进行正常的网络数据传输。

如果Client1和Client2连接在同一个Server上：那么Server通过SessionMap分别拿到Client1和Client2的会话，会话中包含Channel信息，有了两个Client的Channel，Client1和Client2便可完成消息通信。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询

 

如果Client1和Client2连接到不同的NettyServer上：Client1和Client2要进行通信，该怎么办？这个问题放在后面解答。

高效的数据传输

无论是IM系统，还是分布式的RPC框架，高效的网络数据传输，无疑会极大的提升系统的性能。

数据通过网络传输时，一般把对象通序列化成二进制字节流数组，然后将数据通过socket传给对方服务器，对方服务器拿到二进制字节流后再反序列化成对象，达到远程通信的目的。

聊天协议定义

我们在使用各种聊天APP时，会发各种各样的消息，每种消息都会对应不同的消息格式（即“聊天协议”）。

聊天协议中主要包含几种重要的信息：

    1）消息类型；
    2）发送时间；
    3）消息的收发人；
    4）聊天类型（群聊或私聊）。

私聊消息发送原理

Client1给Client2发消息时，我们需要构建上节中的消息体。

具体就是：from_uid是Client1的uid、to_uid是Client2的uid。

NettyServer收到消息后的处理逻辑是：

    1）解析到to_uid字段；
    2）从SessionMap或者Redis中保存的Session集合中获取to_uid即Client2的Session；
    3）从Session中取出Client2的Channel；
    4）然后将消息通过Client2的Channel发给Client2。

群聊消息发送原理

群聊消息的分发通常有两种技术实现方式，我们一一来看看。

方式一：假设一个群有100人，如果Client1给一个群的所有人发消息，其实相当于Client1分别给其余99人分别发一条消息。我们可以直接在Client端，通过循环，分别给群里的99人发消息即可，相当于Client发送给NettyServer发送了99次相同的消息（除了to_uid不同）。

上述方案有很严重的性能问题：Client1通过循环99次，分别把消息发给NettyServer，NettyServer收到这99条消息后，分别将消息发给群内其余的用户。先抛开移动端的特殊性（比如循环还没完成手机就有可能退到后台被系统挂起），显然Client1到NettyServer的99次循环存在明显不合理地方。

方式二：上节的消息体中to_uid_list字段就是为了解决这个方式一的性能问题的。Client1把群内其余99个Client的uid保存在to_uid_list中，然后NettyServer只发一条消息，NettyServer收到这一条消息后，通过to_uid_list字段解析群内其余99的Client的uid，再通过循环把消息分别发送给群内其余的Client。

可以看到：方式二的群聊时，Client1与NettyServer只进行1次消息传输，相比于方式一，效率提高了50%。

技术关键点1：客户端分别连接在不同IM实例时如何通信？

针对本文中的架构，如果多个Client分别连接在不同的Server上，Client之间应该如何通信呢？

为了回答这个问题，我们首先要明白Session的作用。

我们做过JavaWeb开发的朋友都知道，Session用来保存用户的登录信息。

在IM系统中也是如此：Session中保存用户的Channel信息。当Client与Server建立链接成功后，会产生一个Channel，Client和Server是通过Channel，实现数据传输。当两端链接建立起来后，Server会构建出一个Session对象，保存uid和Channel等信息，并把这个Session保存在一个SessionMap里（NettyServer的内存里），uid为key，我们可以通过uid就可以找到这个uid对应的Session。

但只有SessionMap还不够：我们需要利用Redis，它的作用是保存整个NettyServer集群全部链接成功的用户，这也是一种Session，但这种Session没有保存uid和Channel的对应关系，而是保存Client链接到NettyServer的信息，如Client链接到的这个NettyServer的ip、port等。通过uid，我们同样可以从Redis中拿到当前Client链接到的NettyServer的信息。正是有了这个信息，我们才能做到，NettyServer集群任意节点水平扩容。

当用户量少的时候：我们只需要一台NettyServer节点便可以扛住流量，所有的Client链接到同一个NettyServer上，并在NettyServer的SessionMap中保存每个Client的会话。Client1与Client2通信时，Client1把消息发给NettyServer，NettyServer从SessionMap中取出Client2的Session和Channel，将消息发给Client2。

随着用户量不断增多：一台NettyServer不够，我们增加了几台NettyServer，这时Client1链接到NettyServer1上并在SessionMap和Redis中保存了会话和Client1的链接信息，Client2链接到NettyServer2上并在SessionMap和Redis中保存了会话和Client2的链接信息。Client1给Client2发消息时，通过NettyServer1的SessionMap找不到Client2的会话，消息无法发送，于是便从Redis中获取Client2链接在哪台NettyServer上。获取到Client2所链接的NettyServer信息后，我们可以把消息转发给NettyServer2，NettyServer2收到消息后，从NettyServer2的SessionMap中获取Client2的Session和Channel，然后将消息发送给Client2。

那么：NettyServer1的消息如何转发给NettyServer2呢？答案是通过消息队列，如Redis中的list数据结构。每台NettyServer启动后都需要监听一个自己的Redis中的消息队列，这个队列用户接收其他NettyServer转发给当前NettyServer的消息。