架构说明：
1）CIM 中的各个组件均采用 SpringBoot 构建；2）采用 Netty + Google Protocol Buffer 构建底层通信；3）Redis 存放各个客户端的路由信息、账号信息、在线状态等；4）Zookeeper 用于 IM-server 服务的注册与发现。
整体主要由以下模块组成：
1）cim-server——IM 服务端：用于接收 client 连接、消息透传、消息推送等功能。支持集群部署；2）cim-forward-route——消息路由服务器：用于处理消息路由、消息转发、用户登录、用户下线以及一些运营工具（获取在线用户数等）；3）cim-client——IM 客户端：给用户使用的消息终端，一个命令即可启动并向其他人发起通讯（群聊、私聊）；同时内置了一些常用命令方便使用。
流程解释如下：
1）客户端向 route 发起登录；2）登录成功从 Zookeeper 中选择可用 IM-server 返回给客户端，并保存登录、路由信息到 Redis；3）客户端向 IM-server 发起长连接，成功后保持心跳；4）客户端下线时通过 route 清除状态信息。
所以当我们自己部署时需要以下步骤：
1）搭建基础中间件 Redis、Zookeeper；2）部署 cim-server，这是真正的 IM 服务器，为了满足性能需求所以支持水平扩展，只需要注册到同一个 Zookeeper 即可；3）部署 cim-forward-route，这是路由服务器，所有的消息都需要经过它。由于它是无状态的，所以也可以利用 Nginx 代理提高可用性；4）cim-client 真正面向用户的客户端；启动之后会自动连接 IM 服务器便可以在控制台收发消息了。
这里就设计的比较简单，直接利用 Redis 来存储用户信息；用户信息也只有 ID 和 userName 而已。只是为了方便查询在 Redis 中的 KV 又反过来存储了一份 VK，这样 ID 和 userName 都必须唯一。
具体的流程：
1）登录成功之后需要判断是否是重复登录（一个用户只能运行一个客户端）；2）登录成功后需要从 Zookeeper 中获取服务列表（cim-server）并根据某种算法选择一台服务返回给客户端；3）登录成功之后还需要保存路由信息，也就是当前用户分配的服务实例保存到 Redis 中。
为了实现只能一个用户登录，使用了 Redis 中的 set 来保存登录信息；利用 userID 作为 key ，重复的登录就会写入失败。
1）先从 Zookeeper 获取所有的服务实例做一个内部缓存；2）轮询选择一台服务器（目前只有这一种算法，后续会新增）。即时通讯聊天软件app开发可以加小蓝豆的v：weikeyun24咨询即可
当然要获取 Zookeeper 中的服务实例前自然是需要监听 cim-server 之前注册上去的那个节点。
这是一个真正发消息的接口，实现的效果就是其中一个客户端发消息，其余所有客户端都能收到！流程肯定是客户端发送一条消息到服务端，服务端收到后在上文介绍的 SessionSocketHolder 中遍历所有 Channel（通道）然后下发消息即可。服务端是单机倒也可以，但现在是集群设计。所以所有的客户端会根据之前的轮询算法分配到不同的 cim-server 实例中。
由于 Redis 单线程的特质，当数据量大时；一旦使用 keys 匹配所有 cim-route:* 数据，会导致 Redis 不能处理其他请求。所以这里改为使用 scan 命令来遍历所有的 cim-route:*。
接着会挨个调用每个客户端所在的服务端的 HTTP 接口用于推送消息。
之所以说获取在线用户是一个辅助接口，其实就是用于辅助私聊使用的。一般我们使用私聊的前提肯定得知道当前哪些用户在线，接着你才会知道你要和谁进行私聊。
所以私聊接口在收到消息后需要查询到接收者所在的 cim-server 实例信息，后续的步骤就和群聊一致了。调用接收者所在实例的 HTTP 接口下发信息。只是群聊是遍历所有的在线用户，私聊只发送一个的区别。
