从零开始开发IM(即时通讯)服务端(二)
好消息:IM1.0.0版本已经上线啦,支持特性:
- 私聊发送文本/文件
- 已发送/已送达/已读回执
- 支持使用ldap登录
- 支持接入外部的登录认证系统
- 提供客户端jar包,方便客户端开发
github链接: https://github.com/yuanrw/IM
本篇将带大家从零开始搭建一个轻量级的IM服务端,IM的整体设计思路和架构在我的上篇博客中已经讲过了,没看过的同学请点击从零开始开发IM(即时通讯)服务端 。
这篇将给大家带来更多的细节实现。我将从三个方面来阐述如何构建一个完整可靠的IM系统。
- 可靠性
- 安全性
- 存储设计
可靠性
什么是可靠性?对于一个IM系统来说,可靠的定义至少是不丢消息、消息不重复、不乱序,满足这三点,才能说有一个好的聊天体验。
不丢消息
我们先从不丢消息开始讲起。
首先复习一下上一篇设计的服务端架构:
我们先从一个简单例子开始思考:当Alice给Bob发送一条消息时,可能要经过这样一条链路:
- client-->connecter
- connector-->transfer
- transfer-->connector
- connector-->client
在这整个链路中的每个环节都有可能出问题,虽然tcp协议是可靠的,但是它只能保证链路层的可靠,无法保证应用层的可靠。
例如在第一步中,connector
收到了从client
发出的消息,但是转发给transfer
失败,那么这条消息Bob就无法收到,而Alice也不会意识到消息发送失败了。
如果Bob状态是离线,那么消息链路就是:
- client-->connector
- connector-->transfer
- transfer-->mq
如果在第三步中,transfer
收到了来自connector
的消息,但是离线消息入库失败,
那么这个消息也是传递失败了。
为了保证应用层的可靠,我们必须要有一个ack机制,使发送方能够确认对方收到了这条消息。
具体的实现,我们模仿tcp协议做一个应用层的ack机制。
tcp的报文是以字节(byte)
为单位的,而我们以message
单位。
发送方每次发送一个消息,就要等待对方的ack回应,在ack确认消息中应该带有收到的id以便发送方识别。
其次,发送方需要维护一个等待ack的队列。 每次发送一个消息之后,就将消息和一个计时器入队。
另外存在一个线程一直轮询队列,如果有超时未收到ack的,就取出消息重发。
超时未收到ack的消息有两种处理方式:
- 和tcp一样不断发送直到收到ack为止。
- 设定一个最大重试次数,超过这个次数还没收到ack,就使用失败机制处理,节约资源。例如如果是
connector
长时间未收到client
的ack,那么可以主动断开和客户端的连接,剩下未发送的消息就作为离线消息入库,客户端断连后尝试重连服务器即可。
不重复、不乱序
有的时候因为网络原因可能导致ack收到较慢,发送方就会重复发送,那么接收方必须有一个去重机制。
去重的方式是给每个消息增加一个唯一id。这个唯一id并不一定是全局的,只需要在一个会话中唯一即可。例如某两个人的会话,或者某一个群。如果网络断连了,重新连接后,就是新的会话了,id会重新从0开始。
接收方需要在当前会话中维护收到的最后一个消息的id,叫做lastId
。
每次收到一个新消息, 就将id与lastId
作比较看是否连续,如果不连续,就放入一个暂存队列 queue中稍后处理。
例如:
当前会话的
lastId
=1,接着服务器收到了消息msg(id=2)
,可以判断收到的消息是连续的,就处理消息,将lastId
修改为2。但是如果服务器收到消息
msg(id=3)
,就说明消息乱序到达了,那么就将这个消息入队,等待lastId
变为2后,(即服务器收到消息msg(id=2)
并处理完了),再取出这个消息处理。
因此,判断消息是否重复只需要判断msgId>lastId && !queue.contains(msgId)
即可。如果收到重复的消息,可以判断是ack未送达,就再发送一次ack。
接收方收到消息后完整的处理流程如下:
伪代码如下:
class ProcessMsgNode{
/**
* 接收到的消息
*/
private Message message;
/**
* 处理消息的方法
*/
private Consumer<Message> consumer;
}
public CompletableFuture<Void> offer(Long id,Message message,Consumer<Message> consumer) {
if (isRepeat(id)) {
//消息重复
sendAck(id);
return null;
}
if (!isConsist(id)) {
//消息不连续
notConsistMsgMap.put(id, new ProcessMsgNode(message, consumer));
return null;
}
//处理消息
return process(id, message, consumer);
}
private CompletableFuture<Void> process(Long id, Message message, Consumer<Message> consumer) {
return CompletableFuture
.runAsync(() -> consumer.accept(message))
.thenAccept(v -> sendAck(id))
.thenAccept(v -> lastId.set(id))
.thenComposeAsync(v -> {
Long nextId = nextId(id);
if (notConsistMsgMap.containsKey(nextId)) {
//队列中有下个消息
ProcessMsgNode node = notConsistMsgMap.get(nextId);
return process(nextId, node.getMessage(), consumer);
} else {
//队列中没有下个消息
CompletableFuture<Void> future = new CompletableFuture<>();
future.complete(null);
return future;
}
})
.exceptionally(e -> {
logger.error("[process received msg] has error", e);
return null;
});
}
安全性
无论是聊天记录还是离线消息,肯定都会在服务端存储备份,那么消息的安全性,保护客户的隐私也至关重要。
因此所有的消息都必须要加密处理。
在存储模块里,维护用户信息和关系链有两张基础表,分别是im_user
用户表和im_relation
关系链表。
im_user
表用于存放用户常规信息,例如用户名密码等,结构比较简单。im_relation
表用于记录好友关系,结构如下:
CREATE TABLE `im_relation` (
`id` bigint(20) COMMENT '关系id',
`user_id1` varchar(100) COMMENT '用户1id',
`user_id2` varchar(100) COMMENT '用户2id',
`encrypt_key` char(33) COMMENT 'aes密钥',
`gmt_create` timestamp DEFAULT CURRENT_TIMESTAMP,
`gmt_update` timestamp DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
UNIQUE KEY `USERID1_USERID2` (`user_id1`,`user_id2`)
);
user_id1
和user_id2
是互为好友的用户id,为了避免重复,存储时按照user_id1
<user_id2
的顺序存,并且加上联合索引。encrypt_key
是随机生成的密钥。当客户端登录时,就会从数据库中获取该用户的所有的relation
,存在内存中,以便后续加密解密。- 当客户端给某个好友发送消息时,取出内存中该关系的密钥,加密后发送。同样,当收到一条消息时,取出相应的密钥解密。
客户端完整登录流程如下:
- client调用rest接口登录。
- client调用rest接口获取该用户所有
relation
。 - client向connector发送greet消息,通知上线。
- connector拉取离线消息推送给client。
- connector更新用户session。
那为什么connector要先推送离线消息再更新session呢?我们思考一下如果顺序倒过来会发生什么:
- 用户
Alice
登录服务器 connector
更新session- 推送离线消息
- 此时Bob发送了一条消息给Alice
如果离线消息还在推送的过程中,Bob发送了新消息给Alice,服务器获取到Alice的session,就会立刻推送。这时新消息就有可能夹在一堆离线消息当中推过去了,那这时,Alice收到的消息就乱序了。
而我们必须保证离线消息的顺序在新消息之前。
那么如果先推送离线消息,之后才更新session。在离线消息推送的过程中,Alice的状态就是“未上线”,这时Bob新发送的消息只会入库im_offline
,im_offline
表中的数据被读完之后才会“上线”开始接受新消息。这也就避免了乱序。
存储设计
存储离线消息
当用户不在线时,离线消息必然要存储在服务端,等待用户上线再推送。理解了上一个小节后,离线消息的存储就非常容易了。增加一张离线消息表im_offline
,表结构如下:
CREATE TABLE `im_offline` (
`id` int(11) COMMENT '主键',
`msg_id` bigint(20) COMMENT '消息id',
`msg_type` int(2) COMMENT '消息类型',
`content` varbinary(5000) COMMENT '消息内容',
`to_user_id` varchar(100) COMMENT '收件人id',
`has_read` tinyint(1) COMMENT '是否阅读',
`gmt_create` timestamp COMMENT '创建时间',
PRIMARY KEY (`id`)
);
msg_type
用于区分消息类型(chat
,ack
),content
加密后的消息内容以byte数组的形式存储。
用户上线时按照条件to_user_id=用户id
拉取记录即可。
防止离线消息重复推送
我们思考一下多端登录的情况,Alice有两台设备同时登陆,在这种并发的情况下,我们就需要某种机制来保证离线消息只被读取一次。
这里利用CAS机制来实现:
- 首先取出所有
has_read=false
的字段。 - 检查每条消息的
has_read
值是否为false,如果是,则改为true。这是原子操作。
update im_offline set has_read = true where id = ${msg_id} and has_read = false
- 修改成功则推送,失败则不推送。
相信到这里,同学们已经可以自己动手搭建一个完整可用的IM服务端了。更多问题欢迎评论区留言~~
IM1.0.0版本已上线,github链接:
https://github.com/yuanrw/IM
觉得对你有帮助请点个star吧~!
从零开始开发IM(即时通讯)服务端(二)的更多相关文章
- 使用tomcat方式实现websocket即时通讯服务端讲解
使用tomcat方式实现websocket即时通讯服务端讲解 第一种方案:使用Tomcat的方式实现 tomcat版本要求:tomcat7.0+.需要支持Javaee7 导入javeee-api的ja ...
- [iOS]从零开始开发一个即时通讯APP
前言 这是我的毕业设计.刚开始确定这个课题的时候是因为以前有稍微研究过一些XMPP协议,在这个基础上做起来应该不难.然后开始选技术的时候还有半年,我想为什么不从更底层做起呢!那就不用XMPP,当时接触 ...
- Golang 在电商即时通讯服务建设中的实践
马蜂窝技术原创文章,更多干货请搜索公众号:mfwtech 即时通讯(IM)功能对于电商平台来说非常重要,特别是旅游电商. 从商品复杂性来看,一个旅游商品可能会包括用户在未来一段时间的衣.食.住.行等 ...
- .net平台 基于 XMPP协议的即时消息服务端简单实现
.net平台 基于 XMPP协议的即时消息服务端简单实现 昨天抽空学习了一下XMPP,在网上找了好久,中文的资料太少了所以做这个简单的例子,今天才完成.公司也正在准备开发基于XMPP协议的即时通讯工具 ...
- 使用GSoap开发WebService客户端与服务端
Gsoap 编译工具提供了一个SOAP/XML 关于C/C++ 语言的实现, 从而让C/C++语言开发web服务或客户端程序的工作变得轻松了很多. 用gsoap开发web service的大致思路 我 ...
- C#开发BIMFACE系列4 服务端API之源上传文件
在注册成为BIMFACE的应用开发者后,要能在浏览器里浏览你的模型或者获取你模型内的BIM数据, 首先需要把你的模型文件上传到BIMFACE.根据不同场景,BIMFACE提供了丰富的文件相关的接口. ...
- C#开发BIMFACE系列3 服务端API之获取应用访问凭证AccessToken
系列目录 [已更新最新开发文章,点击查看详细] BIMFACE 平台为开发者提供了大量的服务器端 API 与 JavaScript API,用于二次开发 BIM 的相关应用. BIMFACE ...
- C#开发BIMFACE系列15 服务端API之获取模型的View token
系列目录 [已更新最新开发文章,点击查看详细] 在<C#开发BIMFACE系列3 服务端API之获取应用访问凭证AccessToken>中详细介绍了应用程序访问API的令牌凭证.我 ...
- C#开发BIMFACE系列40 服务端API之模型集成
BIMFACE二次开发系列目录 [已更新最新开发文章,点击查看详细] 随着建筑信息化模型技术的发展,越来越多的人选择在云端浏览建筑模型.现阶段的云端模型浏览大多是基于文件级别,一次只可以浏览一 ...
- C#开发BIMFACE系列41 服务端API之模型对比
BIMFACE二次开发系列目录 [已更新最新开发文章,点击查看详细] 在建筑施工图审查系统中,设计单位提交设计完成的模型/图纸,审查专家审查模型/图纸.审查过程中如果发现不符合规范的地方,则流 ...
随机推荐
- Docker最简单入门之(二)——简单使用Docker
0.前言 本章主要写一些怎么使用Docker,拉取镜像和创建容器等之类的Docker的常用基本操作.在开始写之前,大家需要明白一下几个名词的含义 1.镜像:镜像是指一个类似于安装包的东西,尝试安装过电 ...
- Kubernetes Pod 驱逐详解
原文链接:Kubernetes Pod 驱逐详解 在 Kubernetes 中,Pod 使用的资源最重要的是 CPU.内存和磁盘 IO,这些资源可以被分为可压缩资源(CPU)和不可压缩资源(内存,磁盘 ...
- 章节十五、8-配置文件File Logging
一.如何将log输出到文件中? 1.配置xml文件 <?xml version="1.0" encoding="UTF-8"?> <Confi ...
- Hadoop - YARN Introduce
YARN Introduce 1. MapReduce1.0缺陷 (1)存在单点故障 (2)JobTracker"大包大揽"导致任务过重(任务多时内存开销大,上限4000节点) ( ...
- 《机器学习技法》---AdaBoost算法
1 AdaBoost的推导 首先,直接给出AdaBoost算法的核心思想是:在原数据集上经过取样,来生成不同的弱分类器,最终再把这些弱分类器聚合起来. 关键问题有如下几个: (1)取样怎样用数学方式表 ...
- Javascript十大排序算法的实现方法
上一篇中,实现了Javascript中的冒泡排序方法,下面把剩余的九种排序算法实现 选择排序: var array = []; for(var i=0;i<100000;i++){ var x ...
- MYSQL--表与表之间的关系、修改表的相关操作
表与表之间的操作: 如果所有信息都在一张表中: 1.表的结构不清晰 2.浪费硬盘空间 3.表的扩展性变得极差(致命的缺点) 确立表与表之间的关系.一定要换位思考(必须在两者考虑清楚之后才能得出结论) ...
- DRF (Django REST framework) 中的Request 与 Response
DRF中的Request 与 Response 1. Request - REST framework 传入视图的request对象不再是Django默认的HttpRequest对象,而是REST f ...
- restapi(5)- rest-mongo 应用实例:分布式图片管理系统之一,rest 服务
最近有同事提起想把网页上的图片存在MongoDB里,我十分赞同.比起把图片以文件形式存放在硬盘子目录的方式,MongoDB有太多的优势.首先,MongoDB是分布式数据库,图片可以跨服务器存储.在一个 ...
- C#/Java 动态生成电子发票
电子发票是电商时代的产物,PDF发票是最常见的电子发票之一.在这篇文章中,我将给大家分享一个免费的动态生成PDF电子发票的C#方案,并在文章末尾附上Java解决方案. 典型的发票包含客户和供应商的名称 ...