本文介绍: 上一篇中说了一下项目的构成,比较枯燥,一些基本构造方面,这一片呢,一定会更加枯燥。这一篇讲报文协议。后端嘛,不像前端花里胡哨,就是更有内涵一点。为什么这块需要着重说呢,因为聊天系统中需要设计一套保证消息可靠的机制。否则消息都不知道发过去了没有。需要通过报文去保证这些。这些都是需要去设计的。具体设计思路如下。
b站上面本期视频版本,观看视频食用更佳!点击即可跳转,找不到视频可以直接搜索我 目前叫 呆呆呆呆梦
目前已经写的文章有。并且有对应视频版本。
git项目地址 【IM即时通信系统(企聊聊)】点击可跳转
sprinboot单体项目升级成springcloud项目 【第一期】
前端项目技术选型以及页面展示【第二期】
分布式权限 shiro + jwt + redis【第三期】
给为服务添加运维模块 统一管理【第四期】
微服务数据库模块【第五期】
netty与mq在项目中的使用(第六期)】
分布式websocket即时通信(IM)系统构建指南【第七期】
前言
上一篇中说了一下项目的构成,比较枯燥,一些基本构造方面,这一片呢,一定会更加枯燥。这一篇讲报文协议。后端嘛,不像前端花里胡哨,就是更有内涵一点。为什么这块需要着重说呢,因为聊天系统中需要设计一套保证消息可靠的机制。否则消息都不知道发过去了没有。需要通过报文去保证这些。这些都是需要去设计的。具体设计思路如下。
1.如何保证两个用户之间消息可靠
主要有参考这个
IM消息送达保证机制实现
这篇文章有详细明确了一下消息可靠性的保证;
1.1 正常逻辑
这个是正常的发送逻辑。客户A发送给服务器,服务器发送给客户B。这个是之前的逻辑,就是正常的发送逻辑;msg:A用于确认客户端消息发送到服务器。但是在这种逻辑中,客户A是不清楚客户B是否收到消息的;,所以由此引入一个确认机制。
1.2带有确认机制
client-B向im-server发送一个ack请求包,即ack:R
im-server在成功处理后,回复client-B一个ack响应包,即ack:A
则im-server主动向client-A发送一个ack通知包,即ack:N
2.具体实践
声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。