要想成功，你必须自我制造机会，绝不能愚蠢地坐在路边，等待有人经过，邀请你同往财富与幸福之路 —— 歌夫
Netty 案例之 IM 方案设计
背景
IM 系统非常的常见了，比如我们日常用的聊天工具，QQ、微信、各种商城的客服聊天、抖音快手直播等等、都属于IM系统的一个范畴的
IM系统看着简单，但是也是非常多的技术的综合应用，比如网路编程、服务端开发、高并发、高可用还有移动端的开发等等很多个技术栈的应用才创建出IM系统，对于IM开发入门来说也是比较难的，也没有什么系统的学习资料什么的，而且Netty 这种工具也没有什么文档，并且封装的特别的厉害，所以我们接下来要系统的学习一下Netty实现的IM系统简易的实现一下，主要是为了熟悉并掌握Netty，后续还会根据案例进行相应的源码分析
本文会带你快速的了解一个主流的IM的应用场景和架构、以及技术特点和功能引领你对IM系统有一个认知
应用场景
IM其实不仅仅只有QQ、微信这种聊天工具软件，比如斗鱼直播、消息推送、新浪微博、等都会应用到IM技术，但是我们主要学习的方向就是IM的简单实现，主要是为了了解和掌握Netty的使用操作，之后后续会想写的介绍实战中的IM消息的推送方案和代码实现
单聊方案实现
需求分析
单聊的需求就是用户A发消息给用户B，用户B收到消息给用户A进行消息的回复操作，也就是经典的点对点操作
方案设计
我们想象一下就应该知道，不可能让两个手机直连，那么手机就是作为服务器和客户端两个角色了，但是如果你想像一下，一个手机有成千上百个好友，那么你要维持与成千上百个好友的连接，那是不可能的手机根本就没有那么高的性能，所以这种方式是不现实的，所以架构方案应该是有一个中间处理的服务端，所有的客户端之间的消息发送都是有一个中间的服务端进行代理的
比如用户A发消息给用户B:
- 第一步：用户A发送消息给服务器端
- 第二步：服务端解析用户A的消息中的目标客户端地址
- 第三步：服务端将用户A的消息通过目标客户端地址将消息发送给用户B
- 第四步：用户B 解析服务端发送过来的消息并输出
简单逻辑图
详细逻辑实现图
- 用户登陆发起请求连接后将自己的信息发送到服务端，服务端会将用户的ID和通道信息进行维护一张映射信息表：{用户A ID -> 对应连接通道信息,用户B ID -> 对应连接通道信息}
- 用户发送消息后，服务器去拉取之前维护的用户连接列表之后找到目标信息对应的记录，将消息通过建立好的连接通道发送给客户端
群聊方案实现
需求分析
用户A 发消息给群聊1，此时那么群聊1中的所有用户都会接收到用户A发过来的消息
方案设计
其实群聊和单聊的方案实现差不多的，都是需要一个中间的服务端进行消息的转发操作，唯一的差别就是需要通过服务端先寻找群聊的操作，之后在便利群聊中的所有成员，一一的给这些成员进行消息转发操作
用户A给群聊1发消息：
- 用户A 发消息给服务端
- 服务端解析用户A的消息指令，如果目标是群聊，那么进行群聊查找
- 遍历群聊里面的客户端将用户A的消息逐一转发给群聊中的客户端
- 群聊中的客户端收到消息将消息显示出来
简单逻辑图
详细逻辑实现图
- 用户登陆发起请求连接后将自己的信息发送到服务端，服务端会将用户的ID和通道信息进行维护一张映射信息表：{用户A ID -> 对应连接通道信息,用户B ID -> 对应连接通道信息}
- 如果创建的群聊的话，那么群聊有群聊的唯一信息【群聊ID】，群聊里面维护着当前群聊下面所有客户端的连接通道信息{群聊1 ID -> {用户A ID -> 对应的通道信息,用户A ID -> 对应的通道信息}}
- 如果用户A发送了一条消息给群聊的话，服务端会解析用户A的消息内容，解析出来群聊信息ID，之后拉取维护的群聊信息映射表，找出所要发送的群信息里面的所有连接通道，将消息通过通道发送给群里面的客户端【这里记得要将自己的通道进行排除】
IM系统需要解决的问题
- 离线消息如何处理
- 如何保证消息的实时性和准确性
- 如何保证消息的时序性
- 如何保证消息不丢失、不重复
- 如何保证多点登陆消息同步的问题
- 设备登陆的时候是进行消息的拉取还是服务器的推送
- 消息发送失败重试机制
- 客户端掉线如何重新连接、心跳机制
小结
到这里我们就已经实现了简易的IM系统设计，包括了最核心的两个功能一个是单聊一个是群聊，都是通过服务端进行的消息处理，但是虽说我们方案实现了，但是想要应用到生产环境还是会有很多问题的，除了上面遇到的问题还有很多其他的问题，比如分布式系统下客户端掉线怎么办，客户端的连接通道如何处理等等后续都会有详细的方案解决，下一篇实现单聊系统IM
我正在参与掘金技术社区创作者签约计划招募活动，点击链接报名投稿