即时通讯项目

NingDream816

已于 2024-12-04 16:57:21 修改

阅读量1.1k

点赞数 30

文章标签：即时通讯项目网络 redis 数据库服务器缓存设计模式

于 2024-06-25 10:17:37 首次发布

本文链接：https://blog.csdn.net/weixin_51332735/article/details/139909691

版权

需求设计

1 目标和挑战

1.1 目标

分布式IM即时通讯系统的目标包含：实时通讯、多端同步、弹性扩展与稳定性、高可用与容错、数据安全与隐私保护、数据存储可靠、方便集成与扩展。

（1）实时通讯

支持用户在任何时间、任何地点之间实现实时的消息发送和接收，包括文字、图片、语音、视频等多种形式的通讯。系统统需要具备实时性和低延迟特性，确保消息能够在用户之间快速传递，减少通讯的延迟和等待时间。

（2）多端同步

支持用户在不同终端（如手机、平板、电脑）之间的消息同步和互通，确保用户可以随时随地方便地进行即时通讯。

（3）弹性扩展与稳定性

支持大量用户的接入和大规模并发的通讯需求，保证系统稳定运行并能够灵活扩展以适应不断增长的用户量。需要具备弹性扩展性，能够根据用户量和负载情况进行动态扩展，以满足快速增长的通讯需求。

（4）高可用与容错

具备高可用性，确保系统可以持续运行并提供稳定的服务。同时，系统还应具备容错性，能够自动检测和处理故障，避免单点故障导致整个系统的崩溃。

（5）数据安全与隐私保护

保护用户的隐私和数据安全，确保通讯内容的机密性和完整性，防止信息泄露和非法访问。采取有效的数据安全措施，包括数据加密、权限管理、防止恶意攻击等，以保护用户的个人隐私和通讯内容的安全。

（6）数据存储可靠

提供可靠的消息存储和同步机制，确保消息在发送和接收过程中不会丢失，并能够在不同设备之间进行同步，保证用户可以随时查看历史消息。提供有效的存储空间管理机制，包括对附件、图片、语音、视频等多媒体文件的存储和管理，以避免占用过多的存储空间。

（7）方便集成与扩展

系统应具备开放的接口和SDK机制，能够方便其他业务系统快速集成IM即时通讯功能，并扩展系统的功能和服务能力。

（8）其他具体需求目标

其他具体需求目标包括：良好的用户体验、丰富的社交功能、用户管理功能、实时语音和视频通话、群组功能、消息发送与撤回、消息已读未读、文件传输、数据统计和分析等等。

1.2 挑战

分布式IM即时通讯系统最核心的就是要保证系统的可靠性、有序性、实时性、扩展性和稳定性。

（1）可靠性

在IM通讯系统中，可靠性更多的是指投递消息的可靠性，也就是消息从发出到接收的可靠性。一般会通过消息不丢失和消息不重复两个指标来进行衡量。在实际环境中，网络环境是比较复杂的，加上用户在线、离线等因素，这就使得确保消息的可靠性具有一定的技术挑战。对于消息的可靠性来说，主要包含：发送失败、发送成功和消息不重复。

发送失败：IM即时通讯系统要能够立即感知到发送失败的消息，将其反馈给消息发送者，发送者可以选择重试或者稍后再试。
发送成功：消息发送者成功发出消息后，如果消息接收者此时在线，应该能够立即接收到消息。如果消息接收者不在线，或者叫做离线，则IM系统能够缓存这些消息，待消息接收者上线后，能够接收到这些消息。
消息不重复：IM系统需要尽最大程度保证消息不重复。

（2）有序性

在IM即时通讯系统中，需要考虑消息的有序性，不能打乱消息的顺序。否则，会造成消息发送者与消息接收者之间的误解，产生不必要的麻烦，并且消息错乱的话，也会为系统带来相当大的负面影响。在IM即时通讯系统重保证消息的顺序看似比较简单，实则是非常具有技术挑战的一项事情。

（3）实时性

在IM即时通讯系统中，实时性主要是消息的实时性，具体点就是消息要实时达到接收方。如果接收方用户在线，则消息能够实时到达接收方。如果接收方用户不在线，当接收方用户登录系统后，就需要能够接收到消息。另外，为了满足实时性的要求，就需要实现用户的连接管理、消息实时推送、推送失败重试处理、客户端重连等等。这些都是具备一定技术挑战的。

