毕业设计-基于Netty高可用分布式即时通讯系统支持长连接网关管理单聊群聊离线消息消息推送消息消息已读未读消息未.zip

## FastIM > 🚀基于Netty高可用分布式即时通讯系统，支持长连接网关管理、单聊、群聊、离线消息、消息推送消息、消息已读未读、消息未读数、红包、消息漫游等功能，支持集群部署的分布式架构。 ## 一、功能 * [ ] 单聊 * [ ] 群聊 * [ ] 心跳保活重连 * [ ] 消息未读计数 * [x] [客户端SDK](#客户端SDK) * [x] [消息服务SDK](#消息服务SDK) * [ ] 长连接网关 * [ ] 短连接网关 * [ ] 消息漫游 * [ ] 消息加密 * [ ] 红包消息 * [ ] 消息已读 ## 二、系统设计 ### 1. IM架构图 基于可扩展性高可用原则，把网关层、逻辑层、数据层分离，并且支持分布式部署  ### 2. 架构设计 #### 2.0 CLIENT设计： 1. client每个设备会在本地存每一个会话，保留有最新一条消息的顺序 ID 2. 为了避免client宕机，也就是退出应用，保存在内存的消息ID丢失，会存到本地的文件中 3. client需要在本地维护一个等待ack队列，并配合timer超时机制，来记录哪些消息没有收到ack：N，以定时重发。 4. 客户端本地生成一个递增序列号发送给服务器，用作保证发送顺序性。该序列号还用作ack队列收消息时候的移除。 #### 2.1 LSB设计与优化： ##### 2.1.0 LSB设计 1. 接入层的高可用、负载均衡、扩展性全部在这里面做 2. 客户端通过LSB，来获取gate IP地址，通过IP直连，目的是 - 灵活的负载均衡策略 可根据最少连接数来分配IP - 做灰度策略来分配IP - AppId业务隔离策略 不同业务连接不同的gate，防止相互影响 - 单聊和群聊的im接入层通道分开 ##### 2.1.1 LSB优化 问题背景：当某个实例重启后，该实例的连接断开后，客户端会发起重连，重连就大概率转移其他实例上，导致最近启动的实例连接数较少，最早启动的实例连接数较多 解决方法： 1. 客户端会发起重连，跟服务器申请重连的新的服务器IP，系统提供合适的算法来平摊gate层的压力，防止雪崩效应。 2. gate层定时上报本机的元数据信息以及连接数信息，提供给LSB中心，LSB根据最少连接数负载均衡实现，来计算一个节点供连接。 #### 2.2 GATE设计： GATE层网关有以下特性： 1. 任何一个gate网关断掉，用户端检测到以后重新连接LSB服务获取另一个gate网关IP，拿到IP重新进行长连接通信。对整体服务可靠性基本没有影响。 2. gate可以无状态的横向部署，来扩展接入层的接入能力 3. 根据协议分类将入口请求打到不同的网关上去，HTTP网关接收HTTP请求，TCP网关接收tcp长连接请求 4. 长连接网关，提供各种监控功能，比如网关执行线程数、队列任务数、ByteBuf使用堆内存数、堆外内存数、消息上行和下行的数量以及时间 #### 2.3 LOGIC和路由SDK设计： 1. logic按照分布式微服务的拆分思想进行拆分，拆分为多个模块，集群部署： - 消息服务 - 红包服务 - 其他服务 2. logic消息服务集成路由客户端SDK，SDK职责： - 负责和网关底层通信交互 - 负责网关服务寻址 - 负责存储uid和gate层机器ID关系（有状态：多级缓存避免和中间件多次交互。无状态：在业务初期可以不用存） - 配合网关负责路由信息一致性保证 - 如果路由状态和channel通道不一致，比如有路由状态，没有channel通道（已关闭）那么，就会走离线消息流出，并且清除路由信息 - 动态重启gate，会及时清理路由信息 3. SDK和网关底层通信设计：  - 网关层到服务层，只需要单向传输发请求，网关层不需要关心调用的结果。而客户端想要的ack或者notify请求是由SDK发送数据到网关层，SDK也不需要关心调用的结果，最后网关层只转发数据，不做额外的逻辑处理 - SDK和所有的网关进行长连接，当发送信息给客户端时，根据路由寻址信息，即可通过长连接推送信息 ### 3. 协议设计 #### 3.0 目标 1. 高性能：协议设计紧凑，保证数据包小，并且序列化性能好 2. 可扩展性：针对后续业务发展，可以自由的自定义协议，无需较大改动协议结构 #### 3.1 设计 IM协议采用二进制定长包头和变长包体来实现客户端和服务端的通信，并且采用谷歌protobuf序列化协议，设计如下：  各个字段如下解释： - headData：头部标识，协议头标识，用作粘包半包处理。4个字节 - version：客户端版本。4个字节 - cmd：业务命令，比如心跳、推送、单聊、群聊。1个字节 - msgType：消息通知类型 request response notify。1个字节 - logId：调试性日志，追溯一个请求的全路径。4个字节 - sequenceId：序列号，可以用作异步处理。4个字节 - dataLength：数据体的长度。4个字节 - data：数据 #### 3.2 实践 1. 针对数据data，**网关gate层不做反序列化，反序列化步骤在service做**，避免重复序列化和反序列化导致的性能损失 2. 网关层不做业务逻辑处理，只做消息转发和推送，减少网关层的复杂度 ### 4. 安全管理 1. 为防止消息传输过程中不被截获、篡改、伪造，采用TLS传输层加密协议 2. 私有化协议天然具备一定的防窃取和防篡改的能力，相对于使用JSON、XML、HTML等明文传输系统，被第三方截获后在内容破解上相对成本更高，因此安全性上会更好一些 3. 消息存储安全性:针对账号密码的存储安全可以通过“高强度单向散列算法”和“加盐”机制来提升加密密码可逆性；IM消息采用“端到端加密”方式来提供更加安全的消息传输保护。 4. 安全层协议设计。基于动态密钥，借鉴类似SSL，不需要用证书来管理。 ### 5. 消息流转设计 一个正常的消息流转需要如图所示的流程：  1. 客户端A发送请求包R 2. server将消息存储到DB 3. 存储成功后返回确认ack 4. server push消息给客户端B 5. 客户端B收到消息后返回确认ack 6. server收到ack后更新消息的状态或者删除消息 需要考虑的是，一个健壮的系统需要考虑各种异常情况，如丢消息，重复消息，消息时序问题 #### 5.0 消息可靠性如何保证 不丢消息 1. 应用层ACK 2. 客户端需要超时与重传 3. 服务端需要超时与重传，具体做法就是增加ack队列和定时器Timer 4. 业务侧兜底保证，客户端拉消息通过一个本地的旧的序列号来拉取服务器的最新消息 5. 为了保证消息必达，在线客户端还增加一个定时器，定时向服务端拉取消息，避免服务端向客户端发送拉取通知的包丢失导致客户端未及时拉取数据。 #### 5.1 消息重复性如何保证 不重复 1. 超时与重传机制将导致接收的client收到重复的消息，具体做法就是一份消息使用同一个消息ID进行去重处理。 #### 5.2 消息顺序性如何保证 不乱序 ##### 5.2.0 消息乱序影响的因素 1. 时钟不一致，分布式环境下每个机器的时间可能是不一致的 2. 多发送方和多接收方，这种情况下，无法保先发的消息被先收到 3. 网络传输和多线程，网络传输不稳定的话可能导致包在数据传输过程中有的慢有的快。多线程也可能是会导致时序不一致影响的因素 以上，如果保持绝对的实现，那么只能是一个发送方，一