前言
如何设计一款高性能，高并发以及高可用的im消息沟通平台是很多公司发展过程中必须要碰到并且解决的问题，如一家公司内部的通信，各个互联网平台的客服咨询，都是离不开一款好用并且方便维护的im消息沟通系统。那么我们应该怎么样来设计一款三高特性的im系统，并能支持各个业务线接入（内部oa通信，客服咨询，消息推送）等功能呢。
下面就由我来介绍一下我所负责im消息沟通系统所经历的设计历程；
im第一版设计
im第一版设计的初衷是公司需要一款im消息中间件用于支撑客服咨询业务，但是为了方便日后其他业务线也能接入消息沟通平台，所以将整个消息中心的能力需要给到中间件团队进行开发，各业务线接入消息沟通中心实现消息实时触达的能力。
im初版架构介绍
im消息中心初版架构图
存储端在存储端我们使用tidb,redis作为主要存储，redis用于存储消息已读未读，缓存连接信息等功能，tidb作为开源的分布式数据库，选择它是为了方便消息的存储；
mq消息总线我们使用rocketmq来实现消息总线，消息总线是整个im的核心，使用rocketmq能支持十万级别的tps。基本所有服务都要从消息总线中消费消息进行业务处理；
zookeeper注册中心服务会注册到zk中，方便服务之间内部进行调用，同样也可以暴露服务给外部进行调用；
link服务link服务主要用于接收客户端的ws,tcp,udp等协议的连接，调用用户服务进行认证，并投递连接成功的消息给位置服务进行消费，存储连接信息。ws过来的消息先到link再投递到消息总线；
消息分发服务消息分发服务主要用于接收消息总线推过来的消息进行处理，按照im内部消息协议构造好消息体后又推送到消息总线中，比如会推给会话服务、消息盒子、link服务；
位置服务存储link的ws连接，tcp连接等信息，并使用redis进行缓存,key为userId，方便根据UserId查询到该用户所登录的客户端连接在哪个link上。一个用户在相同设备只能登录一个，可以多端登录；
用户服务用于存储所有用户，提供认证查询接口；
消息盒子存储所有消息，提供消息查询，消息已读未读，消息未读数，消息检索等功能；
会话服务管理会话，群聊会话，单聊会话等功能。
整体流程
im消息中心初版时序图
该设计存在的问题思考
在上面的架构设计中，我们详细介绍了初版系统架构的设计思路以及具体流程，那么在初版设计中存在什么样的问题，又该如何优化呢？
link服务到消息分发服务的消息推送使用消息总线。
初版架构设计中，link服务将消息下推给消息分发服务进行处理使用的mq消息总线，使用mq消息总线会有一定的时延。a用户发送消息到link--消息总线--消息分发服务--消息总线--link--b用户这个流程太长，并且大大降低系统吞吐量
消息落库为写扩散。
其实现阶段我们使用的