（4）扩展性

在分布式IM通讯系统中，我们会实现：单聊、群聊、图片、文件、语音、视频、历史消息、消息已读、未读、添加好友、删除好友、创建群、加群、退出群、查看群成员、群公告、修改群备注等一系列完整的功能，更会实现对接OpenAI大模型服务。，并且会提供SDK供其他业务系统接入，在实现上也要支持多端展示。

（5）稳定性

系统的稳定性自然不必多说，绝大多数互联网项目都要求具备稳定性。

挑战最核心的解决方案就是：保证IM系统的高并发读、高并发写、分布式架构、多分层架构、分布式存储、消息缓存与实时推送。

这些策略的具体方案会放到具体设计和实现分布式IM即时通讯系统的章节中去实现，这里就不详细赘述了。

1.3 总结

目标是：实时通讯、多端同步、弹性扩展与稳定性、高可用与容错、数据安全与隐私保护、数据存储可靠、方便集成与扩展。挑战包含了：可靠性、有序性、实时性、扩展性和稳定性。可以从保证IM系统的高并发读、高并发写、分布式架构、多分层架构、分布式存储、消息缓存与实时推送等方面来应对这些挑战。

2 功能需求梳理

分布式IM即时通讯系统的业务就是对消息的管理和对用户的管理。

2.1 消息管理需求

针对聊天本身来说，最核心的需求就是：发送文字、图片、文件、语音、视频、消息缓存、消息未读、已读、撤回，历史消息、单聊、群聊，以及其他一些需求。

2.2 用户管理需求

对用户管理来说，存在的需求包含：添加好友、查看还有列表、删除好友、查看还有信息、加入群聊、查看群成员信息、退出群聊、修改群昵称、创建群聊、拉人进群、踢人出群、解散群聊、填写群公告、修改群备注以及其他用户相关的需求等。

左侧的需求是所有用户都需要实现的，而右侧的需求是针对创建群的人。

2.3 业务流程

从业务流程角度来说，用户都需要登录系统后才能进行操作，并且在系统中，用户可以修改自己的头像和基本信息，可以通过搜索用户来添加好友，从而与好友进行单聊。可以查看好友列表，查看或管理好友信息，删除好友。可以通过搜索群组加入群，进行群聊。也可以自己创建群，拉其他用户进群，实现群聊。还可以查看群列表，查看或管理群信息，退出或解散群。如图所示。

可以看到，不管是单聊还是群聊，总体的业务流程还是比较简单的。用户登录系统后可以通过搜索用户来添加好友，进而能够与好友进行单聊。用户在系统中实现群聊有两种方式，一种是通过搜索群组并加群，另一种时通过创建群组并拉人进群。并且用户可以对好友进行管理并删除好友，也可以对群组进行管理，退出或解散群群。

3 技术流程梳理

就从技术的角度出发，梳理分布式IM即时通讯系统的用户请求交互链路、发送消息交互链路、单聊交互链路和群聊交互链路。

3.1 用户请求交互链路

从技术的角度来讲，用户通过客户端访问分布式IM即时通讯系统，一般都是通过域名来访问的，通过域名访问系统，就需要DNS服务器做域名解析，将域名解析成对应的IP地址来访问指定的服务器。进入服务器后，会通过Kong/OpenResty/Nginx进入系统的业务网关，再到我们部署的后端平台，IM即时通讯服务。由后端平台、IM即时通讯服务再到基础服务，由基础服务再到数据存储服务。向客户端返回数据时，再按照相反的顺序层层返回。整体链路如图所示。

可以看到，当用户通过域名访问分布式IM即时通讯系统时，会经过如下的请求链路。

（1）用户通过PC/H5/小程序/APP访问分布式IM即时通讯系统时，请求可能会分为HTTP请求、TCP请求或者是WebSocket请求，不管是哪种请求，都会先经过DNS服务器对域名进行解析，解析出IP地址，通过IP地址定位到最终的服务器。

（2）请求进入服务器后，会先经过Kong/OpenResty/Nginx等流量网关或者负载均衡器，将请求发往业务网关。

