To be successful, you must create opportunities for yourself, never sit on the side of the road foolishly, waiting for someone to pass by and invite you to the path of wealth and happiness - Gopher
IM scheme design of Netty case
background
IM systems are very common, such as our daily chat tools, QQ, WeChat, customer service chat in various shopping malls, Douyin Kuaishou live broadcast, etc. IM systems that belong to a category of
IM systems look simple, but they are also very The comprehensive application of many technologies, such as network programming, server development, high concurrency, high availability, and mobile terminal development, etc., can create an IM system by applying many technology stacks, which is also difficult for getting started with IM development. , there is no systematic learning materials, and Netty has no documentation, and the packaging is particularly powerful, so we will systematically learn about the simple implementation of the IM system implemented by Netty, mainly for the purpose of Familiar with and master Netty , and follow-up will conduct corresponding source code analysis according to the case.
This article will take you to quickly understand the application scenarios and architecture of a mainstream IM, as well as the technical characteristics and functions to lead you to have an understanding of the IM system
Application scenarios
In fact, IM is not only limited to QQ, WeChat and other chatting tool software, such as Douyu live broadcast, message push, Sina Weibo, etc. will be applied to IM technology, but our main learning direction is the simple implementation of IM, mainly to understand and Master the operation of Netty, and then I will write an introduction to the push scheme and code implementation of IM messages in actual combat.
Single chat solution implementation
demand analysis
The requirement of a single chat is that user A sends a message to user B, and user B receives the message and sends the message to user A to reply to the message, which is a classic point-to-point operation.
Design
我们想象一下就应该知道，不可能让两个手机直连，那么手机就是作为服务器和客户端两个角色了，但是如果你想像一下，一个手机有成千上百个好友，那么你要维持与成千上百个好友的连接，那是不可能的手机根本就没有那么高的性能，所以这种方式是不现实的，所以架构方案应该是有一个中间处理的服务端，所有的客户端之间的消息发送都是有一个中间的服务端进行代理的
比如用户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
我正在参与掘金技术社区创作者签约计划招募活动，点击链接报名投稿