im设计分享

为公司开发了即时消息服务，分享一下

整个im架构如图

im-broker
1.负责维护客户端连接
2.侦测到设备登录或离线，推送消息到rabbitMQ
3.收到客户端消息后上报给rabbitMQ
4.接收从im-api传过来的数据，推送给客户端
im-api
负责维护所有的客户端登录im-broker数据
通过接收rabbitMQ消息来接收客户端的请求，处理请求并回复给im-broker

扩展性分析
im-broker采用目前最流行的nio架构，只处理消息流的上传和下推，不处理具体的业务，单机处理链接能到上百万，如果达到上百万后，可以在im-broker前面用lvs做一个负载均衡，后面接上n台im-broker，可以支持任意数量的客户端，目前线上部署的时候，就部署了2台im-broker

im-api作为消息的消费者，可以部署无限多台服务器，不存在瓶颈

rabbitMQ负责im-broker消息的转发，如果消息数太多的话，需要换成能力更强的rocketMQ或是Pulsar等吞吐量更大的MQ，迁移成本也不高，目前rabbitMQ足够了

polarDB负责存储业务数据，最多扩展至16个计算节点，性能足够，如果支持到微信那个体量，还是靠分库分表来解决

redis我们用的是阿里云的redis服务，扩展性很好，不存在瓶颈，设计数据的时候，就已经限制了单个key对应的set的大小