（3）请求进入业务网关后，如果是HTTP请求，则业务网关会将请求路由到后端平台，如果后端平台此时的业务需要发送即时消息，则后端平台会通过集成的SDK向IM即时通讯服务发送即时消息。如果是TCP请求或者WebSocket请求，则业务网关会将请求路由到IM即时通讯服务，由IM即时通讯服务来处理即时消息。

（4）后端平台和IM即时通讯服务接收到请求后，进行对应的业务处理后，都会调用基础服务的接口来进一步处理业务。

（5）基础服务执行完业务逻辑，会将数据写入数据存储服务，比如Redis、MySQL、ES等数据存储服务中。

（6）后端平台会集成IM即时通讯SDK，并且会集成对接OpenAI大模型的SDK。

当分布式IM即时通讯系统处理完业务逻辑向客户端响应结果数据时，会经过如下的响应链路。

（1）如果客户端只是调用后端平台的接口，来执行后端平台的逻辑，例如搜索用户、查看好友列表、搜索群组、查看群列表等不涉及即时通讯的逻辑时，后端平台处理完业务逻辑并记录相关的数据后，就会按照与请求相反的链路响应数据。

（2）如果客户端调用后端平台的接口，通过后端平台的接口来发送即时消息时，后端平台处理完业务逻辑并记录相应的数据后，会通过集成的SDK服务向IM即时通讯服务发送即时消息，IM即时通讯服务接收到消息后，会通过客户端与IM即时通讯服务建立的长链接，向客户端发送即时消息。

（3）如果客户端是通过WebSocket或者TCP等协议向IM即时通讯服务发送消息，IM即时通讯服务处理完业务逻辑并记录数据后，会通过客户端与IM即时通讯服务建立的长链接，向客户端发送即时消息。

3.2 发送消息交互链路

在分布式IM即时通讯系统中，我们忽略掉其他一些细节信息，重点关注下发送消息的交互链路逻辑。不管是单聊还是群聊，最终都需要通过IM即时通讯服务将消息推送给用户的终端。此时发送消息的流程如图4-2所示。

可以看到，用户在分布式IM即时通讯系统发送消息时，不管是单聊还是群聊，最终的消息都会推送到用户登录的终端设备上。假设此时用户A给用户B发送消息，或者用户A和用户B在同一个群组，用户A向群组发送消息，用户B接收消息的主要流程如下。

（1）用户A调用后端平台的接口向用户B发送消息，并且发送的消息中会带有用户B的ID以及终端信息。

（2）后端平台将消息缓存起来，并且会将消息写入消息库。

（3）后端平台从Redis中获取用户B连接的IM即时通讯服务的ID。

（4）后端平台获取到用户B连接的IM即时通讯服务的ID后，会向RocketMQ中用户B连接的IM即时通讯服务ID对应的Topic发送消息。

（5）IM即时通讯服务会监听自身服务ID对应的RocketMQ中Topic的消息，此时，用户B连接的IM即时通讯服务会接收到消息。

（6）IM即时通讯服务接收到消息后，会根据用户B的ID以及终端信息从缓存中获取用户B与IM即时通讯服务建立的连接，并且通过这个连接向用户B推送消息。

要实现如上发送消息的流程，前提是要满足如下条件。

（1）后端平台满足分布式条件，可随时横向扩展。

（2）IM即时通讯服务满足分布式条件，可随时横向扩展。

（3）每个启动的IM即时通讯服务实例在集群中都有一个唯一的ID。

（4）每个IM即时通讯服务，都只监听自身ID对应的RocketMQ中Topic的消息。

（4）用户登录分布式IM即时通讯系统后，会与IM即时通讯服务建立长连接，并且会根据用户ID和所在的终端缓存长连接，同时会根据用户ID和所在的终端将连接的IM即时通讯服务的ID缓存到Redis。

（6）用户发送消息时，会根据目标用户的ID和终端从Redis中获取IM即时通讯服务的ID，进而向当前IM即时通讯服务的ID对应的RocketMQ的Topic发送消息。

（7）对应的IM即时通讯服务监听并接收到RocketMQ消息后，会根据目标用户的ID和终端从缓存中获取到用户的连接信息，向目标用户推送消息。

3.3 单聊交互链路

