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