IM聊天系统架构实现

一、IM系统整体架构

二、企业级IM系统如何实现心跳与断线重连机制；

        1、重连机制（服务端下线）

                服务端下线，客户端netty可以感知到，在感知的方法中进行重连的操作，注意重连可能连接到旧的服务器继续报错，延迟重试处理（Zk有延迟）；重连就是清楚老的redis中的旧数据，重新放入新的链接信息；

        2、重连机制(客户段下线)

                客户端下线，服务端netty同样可以感知到，当服务端下线清除链接信息以及redis信息；

        3、心跳机制（保活）

                心跳机制主要目的是为了保活，客户端要不断地向服务端发送心跳机制，让服务端知道客户端的状态；

                客户端启动时加上心跳handler，规定时间内没有发送心跳，回调触发发送心跳事件；

                服务端同样也是加上心跳机制handler，规定时间内客户端没有发送心跳，触发检测事件，判断是否大于规定时间，是则下线客户端；

三、IM系统数据持久化（使用mq削峰）

        千万用户在线，数据库QPS1w已经算是不错的服务器了；千万用户发送消息，mysql很难平稳处理；

四、消息丢失的处理

        服务端网络不通，客户端消息体添加感叹号用户重发操作；

        Mq消息丢失，参考Mq消息丢失处理

五、消息去重

        客户端生成每条消息的唯一id，发送时携带消息id；服务端做幂等处理；

六、离线消息（未读消息）的拉去

        用户上线后拉去未读消息，频繁拉去未读消息，单独启动离线服务，离线服务也消费mq消息，将数据同步到缓存中；拉去未读消息去离线服务中的缓存拉去；为了防止数量过多的离线消息存储在redis中（可以使用Zeset数据类型，根据id进行排序），可以只存储最新的部分离线消息；

七、海量聊天数据存储

        1、冗余索引表（空间换时间）：所谓冗余索引表，其实是将消息宽表数据冗余在一张表中，当只需要部分关系信息时，只查询冗余的索引表，根据mysqlB+树的索引结构，当数据量越小时，存储同样的数据层级结构越小；

        2、分库分表：根据用户冗余索引表的查询条件，节后人id以及发送人id 进行Hash取值分库分表设计；

        3、历史数据归档：将超过三个月或更久的数据进行归档，放到新的归档数据库中，查询历史消息时查询历史消息服务信息；根据时间匹配不通的归档数据库；

八、群聊消息写扩散

        群消息只存储消息体本身的内容，再创建一张关于此消息每个人的接收消息表的情况，可以记录每个用户的id以及用户读取消息的状态；类似于微博的动态流的组建；

九、万人群聊功能设计

        万人群聊系统问题：

                一个人发消息需要查询redis1w次将消息推送给这一万个人 ；100条消息需要操作100w次；一个群就有这么多的操作更何况还有很多群，消息未读数的处理；

                 解决方案：未读书可以在内存中加减，批量同步；

                网关层缓存路由信息；

                直接将消息推向所有netty集群的所有节点，各个节点自己去判断是否有对应的用户连接再判断是否需要发送；（或者推向mq各个netty去监听消息自己处理）

十、千万级直播间消息推送

        千万级直播间消息如果有很多的话：丢失些消息也无所谓 ，没有人能看得完，结合业务场景处理；