单聊就是在分布式IM即时通讯系统中，一个用户直接与另外一个用户聊天，也就是一对一的聊天。在这种场景下，很有可能单聊的两个用户中，出现用户不在线的情况。例如，用户A给用户B发送消息时，用户B可能不在线。此时，我们就需要将用户A向用户B发送的消息存储起来。其实，在我们实现的分布式IM即时通讯系统中，无论把用户B是否在线，都会存储消息记录。当用户B登录系统后，将消息同步给用户B，如图4-3所示。

可以看到，用户A向用户B发送消息时，如果用户B在线，就可以按照发送消息的交互链路向用户B发送消息了。如果用户B不在线，此时就无法向用户B正常推送消息。当用户B登录分布式IM即时通讯系统后，就会调用后端平台的接口拉取所有未读消息，并通过用户B在线流程向用户B推送消息。

3.4 群聊交互链路

群聊就是在分布式IM即时通讯系统中，多个用户在同一个群组中进行聊天，此时在发送消息时，我们可以通过群组ID找出群内所有在线的用户，将消息即时发送给在线的用户。那些未在线的用户就按照单聊未在线的用户进行处理，如图4-4所示。

可以看到，群聊的交互链路流程如下所示。

（1）用户调用后端平台的接口向群组发送消息。

（2）后端平台将消息缓存并写入消息库。

（3）由于是向群组发送消息，群里有多个用户，此时就会从Redis中获取所有用户连接的IM即时通讯服务ID列表。

（4）对用户按照服务ID分组，将相同服务ID下的用户分在同一个逻辑分组里，方便后续推送消息，并且会记录未在线的用户列表。

（5）循环向每个服务ID对应的RocketMQ中的Topic发送消息。

（6）广播处理未在线用户的未读消息ID。

（7）IM即时通讯服务会监听自身服务ID对应的Topic，会随时接收推送到自身服务的消息。

（8）当IM即时通讯服务接收到消息后，此时用户掉线，或者用户不在线，向用户推送消息就会失败，或者未查询到用户与IM即时通讯服务建立的连接，就不会向用户推送消息。

（9）当用户登录分布式IM即时通讯系统后，会从后端平台拉取历史（离线）消息，并通过用户在线的流程，向用户推送消息。

总体架构设计

1 系统总体方案架构设计

总体上，分布式IM即时通讯系统，需要满足如下方案目标。

业务目标：满足需求设计篇章中的各类需求场景。
技术目标：发送消息接口：1W+TPS，好友列表，群列表，会话列表、群成员：5W+QPS，支持5W+用户同时在线。
架构目标：高并发、高性能、高可用、可监控、可预警、可伸缩。

1.1 技术选型

开发框架：SpringBoot、SpringCloud、SpringCloud Alibaba、Dubbo。
缓存：Redis分布式缓存+Guava本地缓存。
数据库：MySQL、TiDB、HBase。
流量网关：OpenResty+Lua。
业务网关：SpringCloud Gateway + Sentinel。
持久层框架：MyBatis、Mybatis-Plus。
服务配置、服务注册与发现：Nacos。
消息中间件：RocketMQ。
网络通信：Netty。
文件存储：Minio。
日志可视化治理：ELK。
容器化管理：Swarm、Portainer。
监控：Prometheus、Grafana。
前端：Vue
单元测试：Junit。
基准测试：JMH。
压力测试：JMeter。

1.2 系统初步架构设计

IM即时通讯系统的架构图，大致如图所示。

其实，这种这种架构设计也比较常见，在这种架构设计中，Kong/Openresty/Nginx只做负载均衡和反向代理，研发人员更多的是关业务层和基础层的开发，流量比较小时，这种架构设计一般不会有什么问题。但是一旦流量比较大时，用户调用后端平台的接口发送消息时，即时通讯SDK同步调用即时通讯服务的接口就会出现性能问题。

因为在前面的文章中，我们已经分析了每个用户同时只能与一个IM即时通讯服务实例建立连接，如果大量的用户终端恰好都与一个IM即时通讯服务建立连接，那即时通讯SDK频繁同步调用同一个IM即时通讯服务的接口就会出现性能瓶颈。此时，出现性能瓶颈时，不仅仅会影响到IM即时通讯服务，也会对后端平台接收请求的业务造成一定的影响。

1.3 系统架构设计优化

既然图1-1所示的架构设计存在性能瓶颈，那我们如何进行优化呢？为此我们在如1-1的基础上进行了优化，优化后的架构如图1-2所示。

对比图1-1和图1-2可以看出，在屏蔽掉技术实现细节的前提下，我们将对业务的校验和流量管控进行前置化，放大Kong/OpenResty/Nginx的职责，使得这些软件不仅具备反向代理和负载均衡的功能，还能实现限流、黑白名单、流量管控、业务校验等功能。

也就是说，在这种架构模式下，我们充分发挥了整个分布式IM即时通讯系统的入口职责，充分利用Kong/OpenResty/Nginx的高并发、高吞吐量的能力，尽量将大部分无效请求挡在整个系统之外。例如，用户在没登录系统的前提下，就尝试调用发送消息、添加好友、添加群组等等接口。这样会大大减轻后台平台的业务压力。

除了在Kong/OpenResty/Nginx中实现限流、黑白名单、流量管控、业务校验等功能外，我们还引入了业务网关集群，实现限流、降级、熔断、流控、校验、鉴权等功能，进一步保证下游系统的稳定性和安全。

为了解决大量用户终端恰好连接到同一个IM即时通讯服务实例，IM即时通讯SDK频繁调用同一个IM即时通讯服务实例的接口造成的性能问题。我们在IM即时通讯服务SDK与IM即时通讯服务之间引入了RocketMQ集群。

IM即时通讯服务集群中的每一个IM即时通讯服务实例在集群中都有一个唯一的ID，并且每个IM即时通讯服务实例在启动后，只会监听RocketMQ中与自身ID相关的Topic。这样每个IM即时通讯服务只会收到与自身ID相关的Topic中的消息，不会接收所有的消息。

当用户登录系统后，就会与IM即时通讯服务建立长连接，并且会以用户ID和终端为Key，以IM即时通讯服务的ID为value，将其存储到分布式缓存中。同时，会以用户ID和终端为Key，以用户终端与IM即时通讯服务建立的长连接为value，将其存储到IM即时通讯服务本地内存中。

当用户调用后端平台的接口发消息时，会带上目标用户的ID，并且在IM即时通讯SDK中会指定用户登录的终端设备，最终会通过IM即时通讯SDK向RocketMQ发送消息，此时IM即时通讯SDK会根据目标用户ID和终端从分布式缓存中获取目标用户连接的IM即时通讯服务的ID，并向此ID相关的Topic发送消息。此时与目标用户建立长连接的IM即时通讯服务就会接收到RocketMQ中的消息，随后根据用户ID和终端从本地缓存中获取到与用户终端建立的长连接，并基于此长连接向用户推送消息。

那么问题来了：这种架构设计还有进一步优化的空间吗？

1.4 容器化架构设计

为进一步增强分布式IM即时通讯系统的性能、可用性和弹性伸缩能力，我们可以对分布式IM即时通讯系统进行容器化架构设计，如图1-3所示。

可以看到，我们对分布式IM即时通讯系统的架构设计进行了进一步优化，采用了容器化架构设计。在原有架构的基础上，我们进行了如下改进和优化。

（1）基础支撑服务

基础支撑服务会由各种基础中间件、数据存储服务、以及监控服务实现，包含：MySQL数据库、TiDB数据库、HBase、Redis缓存、RocketMQ消息队列、Prometheus监控和Portainer容器管理等基础中间件实现，基础支撑服务会对整个分布式IM即时通讯系统提供最基础的数据、传输、监控和容器管理等服务。

（2）容器化

在容器化层面，会通过Docker、Swarm和Portainer实现，其中，会基于Swarm和Portainer对容器化进行管理。

（3）其基础性功能实现

除了上述分层架构外，对于建设分布式IM即时通讯系统来说，还要考虑异常监控、服务注册与发现、可视化、服务降级与兜底数据、服务限流、服务容灾、容量规划与扩缩容和全链路压测等。

2 数据模型设计

本节对用户、好友关系、群组、群成员、单聊消息和群聊消息的数据模型进行简单的设计。

注意：数据库脚本已经存放到bh-im-resource仓库下的environment/config/mysql/init目录下，脚本文件为bh_im_init.sql，后续在搭建分布式IM即时通讯系统的研发环境时，会自动将数据脚本导入到MySQL数据库，无需自己重新运行脚本文件。

2.1 用户模型设计

对于用户模型数据来说，简化后的模型字段包括：用户id、用户名、密码、用户昵称、用户头像、用户头像缩略图、性别、用户类型、个性签名、最后登录时间、创建时间，整体如下所示。

2.2 好友关系模型设计

对于好友关系模型数据来说，简化后的模型字段包括：关系id、用户id、好友id、好友昵称、好友头像、创建时间， 整体如下所示。

2.3 群组模型设计

对于群组模型数据来说，简化后的模型字段包括：**群id、群名称、群主id、群头像、群头像缩略图、群公告、群备注、状态、创建时间，**整体如下所示。

2.4 群成员模型设计

对于群成员模型数据来说，简化后的模型字段包括：**数据id、群id、用户id、群内显示名称、用户头像、备注、状态、创建时间，**整体如下所示。

2.5 单聊消息模型设计

对于单聊消息模型数据来说，简化后的模型字段包括：**消息id、发送者id、接收者id、消息内容、消息类型、状态、发送时间，**整体如下所示。

2.6 群聊消息模型设计

对于单聊消息模型数据来说，简化后的模型字段包括：**消息id、群id、发送者id、发送者昵称、消息内容、被@用户id列表、消息类型、状态、发送时间，**整体如下所示。

2.7 数据模型汇总

在数据库中建立对应的数据表，分别为：im_user用户表、im_friend好友关系表、im_group群组表、im_group_member群成员表、im_private_message单聊消息表和im_group_message群聊消息表，并查看对应的模型结构。

通用模型设计

1 系统通用数据模型设计

系统整体涵盖大后端平台，SDK接入服务、即时通讯后端服务、大模型接入服务、大前端UI等项目工程。因此，数据不只是在客户端与服务端之间交互，还会涉及到服务端各系统之间的数据交互，此时，我们可以在客户端与服务端之间，服务端各系统之间的数据交互过程中，抽象出通用的数据模型。

1.1 模型数据梳理

在梳理模型数据之前，我们再来看看分布式IM即时通讯系统的容器化架构设计图，如图1-1所示。

大致梳理出如下十种通用数据模型。

登录信息模型：用户使用分布式IM即时通讯系统的功能时，需要对用户的登录信息进行校验，只有校验通过的用户才能正常使用系统的功能，此时就需要设计用户的登录信息模型。
Session信息模型：用户登录系统后，如何管理用户的登录信息，这就涉及到Session信息的管理，此时就需要设计Session的数据模型。
用户信息模型：用户在系统中发送消息时，如何绑定消息和发送者的信息？此时，就需要单独设计用户的信息模型。
心跳数据模型：客户端与即时通讯服务之间建立长连接后，为了避免长期未使用造成的断连问题，需要在客户端与即时通讯服务之间设计心跳机制，此时就需要设计心跳数据模型。
私聊数据模型：用户在系统中可以与其他用户实现一对一单聊，此时，就需要实现私聊数据模型。
群聊数据模型：用户在系统中可以实现在群组中聊天，群组中的群成员都能接收到当前用户的聊天内容，此时，就需要实现群聊的数据模型。
通用发送数据模型：即时通讯服务向客户端响应登录结果，发送心跳数据、发送单聊消息和群聊消息，即时通讯服务都会以通用发送数据模型来发送数据。此时，就需要设计和实现通用发送数据模型。
通用接收数据模型：用户通过大后端平台发送消息时，大后端平台会通过即时通讯SDK向RocketMQ集群发送消息，即时通讯服务集群会监听RocketMQ集群中对应的Tocpic数据，此时的数据交互就是通过通用接收数据模型来完成的。此时，就需要设计和实现通用接收数据模型。
响应结果数据模型：发送消息成功后，需要响应消息的发送结果，此时，就是以响应结果数据模型来完成的。因此，就需要设计和实现响应结果的数据模型。
RocketMQ数据模型：当用户发送消息时，会涉及到数据在RocketMQ中的传输过程，此时，就需要设计和实现RocketMQ的数据模型。