语源科技BlogJava-Jack Jiang

基于开源MobileIMSDK框架，即时通讯IM产品RainbowChat v12.0已发布

Jack Jiang — Mon, 27 Apr 2026 09:22:00 GMT

1、关于RainbowChat

RainbowChat是一套基于开源IM即时通讯聊天框架 MobileIMSDK 的产品级移动端IM系统。RainbowChat源于真实运营的产品，解决了大量的屏幕适配、细节优化、机器兼容问题。RainbowChat可能是市面上提供im即时通讯聊天源码的，唯一一款同时支持TCP、UDP、WebSocket三种通信协议的IM产品。与姊妹产品 RainbowTalk 和 RainbowChat-Web 技术同源，历经考验。

☞ 详细介绍：http://www.52im.net/thread-19-1-1.html
☞ 版本日志：http://www.52im.net/thread-2735-1-1.html
☞ 运行截图：Android端、iOS端
☞ 下载体验：App Store安装地址（另：Android端下载体验点此查看）

2、关于MobileIMSDK开源工程

MobileIMSDK 是一套全平台开源IM即时通讯聊天框架，超轻量级、高度提炼，一套API优雅支持UDP 、TCP 、WebSocket 三种协议，客户端支持iOS、Android、H5、小程序、Uniapp、标准Java、纯血鸿蒙等，服务端基于Netty编写，性能卓越、易于扩展。

工程同步开源地址：

❶ GitHub：https://github.com/JackJiang2011/MobileIMSDK
❷ 码云gitee： https://gitee.com/jackjiang/MobileIMSDK
❸ Gitcode：https://gitcode.com/hellojackjiang2011/MobileIMSDK

2、v12.0 版更新内容

此版更新内容（更多历史更新日志）：

（1）Android端主要更新内容【全面适配Android 16、适配16KB page size、适配全面屏特性等】：

1）[bug] 解决了两个表情占位符重复的问题；
2）[bug] 解决了好友列表删除唯一好友后，一直转圈的问题；
3）[bug] 优化了搜索聊天记录时，当首页“消息”中不存在该陌生人时，搜出的群聊详细中消息发送者昵称会用uid显示的问题；
4）[bug] 解决了不支持分区存储的老手机转发的大文件消息，在新系统上无法下载的问题；
5）[bug] 优化了存在多条置顶消息时，不是按置顶时间而是消息时间排序的问题；
6）[新增] 二维码生成界面下方增加功能按钮；
7）[新增] “用户信息”界面增加了“查看用户资料”按钮；
8）[新增] 优化了世界频道的打开入口等；
9）[新增] 去掉了“商城”模块，增加了“发现”页面；
10）[优化] 将核心层提炼成独立的chatkit模块；
11）[优化] 解决了独立chatkit后，好友信息中删除对方时，无法自动跳转到主页的问题；
12）[优化] 现在不能删除首页列表中的“确认提醒”这个item了；
13）[优化] 升级腾讯Bugly至4.1.9.3，解决上架国内应用市场的隐私合规问题；
14）[优化] 登录和退出登录接口中废弃了osType字段；
15）[优化] 优化了注册界面中关于服务端返回邮箱格式不正确的错误码的处理；
16）[优化] 支持小窗、分屏显示；
17）[优化] 只有好友才能查看对方的注册和登录时间；
18）[优化] 查找好友时不再显示对方的在线状态；
19）[优化] 提升targetSdkVersion至36，全面兼容Android 16；
20）[优化] 开发工程升级适配AGP 9.1最新版；
21）[优化] 升级权限框架以适配最新Android 16系统；
22）[优化] 针对全部界面适配系统强制的Edge to Edge全面屏特性；
23）[优化] 解决了Android 16下聊天界面输入法弹出时会挡住消息输入框的问题；
24）[优化] 解决基于PopupWindow实现的弹出界面底部在Edge to Edge全面屏特性下的显示问题；
25）[优化] 加固一处因多线程安全问题导致的可能崩溃风险；
26）[优化] 升级高德地图SDK至最新v11.1等，适配google play强制16KB page size问题；
27）[优化] 优化了位置消息搜索界面的搜索组件ui并提升了细节体验；
28）[优化] 解决了进入了主页搜索界面在Android 16下不能自动弹出输入法，及优化了点击背景可收起软键盘；
29）[优化] 删减了APP首次启动时的权限申请内容；
30）[优化] 解决了Android 16下返回按钮事件捕获失败的问题；
31）[优化] 聊天界面下方的功能面板图标美化等；
32）[优化] 聊天文本框自动换行；
33）[优化] 其它更具现代感的UI细节优化和体验等；

（2）服务端主要更新内容【安全加固、新增接口等】：

1）[bug] 解决了对接RainbowChat-Web产品时，网页端无法正常登录的问题；
2）[优化] 加固了后端SQL防注入逻辑；
3）[优化] 开启了WebSocket协议支持；
4）[优化] 对离线数据表中的消息指纹字段增加了索引，提升查询性能；
5）[优化] 优化了文件下载服务中存在利用文件名进行越权文件操作的安全隐患；
6）[优化] 提供了一个校验token与uid一致性的安全性实现示例；
7）[优化] 优化了原Android专用的登录接口【接口1009】，使之同时支持验证码、密码登录；
8）[优化] 【接口1008-10-22】新增了“preview_count”字段；
9）[优化] 将IDEA工程中applicationContextRoot改成了rainbowchat_pro/（方便开发环境跟生产环境一致）;
10）[优化] 优化了注册接口【接口1008-1-7】，增加了手机号和短信验证码支持；
11）[新增] 数据库新增了注销登录相关字段；
12）[新增] 新增注销登录接口；
13）[新增] 新增获取验证码接口【接口1008-1-27】；
14）[新增] 新增新的登录接口【接口1017】，同时支持ios等客户端的验证码、密码登录；
15）[新增] 新增对接鸿蒙NEXT产品时支持华为Push Kit离线推送；

3、升级后的主要UI运行截图

（☞ 更多截图请查看：Android端运行截图、iOS端运行截图）

4、真机运行视频

（☞ 新窗口中查看真机运行视频）

5、真机实拍截图

Jack Jiang 2026-04-27 17:22 发表评论

社交场景下的统一即时通讯im消息流交互层模块化技术实践

Jack Jiang — Mon, 20 Apr 2026 10:43:00 GMT

网易技术团队旭风分享，有排版优化和修订。

1、引言

一款社交产品的诞生，离不开即时通讯（IM）场景。随着团队业务版图在社交领域的布局，诞生了多个社交场景APP，涉及的IM场景，包含私聊、群聊、聊天室等。

这些IM场景，在消息流的展示形式上是极为相似的，同时每个业务又有着自己特殊的交互需求。基于此，我们对IM消息流能力做了标准化的构建，来减少IM功能的业务接入成本；同时也是为了统一各个业务的技术方案，减少跨业务开发的理解和维护成本。本文主要针对iOS端在IM消息流交互层的设计上，提供一些实践思路。

2、业界的实现方案

目前业界有各种即时通讯服务商提供的配套交互层解决方案，其大多以牺牲灵活性来满足快速集成需要，在定制能力上远不能胜任我们业务需要。

再诸如 MessageKit之类的社区IM框架，其在视觉交互表现上功能完备，能帮助我们快速、灵活搭建IM消息流结构，但业务需要的是一套完整的携带消息交互能力的方案，因此对此类框架，仍需要做不小的改造才能适应我们的业务（另一参考方案：MobileIMSDK（Gitee源码托管地址））。

3、我们的想法

对于一个IM消息流交互层方案，主要考虑几个方面：

1）规范的消息流结构：提供消息流视图结构规范化的构建方式；
2）标准的消息交互能力：统一消息交互能力，业务方按需使用，快速集成；
3）业务拓展性：针对数据源、消息交互能力提供业务灵活拓展点；
4）业务接入成本：内置通用交互方案，降低业务接入成本。

目前，我们存量业务中的IM场景，底层IM能力主要由云信引擎提供。同时又存在基于业务服务端，通过HTTP去交互的场景。

另外，还需要预留后期切换IM引擎的可能性，因此需要将交互层IM能力抽象出来。

此外，为了适应团队现状，减小业务接入成本，考虑将云信提供的交互能力内置在方案中。

4、整体设计

设计愿景：提供标准化的能力，同时对拓展开放。

我们期望一套通用的IM消息流能力，能够在方案上标准化。这里的标准化，主要包含消息流结构构建的标准化，以及消息交互能力的标准化。同时，方案需要在交互能力上适应不同业务场景，因此采用依赖注入的方式，提供业务定制能力。

按照职能划分，将框架整体分为了两层：

1）消息流结构层：负责消息流结构的构建，定义消息视图、布局、数据上的规范，提供业务层分别在「消息」、「会话」两个维度的配置能力。

2）消息交互层：提供消息能力、消息流、消息数据方面的交互能力，向下依赖交互接口，内置标准交互能力的同时，也支持业务按需注入交互实现。

5、聊天消息流的显示结构

5.1 消息组件

不同的业务场景，消息流样式表现必然有所差异。

下面列出了我们几个业务中的消息流界面：

如何设计一套通用的消息流视图结构，满足不同业务需要？经过对各个业务以及一些主流IM工具的观察，将消息视图结构设计成如下结构，是能够满足我们各个IM场景需要的（见下图）。

我将消息结构拆分成了5部分，对应5个消息组件 MessageView ，每个消息组件都支持业务对其「样式」、「显隐」、「布局」进行配置，从而满足不同场景定制需要。

MessageView作为基础消息组件，提供了一些标准能力，例如是否响应菜单动作 canPerformMenuAction 、视图重用回调时机 prepareForReuse 、尺寸策略等。
open class MessageView: MessageAbstractView {
  public var canPerformMenuAction = false
    open func refresh(with message: Message) {}
    open func prepareForReuse() {}
    open class func createSizeStrategy(message: Message, fittingSize: CGSize) -> MessageLayoutSizeStrategy? {
    // ...
    }
}

5.2 尺寸策略

消息组件尺寸作为消息流布局上不可或缺的要素，方案提供了多种尺寸计算策略 MessageLayoutSizeStrategy 。

具体是：

1）自动布局计算策略：业务方对消息组件使用 AutoLayout 布局时使用，内部会依据约束自动计算好组件尺寸；
2）SizeThatFit 策略：依据组件 SizeThatFit 方法返回的尺寸进行布局；
3）自定义策略：提供自定义尺寸计算方式。

public protocol MessageLayoutSizeStrategy {
    func caclulateSize(_ sizeViewType: MessageView.Type,
                       message: Message,
                       fittingSize: CGSize) -> CGSize
}

public struct MessageAutoLayoutSizeStrategy: MessageLayoutSizeStrategy {
    public func caclulateSize(_ sizeViewType: MessageView.Type,
                              message: Message,
                              fittingSize: CGSize) -> CGSize {
    // ...省略其他代码
        return sizeView.systemLayoutSizeFitting(UIView.layoutFittingCompressedSize)
    }

}

public struct MessageSizeThatFitsStrategy: MessageLayoutSizeStrategy {
    public func caclulateSize(_ sizeViewType: MessageView.Type,
                              message: Message,
                              fittingSize: CGSize) -> CGSize {
        // ...省略其他代码
        return sizeView.sizeThatFits(fittingSize)
    }
}

5.3 布局快照

我们还针对消息组件维度支持了布局快照。通常当一个消息组件尺寸固定，在交互过程中尺寸不会发生的情况下，打开布局快照，以减少布局计算消耗。同时也提供了快照清除的能力。

我们对多个消息流在快速滚动过程中的CPU峰值做了统计，在使用自动布局尺寸策略的情况下，开启布局快照，峰值降低了10%~20%。

5.4 交互事件

另外在手势交互上，对外暴露了各个消息组件的一系列交互事件。常见的场景例如单击浏览消息内容，长按展示消息菜单等。

方案内部提供了基于系统样式的长按菜单，并提供上层菜单配置能力，同时也可以基于暴露的长按手势事件来自定义菜单。

5.5 消息流

一个会话对应一个流，方案也提供了消息流在会话维度上的一些标准化配置。例如消息分页数量、是否自动拉取历史消息、是否开启增量刷新，以及在时间展示上的样式配置等。

此外为了减少列表重绘，消息流也支持增量刷新。通常情况下业务层不需要主动刷新列表，只需对消息数据进行增删改操作，内部会触发对数据源的「diff-update」计算，从而驱动列表的增量更新。

6、聊天消息交互层

6.1 概述

对于业务方而言，在消息交互上通常关心这么几点：

1）提供了哪些标准化的交互能力；
2）如何拓展自定义的交互实现；
3）如何对交互流程进行干预。

结合团队现状，我们在方案内部内置了基于某信的IM交互能力，同时定义了相关交互接口，供业务方按需注入实现。

在实际业务中，一个APP内可能存在多个IM场景，因此交互能力支持按会话维度进行注入，各个会话之间的交互是相互隔离的。

6.2 消息源

不同的IM场景，消息数据来源可能存在差异。例如我们私聊、群聊的数据源来自云信数据同步服务，聊天室数据需要通过云信提供的历史消息接口拉取，另外也存在诸如通过业务服务端接口来拉取消息数据的场景。

因此方案上设置了数据源接口 SessionMessageProvider ，提供不同场景消息源的定制能力。

public protocol SessionMessageProvider {
    func messages(in session: Session,
                  anchorMessage: Message?,
                  limit: Int,
                  completion: @escaping ([Message]) -> Void)
}

方案设置了一个负责管理消息数据源的 DataManager 实例，其依赖 SessionMessageProvider 提供的数据源。同时内置了基于云信的数据源获取实现，能够根据当前会话类型，获取私聊、群聊、聊天室的数据源。

如果当前场景是通过HTTP拉取消息的，则需要业务上层手动注入一个从接口获取数据源的 SessionMessageProvider 实例。

6.3 交互源

方案提供了IM标准交互能力，例如消息收发、消息撤回、保存等，以统一各业务交互姿势。

具体的交互源除了要考虑目前包含的云信及业务服务端，也要适应其他交互源，因此将交互实现部分也抽象出了接口 MessageServiceInterface 。业务根据当前实际场景，注入具体的交互实现即可。

下面列出了一些交互申明：

public protocol MessageServiceInterface {
    func send(message: Message, in session: Session, completion: @escaping MessageServiceInterfaceCompletion)
    func resend(message: Message, completion: @escaping MessageServiceInterfaceCompletion)
    func forward(message: Message, to session: Session, completion: @escaping MessageServiceInterfaceCompletion)
    func revoke(message: Message, completion: @escaping MessageServiceInterfaceCompletion)
    func save(message: Message, in session: Session, completion: @escaping MessageServiceInterfaceCompletion)
    func delete(message: Message, completion: @escaping MessageServiceInterfaceCompletion)
}

同样，我们也内置了一些通用交互方案，例如支持云信提供的私聊群聊交互能力，以及由中台提供的通用聊天室服务交互能力，以支持相关场景下快速接入。

6.4 交互钩子

在实际IM业务开发过程中，往往需要对交互流程做一些干预，或是在交互过程中做一些定制化的动作。因此方案也提供了一些交互钩子，支持「交互前置校验」、「交互前准备」。

以消息发送流程为例，提供了「发送前校验」、「发送准备」两个消息发送过程的回调钩子：

public protocol MessageServicePrechecker {
   // 消息发送前置校验
    func shouldSend(message: Message, in session: Session) -> Bool

    // ...省略其他代码
}

public protocol MessageServicePreparation {
    /// 准备发送准备
    func prepareSend(message: Message, in session: Session, callback: @escaping MessageServicePreparationCallback)

    // ...省略其他代码
}

整体的发送流程如图所示：

前置校验阶段，用来作消息发送前的校验工作，根据实际状态决定消息是否可以发送。发送准备阶段，则可以在消息投递前做最后的准备工作，例如海外业务可以在这里处理消息资源附件上传Amazon，或是在此处对消息塞入一些客户端信息、反作弊Token等，支持异步操作。

7、业务接入能力

业务只需要在上层提供针对消息以及会话两个维度的配置，就能基于内置的交互能力，构建出一套基础的IM消息流能力。

在具体的消息样式呈现上，则通常需要业务层维护一组关于「消息类型-消息组件类型-消息结构」的映射关系。

具体关联如下：

在交互能力上，提供了IM场景的标准能力，业务可以按需使用。

另外，实际IM场景可能需要一些更为丰富的定制能力，则可以依据方案提供的消息数据源接口、消息交互接口来对具体交互实现进行定制。同时也可以使用相关的交互钩子对交互过程进行干预，以适应自己的业务。

8、本文小结

本文对团队IM场景的现状做了简单介绍，撇开具体实现细节，就如何搭建一套能够适应多业务需要的通用IM消息流交互层方案，提供了一些思考和实践经验。

从结果来看，该方案稳定支撑了团队多个IM场景，抹除各场景实现差异，有效降低了维护成本和新业务接入成本。

9、参考资料

[1] 零基础IM开发入门(一)：什么是IM聊天系统？

[2] 一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

[3] 一套原创分布式即时通讯(IM)系统理论架构方案

[4] 从游击队到正规军(二)：马蜂窝旅游网的IM客户端架构演进和实践总结

[5] 社交软件红包技术解密(十)：手Q客户端针对2020年春节红包的技术实践

[6] 微信团队分享：来看看微信十年前的IM消息收发架构，你做到了吗

[7] 携程技术分享：亿级流量的办公IM及开放平台技术实践

[8] 百度公共IM系统的Andriod端IM SDK组件架构设计与技术实现

[9] 转转平台IM系统架构设计与实践(一)：整体架构设计

[10] 一年撸完百万行代码，企业微信的全新鸿蒙NEXT客户端架构演进之路

[11] 转转客服IM聊天系统背后的技术挑战和实践分享

[12] B站IM消息系统的新架构升级实践

[13] 企业微信针对百万级组织架构的客户端性能优化实践

[14] 企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等

[15] 从客户端的角度来谈谈移动端IM的消息可靠性和送达机制

[16] 现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障

[17] IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）

[18] IM开发干货分享：有赞移动端IM的组件化SDK架构设计实践

[19] 阿里技术分享：闲鱼IM基于Flutter的移动端跨端改造实践

[20] IM开发干货分享：万字长文，详解IM“消息“列表卡顿优化实践

[21] IM开发干货分享：IM客户端不同版本兼容运行的技术思路和实践总结

[22] 百度统一socket长连接组件从0到1的技术实践

[23] 淘宝移动端统一网络库的架构演进和弱网优化技术实践

[24] 抖音技术分享：飞鸽IM桌面端基于Rust语言进行重构的技术选型和实践总结

[25] 大型IM工程重构实践：企业微信Android端的重构之路

即时通讯技术学习：
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文同步发布于：http://www.52im.net/thread-4905-1-1.html）

Jack Jiang 2026-04-20 18:43 发表评论

现代IM系统中聊天消息的同步和存储方案探讨

Jack Jiang — Tue, 14 Apr 2026 03:39:00 GMT

本文作者阿里云高级技术专家木洛，有优化和修订。

1、前言

IM全称是“Instant Messaging”，中文名是即时通讯。在这个高度信息化的移动互联网时代，生活中IM类产品已经成为必备品，比较有名的如钉钉、微信、QQ等以IM为核心功能的产品。当然目前微信已经成长为一个生态型产品，但其核心功能还是IM。还有一些非以IM系统为核心的应用，最典型的如一些在线游戏、社交应用，IM也是其重要的功能模块。可以说，带有社交属性的应用，IM功能一定是必不可少的。

IM系统在互联网初期即存在，其基础技术架构在这十几年的发展中更新迭代多次，从早期的CS、P2P架构，到现在后台已经演变为一个复杂的分布式系统，涉及移动端、网络、安全和存储等技术的方方面面。其支撑的规模也从早期的少量日活，到现在微信这个巨头最新公布的达到9亿的日活的体量。

IM系统中最核心的是消息系统，消息系统最核心的是消息的同步和存储：

1）消息的同步：将消息完整的、快速的从发送方传递到接收方，就是消息的同步。消息同步系统最重要的衡量指标就是消息传递的实时性、完整性以及能支撑的消息规模。从功能上来说，一般至少要支持在线和离线推送，高级的IM系统还支持“多端同步”；

2）消息的存储：消息存储即消息的持久化保存，这里不是指消息在客户端本地的保存，而是指云端的保存，功能上对应的就是“消息漫游”。“消息漫游”的好处是可以实现账号在任意端登陆查看所有历史消息，这也是高级IM系统特有的功能之一。

本文内容主要涉及IM系统中的消息系统架构，探讨一种适用于大用户量的消息同步以及存储系统的架构实现，能够支持消息系统中的高级特性“多端同步”以及“消息漫游”。在性能和规模上，能够做到全量消息云端存储，百万TPS以及毫秒级延迟的消息同步能力。

2、架构设计

本章主要会介绍基于TableStore的现代IM消息系统的架构设计，在详细介绍架构设计之前，会先介绍一种Timeline逻辑模型，来抽象和简化对IM消息同步和存储模型的理解。理解了Timeline模型后，会介绍如何基于此模型对消息的同步以及存储进行建模。基于Timeline模型，在实现消息同步和存储时还会有各方面的技术权衡，例如如何对消息同步常见的读扩散和写扩散两种模型进行对比和选择，以及针对Timeline模型的特征如何来选择底层数据库。

▲ 上图是消息系统传统架构与现代架构的简单对比

传统架构下，消息是先同步后存储：

对于在线的用户，消息会直接实时同步到在线的接收方，消息同步成功后，并不会进行持久化。而对于离线的用户或者消息无法实时同步成功时，消息会持久化到离线库，当接收方重新连接后，会从离线库拉取所有未读消息。当离线库中的消息成功同步到接收方后，消息会从离线库中删除。传统的消息系统，服务端的主要工作是维护发送方和接收方的连接状态，并提供在线消息同步和离线消息缓存的能力，保证消息一定能够从发送方传递到接收方。服务端不会对消息进行持久化，所以也无法支持消息漫游。

现代架构下，消息是先存储后同步：

先存储后同步的好处是，如果接收方确认接收到了消息，那这条消息一定是已经在云端保存了。并且消息会有两个库来保存，一个是消息存储库，用于全量保存所有会话的消息，主要用于支持消息漫游。另一个是消息同步库，主要用于接收方的多端同步。
消息从发送方发出后，经过服务端转发，服务端会先将消息保存到消息存储库，后保存到消息同步库。完成消息的持久化保存后，对于在线的接收方，会直接选择在线推送。但在线推送并不是一个必须路径，只是一个更优的消息传递路径。
对于在线推送失败或者离线的接收方，会有另外一个统一的消息同步方式。接收方会主动的向服务端拉取所有未同步消息，但接收方何时来同步以及会在哪些端来同步消息对服务端来说是未知的，所以要求服务端必须保存所有需要同步到接收方的消息，这是消息同步库的主要作用。对于新的同步设备，会有消息漫游的需求，这是消息存储库的主要作用，在消息存储库中，可以拉取任意会话的全量历史消息。

以上是传统架构和现代架构的一个简单的对比，现代架构上整个消息的同步和存储流程，并没有变复杂太多，但是其能实现多端同步以及消息漫游。现代架构中最核心的就是两个消息库“消息同步库”和“消息存储库”，是消息同步和存储最核心的基础。而本篇文章接下来的部分，都是围绕这两个库的设计和实现来展开。

3、Timeline模型

在分析“消息同步库”和“消息存储库”的设计和实现之前，在本章会先介绍一个逻辑模型-Timeline。Timeline模型会帮助我们简化对消息同步和存储模型的理解，而消息库的设计和实现也是围绕Timeline的特性和需求来展开。

▲ Timeline模型

如图是Timeline模型的一个抽象表述，Timeline可以简单理解为是一个消息队列，但这个消息队列有如下特性：

1）每个消息拥有一个顺序ID（SeqId），在队列后面的消息的SeqId一定比前面的消息的SeqId大，也就是保证SeqId一定是增长的，但是不要求严格递增；

2）新的消息永远在尾部添加，保证新的消息的SeqId永远比已经存在队列中的消息都大；

3）可根据SeqId随机定位到具体的某条消息进行读取，也可以任意读取某个给定范围内的所有消息。

有了这些特性后，消息的同步可以拿Timeline来很简单的实现。图中的例子中，消息发送方是A，消息接收方是B，同时B存在多个接收端，分别是B1、B2和B3。A向B发送消息，消息需要同步到B的多个端，待同步的消息通过一个Timeline来进行交换。A向B发送的所有消息，都会保存在这个Timeline中，B的每个接收端都是独立的从这个Timeline中拉取消息。每个接收端同步完毕后，都会在本地记录下最新同步到的消息的SeqId，即最新的一个位点，作为下次消息同步的起始位点。服务端不会保存各个端的同步状态，各个端均可以在任意时间从任意点开始拉取消息。

消息漫游也是基于Timeline，和消息同步唯一的区别是，消息漫游要求服务端能够对Timeline内的所有数据进行持久化。

基于Timeline，从逻辑模型上能够很简单的理解在服务端如何去实现消息同步和存储，并支持多端同步和消息漫游这些高级功能。落地到实现的难点主要在如何将逻辑模型映射到物理模型，Timeline的实现对数据库会有哪些要求？我们应该选择何种数据库去实现？这些是接下来会讨论到的问题。

4、消息存储模型

▲ 基于Timeline的消息存储模型

如图是基于Timeline的消息存储模型，消息存储要求每个会话都对应一个独立的Timeline。如图例子所示，A与B/C/D/E/F均发生了会话，每个会话对应一个独立的Timeline，每个Timeline内存有这个会话中的所有消息，服务端会对每个Timeline进行持久化。服务端能够对所有会话Timeline中的全量消息进行持久化，也就拥有了消息漫游的能力。

5、消息同步模型

消息同步模型会比消息存储模型稍复杂一些，消息的同步一般有读扩散和写扩散两种不同的方式，分别对应不同的Timeline物理模型。

▲ 读扩散和写扩散两种不同同步模式下对应的不同的Timeline模型

如图是读扩散和写扩散两种不同同步模式下对应的不同的Timeline模型，按图中的示例，A作为消息接收者，其与B/C/D/E/F发生了会话，每个会话中的新的消息都需要同步到A的某个端，看下读扩散和写扩散两种模式下消息如何做同步。

读扩散：

消息存储模型中，每个会话的Timeline中保存了这个会话的全量消息。读扩散的消息同步模式下，每个会话中产生的新的消息，只需要写一次到其用于存储的Timeline中，接收端从这个Timeline中拉取新的消息。
优点是消息只需要写一次，相比写扩散的模式，能够大大降低消息写入次数，特别是在群消息这种场景下。但其缺点也比较明显，接收端去同步消息的逻辑会相对复杂和低效。接收端需要对每个会话都拉取一次才能获取全部消息，读被大大的放大，并且会产生很多无效的读，因为并不是每个会话都会有新消息产生。

写扩散：

写扩散的消息同步模式，需要有一个额外的Timeline来专门用于消息同步，通常是每个接收端都会拥有一个独立的同步Timeline，用于存放需要向这个接收端同步的所有消息。
每个会话中的消息，会产生多次写，除了写入用于消息存储的会话Timeline，还需要写入需要同步到的接收端的同步Timeline。在个人与个人的会话中，消息会被额外写两次，除了写入这个会话的存储Timeline，还需要写入参与这个会话的两个接收者的同步Timeline。而在群这个场景下，写入会被更加的放大，如果这个群拥有N个参与者，那每条消息都需要额外的写N次。
写扩散同步模式的优点是，在接收端消息同步逻辑会非常简单，只需要从其同步Timeline中读取一次即可，大大降低了消息同步所需的读的压力。其缺点就是消息写入会被放大，特别是针对群这种场景。

在IM这种应用场景下，通常会选择写扩散这种消息同步模式。

IM场景下，一条消息只会产生一次，但是会被读取多次，是典型的读多写少的场景，消息的读写比例大概是10:1。若使用读扩散同步模式，整个系统的读写比例会被放大到100:1。

一个优化的好的系统，必须从设计上去平衡这种读写压力，避免读或写任意一维触碰到天花板。所以IM系统这类场景下，通常会应用写扩散这种同步模式，来平衡读和写，将100:1的读写比例平衡到30:30。

当然写扩散这种同步模式，还需要处理一些极端场景，例如万人大群。针对这种极端写扩散的场景，会退化到使用读扩散。一个简单的IM系统，通常会在产品层面限制这种大群的存在，而对于一个高级的IM系统，会采用读写扩散混合的同步模式，来满足这类产品的需求。采用混合模式，会根据数据的不同类型和不同的读写负载，来决定用写扩散还是读扩散。

6、典型架构设计

如上图所示，是一个典型的消息系统架构。

该典型的消息系统架构中包含几个重要组件：

1）端：作为消息的发送和接收端，通过连接消息服务器来发送和接收消息。

2）消息服务器：一组无状态的服务器，可水平扩展，处理消息的发送和接收请求，连接后端消息系统。

3）消息队列：新写入消息的缓冲队列，消息系统的前置消息存储，用于削峰填谷以及异步消费。

4）消息处理：一组无状态的消费处理服务器，用于异步消费消息队列中的消息数据，处理消息的持久化和写扩散同步。

5）消息存储和索引库：持久化存储消息，每个会话对应一个 Timeline 进行消息存储，存储的消息建立索引来实现消息检索。

6）消息同步库：

写扩散形式同步消息，每个用户的收件箱对应一个 Timeline，同步库内消息不需要永久保存，通常对消息设定一个生命周期。

新消息会由端发出，通常消息体中会携带消息 ID（用于去重）、逻辑时间戳（用于排序）、消息类型（控制消息、图片消息或者文本消息等）、消息体等内容。

消息会先写入消息队列，作为底层存储的一个临时缓冲区。消息队列中的消息会由消息处理服务器消费，可以允许乱序消费。消息处理服务器对消息先存储后同步，先写入发件箱 Timeline（存储库），后写扩散至各个接收端的收件箱（同步库）。

消息数据写入存储库后，会被近实时的构建索引，索引包括文本消息的全文索引以及多字段索引（发送方、消息类型等）。

对于在线的设备，可以由消息服务器主动推送至在线设备端。对于离线设备，登录后会主动向服务端同步消息。每个设备会在本地保留有最新一条消息的顺序 ID，向服务端同步该顺序 ID 后的所有消息。

7、消息库设计

基于Timeline模型，以及Timeline模型在消息存储和消息同步的应用，我们看下消息同步库和消息存储库的设计。

▲ 基于Timeline的消息库设计

消息同步库：

消息同步库用于存储所有用于消息同步的Timeline，每个Timeline对应一个接收端，主要用作写扩散模式的消息同步。
这个库不需要永久保留所有需要同步的消息，因为消息在同步到所有端后其生命周期就可以结束，就可以被回收。但是如前面所介绍的，一个实现简单的多端同步消息系统，在服务端不会保存有所有端的同步状态，而是依赖端自己主动来做同步。
所以服务端不知道消息何时可以回收，通常的做法是为这个库里的消息设定一个固定的生命周期，例如一周或者一个月，生命周期结束可被淘汰。

消息存储库：

消息存储库用于存储所有会话的Timeline，每个Timeline包含了一个会话中的所有消息。这个库主要用于消息漫游时拉取某个会话的所有历史消息，也用于读扩散模式的消息同步。
消息同步库和消息存储库，对数据库有不同的要求，如何对数据库做选型，在下面会讨论。

8、数据库选型

消息系统最核心的两个库是消息同步库和消息存储库，两个库对数据库有不同的要求：

总结下来，对数据库的要求有如下几点：

1）表结构设计能够满足Timeline模型的功能要求：不要求关系模型，能够实现队列模型，并能够支持生成自增的SeqId；
2）能够支持高并发写和范围读，规模在十万级TPS；
3）能够保存海量数据，百TB级；
4）能够为数据定义生命周期。

9、本文小结

本文主要介绍了现代IM系统中消息推送和存储架构的实现，基于逻辑的Timeline模型，我们可以很清晰明了的理解整个消息推送和存储的架构。而基于Timeline的消息存储和推送模型，其实不光可以应用在IM消息系统中，还可应用在例如Feeds流、实时消息同步、直播弹幕等场景。

10、参考资料

[1] 浅谈IM系统的架构设计

[2] 简述移动端IM开发的那些坑：架构设计、通信协议和客户端

[3] 一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

[4] 一套原创分布式即时通讯(IM)系统理论架构方案

[5] 从零到卓越：京东客服即时通讯系统的技术架构演进历程

[6] 蘑菇街即时通讯/IM服务器开发之架构选择

[7] 腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT

[8] 移动端IM中大规模群消息的推送如何保证效率、实时性？

[9] 子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践

[10] 微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）

[11] 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

[12] 社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等

[13] 社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进

[14] 从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路

[15] 瓜子IM智能客服系统的数据架构设计（整理自现场演讲，有配套PPT）

[16] 阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处

[17] IM开发基础知识补课(十)：大型IM系统有多难？万字长文，搞懂异地多活！

[18] 阿里技术分享：电商IM消息平台，在群聊、直播场景下的技术实践

[19] 一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等

[20] 从新手到专家：如何设计一套亿级消息量的分布式IM系统

[21] 企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等

[22] 融云技术分享：全面揭秘亿级IM消息的可靠投递机制

[23] IM开发技术学习：揭秘微信朋友圈这种信息推流背后的系统设计

[24] 阿里IM技术分享(三)：闲鱼亿级IM消息系统的架构演进之路

[25] 基于实践：一套百万消息量小规模IM系统技术要点总结

[26] 跟着源码学IM(十)：基于Netty，搭建高性能IM集群（含技术思路+源码）

[27] 一套十万级TPS的IM综合消息系统的架构实践与思考

[28] 直播系统聊天技术(八)：vivo直播系统中IM消息模块的架构实践

[29] 得物从0到1自研客服IM系统的技术实践之路

[30] 海量用户IM聊天室的架构设计与实践

[31] 企业微信针对百万级组织架构的客户端性能优化实践

[32] 一套分布式IM即时通讯系统的技术选型和架构设计

[33] 陌陌技术分享：陌陌IM在后端KV缓存架构上的技术实践

[34] 微信团队分享：来看看微信十年前的IM消息收发架构，你做到了吗

[35] 携程技术分享：亿级流量的办公IM及开放平台技术实践

[36] 转转平台IM系统架构设计与实践(一)：整体架构设计

[37] 支持百万人超大群聊的Web端IM架构设计与实践

[38] 一年撸完百万行代码，企业微信的全新鸿蒙NEXT客户端架构演进之路

[39] 转转客服IM聊天系统背后的技术挑战和实践分享

[40] B站IM消息系统的新架构升级实践

[41] 如何保障分布式IM聊天系统的消息有序性（即消息不乱）

[42] 新手入门一篇就够：从零开发移动端IM

[43] 移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”

[44] 零基础IM开发入门(一)：什么是IM聊天系统？

即时通讯技术学习：
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文内容引用自：http://www.52im.net/thread-1230-1-1.html）

Jack Jiang 2026-04-14 11:39 发表评论

即时通讯安全篇（十六）：对称加密 vs 非对称加密？一文搞懂！

Jack Jiang — Thu, 09 Apr 2026 04:29:00 GMT

本文由vivo 互联网服务器团队Deng Qian分享，有排版和内容优化。

1、引言

在了解加密原理前，我们来看看这样一个故事：

小红和小明是情侣，一天，小红给小明发短信说：“亲爱的，我银行卡上没有钱了，你给我转1万块钱吧。”有过上当受骗经历的人都知道这有可能是小偷偷了小红手提包，然后拿手机发的短信。
不过我们小明学过加密原理，于是他回复说：“你直接拿我的银行卡刷吧，密码加上我们第一次约会的日期就是663156。”
很明显，只有小明和小红知道他们第一次约会是什么时候，假设是2008年4月1号，那么小红就可以根据计算663156-200841=462315得到银行卡密码，就可以消费了。

这就是加密的本质：将信息与密钥相加得到加密后的信息，只有知道密钥的人才能解密。

本文将以通俗案例讲解加密本质，介绍对称加密（含 AES、迪菲–赫尔曼密钥交换）与非对称加密（RSA）原理、特点及应用，并阐释其数学基础。

2、系列文章

3、什么是秘钥

既然加密需要密钥，那么密钥是什么呢？

密钥是作用于加密时的一串密码，通过密钥进行信息加密，传输，到达接收者和监听者，由于接收者也有密钥，所以接收者可以根据密钥进行解密。从而防止通讯信息泄露。

4、什么是对称加密

前言讲的故事就是一个对称式加密，小明和小红都知道第一次约会的日期。所以传统的对称式加密需要通讯双方都保存同一份密钥，通过这份密钥进行加密和解密。所以对称加密也称为单密钥加密。

对称加密的优势在于加解密速度快，但是安全性较低，密钥一旦泄露，所有的加密信息都会被破解。同时密钥的传输和保密也成为难题。为了解决密钥传输的问题，出现通过密钥交换建立共享密钥的技术。具体如何建立共享密钥呢？我们往下看。

5、对称加密之建立共享密匙

在小明、小红和小偷的三人世界中，由于小明是学过加密原理的，知道迪菲–赫尔曼密钥交换（Diffie-Hellman Key Exchange），所以他知道如何建立共享密钥。

5.1 颜料混合把戏

接下来我们看看如何通过颜料混合把戏建立共享密钥吧。

假设在房间中有小明、小红和小偷三个人，每个人各自拥有相同颜色的颜料。在房间的正中间也有这些颜料。接下来，小明要和小红建立共享密钥了。
此时，小明对大家说：“我要用蓝色。”然后小明从自己的颜料里选择了黄色，这个黄色就是小明的私钥，小红和小偷都不知道。
小明将自己的私钥黄色与公钥蓝色混合后，得到了一种不能分解的颜色，我们就叫“小明-蓝色”吧（虽然大家都知道黄+蓝变绿，但是这里我们为了知道是谁的混合色，还是以名字加公钥颜色来称呼），然后小明将“小明-蓝色”公布了出来。
同样，小红听到了小明说用蓝色后，也选择了自己的私钥红色与公钥蓝色混合，得到了“小红-蓝色”并公布了出来。

此时，房间中小明、小红、小偷三人都知道了几个信息：

1）他们都用了蓝色；
2）小明公布了“小明-蓝色”（小红和小偷不知道是什么颜料与蓝色的混合）；
3）小红公布了“小红-蓝色”（小红和小偷不知道是什么颜料与蓝色的混合）。

接下来，见证奇迹的时刻到了：小明拿到“小红-蓝色”与自己的私钥“黄色”混合，得到“小红-蓝色-小明”的新颜料。同样的，小红拿到“小明-蓝色”与自己的私钥“红色”混合，得到“小明-蓝色-小红”。大家发现了吗？“小红-蓝色-小明”和“小明-蓝色-小红”是一模一样的颜色。而小偷不知道小明和小红的私钥颜色，无法混合出与他们相同的颜色。

至此，共享密钥建立起来了。在了解了共享密钥的建立过程后，我们将告别实体颜料，采用数字的方式来建立共享密钥。

注：大家可能想到了，小偷可以根据自己的颜料与公钥“蓝色”混合，尝试得出“小明-蓝色”和“小红-蓝色”。这样的方法称之为穷举法，也就是尝试所有的可能性，进行信息破解，所以加密算法在理论上都是可以通过穷举法破解的，只不过实际上，超级计算机都需要计算万亿年才能穷举出所有可能性。

5.2 乘法把戏

首先，我们假设乘法如同颜料混合一样，是不能分解的，看看如何用乘法与数字建立共享密钥。

小明公开了一个数字5，然后小明选择了一个私人数字4，然后利用乘法将两者混合起来，得到“小明-5”（20），接下来小红也选择了一个私人数字7得到“小红-5”（35），小明拿到35*4=140，小红拿到20*7=140。共享密钥建立完成。

大家也发现了，小偷知道20,35,5这三个数字后，用除法就能算出小明和小红的私钥。所以，接下来我们将了解实际使用中的如何使用乘法把戏来防止私钥被计算出来的。

6、对称加密之迪菲·赫尔曼密钥交换算法

我们都知道幂运算，但是要让计算机计算就比较难了。所以，我们会用幂运算作为建立共享密钥的乘法把戏。同时，我们还要了解钟算的原理，这里的钟可以理解成我们经常看到的时钟，我们常见的时钟最大是12，如果当前是10点，过了4个小时后，就变成了下午2点。也就是(10+4)mod12=2。了解了钟算和幂运算后，就开始进入正题吧。

还是小明、小红和小偷的房间，小明声明了钟为11，幂运算的底为2，接下来小明和小红分别选择了自己的私钥4和7。

1）第一步：小明混合自己的“小明-11,2”得到，小红混合自己的“小红-11,2”得到。

2）第二步：小明拿到“小红-11,2”（7）进行计算，小红拿到“小明-11,2”（5）进行计算。

大家注意到了吗：小明和小红建立了共享密钥3，而小偷无法根据已知的11、2、5、7这几个数字计算出密钥或小明小红的私钥。有了共享密钥后，小明和小红就可以安全进行加密传输了。

迪菲－赫尔曼密钥交换：

7、对称加密之AES加密过程

AES 的全称是 Advanced Encryption Standard ，是最流行的对称加密算法，其加解密速度快。

AES支持128位，192位，256位三种长度的密钥，密钥越长安全性越高。AES加密时会把明文切分成许多小块的明文，然后对每块明文单独加密，将加密后的密文传送出去，接收方再将密文切块解密，得到明文。如下图所示。

AES加密原理：

上一步中小明和小红已经协商好了密钥3。接下来就可以通过对称加密进行通信了。

在小明、小红和小偷的房间中，小明想把密码“462315”告诉小红，于是：

1）第一步：将密码按照一位的长度进行切分（实际中通常按128位进行切分）；就变成了“4”“6”“2”“3”“1”“5”；

2）第二步：对每块明文通过密钥3进行加密，结果就是“795648”，然后小明告诉小红和小偷：“我的密码是795648”；

3）第三步：小红拿到密文后，对密文进行切块，对每块通过密钥3进行解密，就得到了正确的密码“462315”，而小偷由于不知道密钥，就无法解密出正确的信息。

8、什么是非对称加密

8.1 概述

在对称加密中，加密和解密使用的是同一份密钥。所以，在非对称加密中，加密和解密使用的是不同的密钥。

非对称加密中的密钥分为公钥和私钥。公钥顾名思义就是公开的，任何人都可以通过公钥进行信息加密，但是只有用户私钥的人才能完成信息解密。非对称加密带来了一个好处，避免了对称式加密需要传输和保存同一份密钥的痛苦。

现在最流行的非对称加密算法就是RSA加密算法，具体是怎么做的呢，我们继续往下看。

8.2 RSA加密过程

百科是这么解释的：

RSA加密算法是一种非对称加密算法，在公开密钥加密和电子商业中被广泛使用。RSA是由罗纳德·李维斯特（Ron Rivest）、阿迪·萨莫尔（Adi Shamir）和伦纳德·阿德曼（Leonard Adleman）在1977年一起提出的。当时他们三人都在麻省理工学院工作。RSA 就是他们三人姓氏开头字母拼在一起组成的。

▲ RSA算法的作者合影（照片拍摄于1978年）

前面我们讲了如何通过钟算和幂函数建立不可逆（计算机可以通过穷举法计算出私钥，实际场景中就算是超级计算机也要计算几万亿年之久）的共享密钥。由于小红是小明的女朋友，小明天天在小红面前给她讲RSA加密算法的原理，所以小红也知道怎么得出自己的公钥和私钥。

接下来我们一起跟着小红的脚步，看看RSA加密的公钥和私钥是怎么计算出来的：

1）第一步：小红选择了两个很大的质数p和q，这里为了便于计算，选择2和11;
2）第二步：计算p和q的乘积n=p*q=2*11=22；
3）第三部：计算n的欧拉函数φ(n)=(p-1)*(q-1)=10；
4）第四步：选择一个小于φ(n)且与φ(n)互质的整数e，{1,3,7,9}，这里选择e=7；
5）第五步：计算e对于φ(n)的模反元素（ed mode φ(n) = 1）d，d=3。

到这里小红就得到了他自己的公钥(n,e)和私钥(n,d)。其中n就是钟大小，e和d就是幂函数的幂。接下来就通过计算出来的公钥和私钥进行数据的加解密。

还是小明、小红和小偷三个人，小红对大家说，我的公钥是（22,7），小明知道了小红的公钥后，想讲自己的信息“14”告诉小红，于是就用小红公开的公钥进行加密。

具体步骤如下：

1）第一步：小明根据要加密的信息14进行计算，得到加密后的信息20，然后将20告诉小红和小偷；
2）第二步：小红有自己的私钥，将加密信息20进行解密，，得到了小明想传递给小红的信息。而小偷呢，知道22,7,20，但是不知道小红的密钥（22,3），无法解密出正确的信息。

RSA加密算法在数字签名中也发挥着巨大的作用：假设小偷可以假冒小红，说小红的公钥是（22,9），而小明不知道是小偷假扮的，按照小偷的公钥加密后，结果被小偷解密了。数字签名的作用就是防止信息被篡改，小红说她的公钥是（22,7）的同时，使用私钥给这段信息（通常使用MD5值计算签名）加上签名，小明得到公钥（22,7）和签名13，小明拿到签名后利用公钥计算出信息是否被篡改。

9、加密的实际作用

本文使用的很小的数来进行加密原理的讲解，为了是读者可以方便进行计算。

在实际使用中（n,e）都是特别大的数，其中n的长度都在768以上，1024长度被认为是基本安全的。

（1230186684530117755130494958384962720772853569595334792197322452151726400507263657518745202199786469389956474942774063845925192557326303453731548268507917026122142913461670429214311602221240479274737794080665351419597459856902143413=
33478071698956898786044169848212690817704794983713768568912431388982883793878002287614711652531743087737814467999489
×
36746043666799590428244633799627952632279158164343087642676032283815739666511279233373417143396810270092798736308917）

10、写在最后

或许看到这里，大家心里还有许多疑惑：

1）为什么小明和小红建立共享密钥时，通过几次幂运算和钟算就能得到一样的共享密钥？
2）为什么RSA加密算法要用两个质数？
3）为什么通过公钥加密的信息可以通过私钥解开？

加密算法的背后，是一道道迷人的数学难题。而RSA加密算法之所以被广泛运用，是因为一个名为整数分解的古老数学问题，你可以轻易找到两个很大的质数相乘得到一个结果n，但是要将这个结果n分解回两个质数就变得极其困难。尽管这个所谓的“整数分解”问题被研究了数个世纪，还没人能找到一个足够高效的通用方法解决它，并对标准RSA钟大小造成危害。

数学史中充满了未解决的问题，尽管这些迷人的问题缺乏任何实际应用，却单靠其美学特质就吸引了数学家进行深入探究。

令人颇感惊讶的是，许多这类迷人但显然无用的问题后来都有了很大的实用价值，这一价值只有在问题被研究数个世纪后才得以破解。整数分解这一问题由来已久。对其最早的严肃研究似乎是在17世纪，由数学家费马（Fermat）和梅森（Mersenne）进行的。欧拉（Euler）和高斯（Gauss）两位数学“泰斗”也在接下来的世纪里对这一问题做出了贡献。但直到公钥加密于20世纪70年代被发明，分解大数字的困难才成为一个实际应用的关键。

11、本文小结

最后总结一下。

首先：我们通过一个诈骗短信的例子，引出了加密的原理就是信息+密钥，密钥就是对信息进行加解密的一串数字。

然后：通过颜料混合把戏形象的演示了如何建立共享密钥。在使用乘法建立共享密钥的过程中，学习了钟算和幂运算，接着我们了解了RSA加密算法的过程，通过两个质数生成公钥和私钥。

最后：我们根据公钥进行信息加密，再通过私钥完成信息解密。

12、参考资料

[1] 探讨组合加密算法在IM中的应用

[2] 一文读懂常用加解密算法与网络通讯安全

[3] 非对称加密技术的原理与应用实践

[4] 你知道，HTTPS用的是对称加密还是非对称加密？

[5] IM聊天系统安全手段之通信连接层加密技术

[6] IM聊天系统安全手段之传输内容端到端加密技术

[7] 信创必学，一文读懂什么是国密算法的

[8] 传输层安全协议SSL/TLS的Java平台实现简介和Demo演示

[9] 理论联系实际：一套典型的IM通信协议设计详解（含安全层设计）

[10] 微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解

[11] 来自阿里OpenIM：打造安全可靠即时通讯服务的技术实践分享

[12] 简述实时音视频聊天中端到端加密（E2EE）的工作原理

[13] 移动端安全通信的利器——端到端加密（E2EE）技术详解

[14] 通俗易懂：一篇掌握即时通讯的消息传输安全原理

[15] 一分钟理解 HTTPS 到底解决了什么问题

[16] 一篇读懂HTTPS：加密原理、安全逻辑、数字证书等

[17] 基于Netty的IM聊天加密技术学习：一文理清常见的加密概念、术语等

[18] 手把手教你为基于Netty的IM生成自签名SSL/TLS证书

[19] 即时通讯初学者必知必会的20个网络编程和通信安全知识点

[20] 零基础IM开发入门(五)：什么是IM系统的端到端加密？

[21] 微信团队分享：来看看微信十年前的IM消息收发架构，你做到了吗

[22] 零基础IM开发入门(一)：什么是IM系统？

[23] 一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等

[24] 转转平台IM系统架构设计与实践(一)：整体架构设计

[25] 一套分布式IM即时通讯系统的技术选型和架构设计

即时通讯技术学习：
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文已同步发布于：http://www.52im.net/thread-4899-1-1.html）

Jack Jiang 2026-04-09 12:29 发表评论

网络编程入门如此简单(五)：UDP跟TCP相比，到底差了什么？

Jack Jiang — Tue, 17 Mar 2026 07:35:00 GMT

本文由悟空聊架构分享，有修订和排版优化。

1、引言

本文将通俗易懂地为你类比解释UDP与TCP的核心差异，包括如何基于UDP实现TCP的可靠传输：通过模拟三次握手、添加序列号与确认机制解决顺序和丢包问题，利用滑动窗口控制流量，并引入拥塞控制算法来动态调整发送速率等。

2、系列文章

本文是该系列文章中的第 5 篇：

3、写在前面

本题是我在面试中，技术总监问我的一道真题，当时答得不太好，所以把它揪出来总结了下。后来问了下总监，总监说这是阿里的面试题。。

其实面试官主要是想让我说出 UDP 和 TCP 的原理上的区别，怎么给 UDP 加些功能实现 TCP。

看好去很容易就能说出一两个 TCP 和 UDP 的区别，但如果能用女朋友都能听懂的方式该怎么说呢？

女朋友：我不想听课本上讲的！我听不懂呀~

下面我会以大白话的方式来解答上面的问题。

4、UDP协议的主要特点

UDP 让我想起了刚毕业参加工作那会，一名毕业菜鸟。

1）沟通简单：

领导安排的任务，直接干就完了。

UDP 也是，相信网络世界永远是美好的，我发送的包是很容易送到的，接收方也是很容易组装的。数据结构也很简单，不需要大量的数据结构、处理逻辑、包头字段。

2）轻信他人：

测试人员报的 bug 我也不会和她争论什么，永远相信测试人员是对的，测试人员说啥就是啥，我改就是。

UDP 也是，不会建立连接，有个端口号，谁都可以监听这个端口号往上面发数据。也可以从这个端口号传给任何人数据。反正我只管发就是。

3）不会讨价还价：

产品经理昨天说手机壳需要根据心情变色，测试人员说这个 bug 要把关联的两个 bug 一起修掉。那就按照他们说的做吧！

UDP 也是，不懂坚持和退让。也就是根据网络情况进行拥塞控制。无论网络丢包多严重，我还是照样发~

5、UDP协议的使用场景

针对像我那时候毕业菜鸟的情况，领导给我安排了三种工作环境让我选。

1）内部系统，任务简单，模块单一，不需要考虑代码的关联影响，即使失败了也没有关系。

UDP 也是，需要资源少，网络情况比较好的内网，或者对于丢包不敏感的应用。

2）有一个强力的团队支持，都是中高级开发、测试人员，团队成员打过很多年交道，互相信任。有什么问题，吼一嗓子就可以了！

UDP 也是，不需要一对一沟通来建立连接，可以广播的应用。

3）一个新项目，需要有激情，对于刚毕业的菜鸟，都是有很强的自主能动性的，也不会耍滑头，躲在厕所玩手机，带薪拉shi ？即使项目不忙，我也抓紧时间干。项目忙，还是一样干！

UDP 也是，猛着发包就是，主要应用在需要处理速度快，时延低，可以容忍少数丢包的情况。即使网络情况不佳，发包就是~

针对上面的三大场景，UDP 常用在实时竞技游戏，IoT 物联网，移动通信领域。

6、TCP协议的主要特点

6.1 面向连接

TCP 和 UDP 是传输层里面比较重要的两个协议。大部分面试的时候都会问到两者的区别。而大部分都会两句，比如 TCP 是面向连接的，UDP 是面向无连接。

那什么是面向连接？

TCP 三次握手是我们常常念叨和背诵的。而在这三次握手成功后，就是建立连接成功。

那什么又叫面向呢？

我们也常听到面向对象编程、面向切面编程、面向服务编程。那到底什么是面向？

在我看来面向就是遵循一定的协议、规范、数据结构等来做一系列事情。

比如面向连接，就是为了在客户端和服务端维护连接，而建立一定的数据结构来维护双方交互的状态，用这样的数据来保证所谓的面向连接的特性。

知道了 TCP 的是用三次握手来建立连接，那我们是否可以让 UDP 也发三个包来模拟 TCP 建立连接？可以是可以，但是如果只是建立，而不是面向连接，其实意义不大。

那 TCP 面向连接做了哪些事情？

TCP 提供可靠交付，通过 TCP 连接传输的数据，可以无差错、不丢失、不重复、并且按序到达。而 UDP 继承了 IP 包的特性，不保证不丢失，不保证按顺序到达。

6.2 面向字节流

TCP 是面向字节流，所谓字节流，就是发的是一个流，没头没尾。TCP 自己维护流状态。

UDP 基于 IP 数据报，一个一个地发，一个一个地收。

6.3 拥塞控制

TCP 拥有拥塞控制，如果包丢弃了或者网络环境不好了，就会根据网络情况自行控制自己的行为，看下是发快点还是发慢点。

UDP 则没有这么智能了，你让我发，我就发呗，反正是你让我发的，其他的一概不管~

6.4 有状态服务

TCP 是一个有状态的服务，有状态可以理解为：我记录了哪些发送了，哪些没有发送，哪些接收到了，哪些没接收到，应该接收哪个了，一点差错都不行。TCP 干的事情可真多！

而 UDP 则不是有状态的服务，我只管发，其他的就交给接收端吧，有点任性是吧？

7、如何让UDP追上TCP的能力？

建立连接上面已经讲到了，三次握手和四次握手，UDP 也可以模拟去做。

那下面还有几个问题：

1）顺序问题；
2）丢包问题；
3）流量控制；
4）拥塞控制。

TCP 的数据结构长这样：

其实如果你能把这些结构讲清楚，就已经理解了 TCP 的核心功能。下面我还是用大白话的方式来讲解上面的四个问题。

顺序问题和丢包问题可以利用确认与重发的机制。假如包收到了，可以做一个确认，发送一个 ACK 给发送端，告诉他我收到了。假如有的包提前到了，就缓存着。假如有包丢失了，就可以超时重试。超时重试不宜过短，时间必须大于往返时间 RTT，否则会引起不必要的重传。也不宜过长，如果超时时间过长，访问就变慢了。那怎么确定这个时间，可以通过采样 RTT 的时间，进行加权平均。还需要根据网络状况，动态变化。可以了解下自适应重传算法。

流量控制就是根据网络情况调整发包的速率。利用的是滑动窗口。在对于包的确认中，同时会携带一个窗口的大小，只要利用好这个窗口大小，就能很好地调整发包速率，发的报文段不要超过窗口的大小就 OK。

拥塞控制主要用来避免包丢失和超时重传，如果出现了这两种现象，就说明发的速率太快了。那最开始怎么知道发送速率呢？其实开始时只发送一个报文段数据，如果收到一个确认，则倍增报文段，依次类推。当发现超时重传时，就又回到只发送一个报文段的情况，这个就是慢启动，这种方式不合适。其实还有一种快速重传算法，简单来说就是拥塞窗口减半，后续线性增速。针对于算法怎么实现的，这里就不展开讲述了。

至此，我用大白话的方式讲解了 UDP 和 TCP 的区别，以及 UDP 缺什么功能，需要怎么去弥补才能实现 TCP 的功能。相信这样回答的思路可以让面试官觉得还是有点东西的。

8、参考资料

[1] TCP/IP详解 - 第11章·UDP：用户数据报协议

[2] TCP/IP详解 - 第17章·TCP：传输控制协议

[3] 通俗易懂-深入理解TCP协议（上）：理论基础

[4] 通俗易懂-深入理解TCP协议（下）：RTT、滑动窗口、拥塞处理

[5] 快速理解TCP协议一篇就够

[6] 快速理解TCP和UDP的差异

[7] 快速理解为什么说UDP有时比TCP更有优势

[8] 一泡尿的时间，快速搞懂TCP和UDP的区别

[9] 跟着动画来学TCP三次握手和四次挥手

[10] 假如你来设计网络，会怎么做？

[11] 假如你来设计TCP协议，会怎么做？

[12] 深入地理解UDP协议并用好它

[13] 如何让不可靠的UDP变的可靠？

[14] UDP比TCP高效？还真不一定！

[15] 可靠传输的TCP协议send成功就意味着数据一定发出去了？

[16] 为何基于TCP协议的移动端IM仍然需要心跳保活机制？

[17] 技术扫盲：新一代基于UDP的低延时网络传输层协议——QUIC详解

即时通讯技术学习：
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文已同步发布于：http://www.52im.net/thread-4897-1-1.html）

Jack Jiang 2026-03-17 15:35 发表评论

基于WebSocket的IM即时通信方案在H5游戏场景下的技术实践

Jack Jiang — Mon, 02 Mar 2026 13:56:00 GMT

摘要: 本文由网易云音乐技术团队入云分享，有修订和排版优化。1、引言说起 IM，大家应该都或多或少了解过一些，一般被熟知是在一些聊天场景里应用的比较多；而一般情况下我们常接触的业务中大多是做一些接口的查询提交之类的操作，用正常的 Ajax 请求就足以满足需求，比较难接触到 IM 这种方案。但如果涉及到一些需要频繁更新数据的业务场景，使用常规接口查询难免会给服务端造成比较大的性能开销，并且数据更新的延迟也会... 阅读全文

Jack Jiang 2026-03-02 21:56 发表评论

鸿蒙Next原生IM即时通讯RainbowTalk，纯ArkTS编写，基于开源MobileIMSDK框架

Jack Jiang — Wed, 25 Feb 2026 09:47:00 GMT

1、基本介绍

RainbowTalk 是一套基于 MobileIMSDK 开源通信框架的产品级纯血鸿蒙NEXT端IM系统。RainbowTalk与姊妹产品 RainbowChat技术同源，不同于市面上某些开源或售卖的demo级代码，RainbowChat已被成千上万真实的客户使用过，解决了大量的产品逻辑、代码逻辑、细节优化等问题。
RainbowTalk 由纯ArkTS编写、全新开发，没有套壳、也没走捷径，原生“纯血”（详见：《RainbowTalk详细介绍》）。
RainbowTalk 无闭源代码（包括核心通信层），这与市面上知识产权来路不明、无核心技术、无售后的“三无”产品，或打着开源名义实则闪烁其词不开源核心的产品有本质区别。
RainbowTalk 是 RainbowChat 和 RainbowChat-Web 的姊妹产品。
☞ 详细介绍：http://www.52im.net/thread-4822-1-1.html
☞ 运行截图：http://www.52im.net/thread-4824-1-1.html （运行视频）
☞ 下载体验：http://www.52im.net/thread-4825-1-1.html

2、关于MobileIMSDK开源框架

MobileIMSDK 是一套全平台开源IM即时通讯聊天框架，超轻量级、高度提炼，一套API优雅支持UDP 、TCP 、WebSocket 三种协议，客户端支持iOS、Android、H5、小程序、Uniapp、标准Java、纯血鸿蒙等，服务端基于Netty编写，性能卓越、易于扩展。
工程同步开源地址：
❶ GitHub：https://github.com/JackJiang2011/MobileIMSDK
❷ 码云gitee： https://gitee.com/jackjiang/MobileIMSDK
❸ Gitcode：https://gitcode.com/hellojackjiang2011/MobileIMSDK

3、功能情况

1）支持文本消息、语音留言消息、图片消息、大文件消息（支持断点上传）、短视频消息、个人名片、群名片、Emoji表情、消息撤回、消息转发、消息引用、“@”功能、“扫一扫”功能等；
2）支持一对一陌生人聊天模式；
3）支持一对一正式好友聊天模式；
4）支持多对多群聊聊天模式；
5）完善的群组信息管理：建群、退群、解散、转让、邀请、踢人、群公告等；
6）完整的注册、登陆（同时支持手机验证码登录和密码登录）、密码找回等功能闭环；
7）个人中心功能：改基本信息、改个性签名、改头像、改密码等；
8）支持个人相册查看；
9）完整的离线消息/指令拉取机制；
10）完整的本地消息/指令缓存机制，节省网络流量；
11）完整的富媒体文件（语音、大文件、图片、短视频）缓存机制，节省网络流量；
12）完整的好友关系管理：查找好友、发出请求、处理请求、删除好友、好友备注等；
13）其它未提及的功能和特性请自行下载体验。
RainbowTalk线上版本目前仅作演示和研究之用，运行环境配置最小化（仅1核1G和1MB带宽），请客观评估。

4、技术亮点

1）与姊妹产品RainbowChat 技术同源（算法和功能逻辑历经时间考验和大量客户面辐射，可靠性一定优于短时间内堆砌功能的产品）；
2）从通信底层到上层功能，完全自主开发——版权清晰、技术资产可控；
3）超轻量级——纯ArkTS编写且无任何重依赖；
4）通讯核心层基于MobileIMSDK 工程，保证了业务代码与通信核心的高度分层（经验不足的IM产品是做不到这一点的）；
5）支持完整的消息送达保证（QoS）机制，保证送达率，理论丢包率约为0.0001%；
6）基于 MobileIMSDK 工程的自有协议，未来的流量压缩对于APP端的节电控制和流量控制、服务端的网络吞吐等都有完全的控制能力；
7）完善的网络状况自动检测、断网重连等服务自动治愈能力；
8）核心通信算法和实现均为自主原创（历经10年，并非开源拼凑），保证了技术的持续改进、升级、扩展；
9）聊天协议兼容和互通：实现了与姊妹产品RainbowChat、RainbowChat-Web的完全兼容和消息互通；

5、技术原则

为了更易学习、研究、2次开发，RainbowTalk始终遵从：
1）界面与通信解偶：UI界面与网络通信层和数据处理层代码解耦，UI界面的重构、维护、改版都非常容易和优雅；
3）核心内聚和收敛：得益于长期的提炼和经验积累，网络通信核心层高度封装，开发者无需理解复杂网络算法。
4）纯 ArkTS 实现：纯ArkTS编写，无重量级框架和库依赖（更无Native代码），可干净利落地对接各种既有系统；
5）跨平台运行能力：受益于鸿蒙系统的跨端特性，理论上本应用的客户端可运行于任何支持鸿蒙Next的平台上；
6）架构设计简洁：简单直接，易于学习，能少一个分层则绝不强行炫技；
7）简单地就是最好的：始终贯彻简单直接的互联网产品技术理念。

6、主要功能运行截图

（☞ 更多运行截图、更多运行视频、详细介绍 ☜)
（本文内容引用自：http://www.52im.net/thread-4822-1-1.html）

Jack Jiang 2026-02-25 17:47 发表评论

如何保障分布式IM聊天系统的消息可靠性（即消息不丢）

Jack Jiang — Mon, 02 Feb 2026 07:42:00 GMT

本文引用了45岁老架构师尼恩的技术分享，有修订和重新排版。

1、引言

接上篇《如何保障分布式IM聊天系统的消息有序性（即消息不乱）》，本文主要聚焦分布式IM聊天系统消息可靠性问题，即如何保证消息不丢失。

2、系列文章

为了更好以进行内容呈现，本文拆分两了上下两篇。

本文是2篇文章中的第 1 篇：

《如何保障分布式IM聊天系统的消息有序性（即消息不乱）》
《如何保障分布式IM聊天系统的消息可靠性（即消息不丢）》（☜ 本文）

本篇主要聚焦的是分布式IM聊天系统消息可靠性问题。

3、痛点拆解：聊天消息总是丢？不是网络差，是设计没兜底

产品做着做着，用户开始投诉：“我明明发了消息，对方怎么没收到？”。你查日志发现——消息真丢了。但更可怕的是：你也不知道它什么时候丢的。

这背后，其实是移动场景下的经典三连击：

1）地铁进隧道，网络闪断；
2）App 被系统杀掉，进程没了；
3）对方服务器刚好在发布，接口500……

你以为只是“发一下”，其实要穿越重重险境才能抵达。

结果就是：

- 消息发不出去 → 用户以为被无视；
- 或者重试太多 → 对方收到一堆重复“在吗？”；
- 最后用户体验崩了，客服工单爆了。

所以问题本质不是“快不快”，而是：

“宁可慢点，也不能丢；就算重发，也不能重复。”

这就是我们常说的可靠消息投递 ——一个看似简单的需求，却是高可用系统的分水岭。

4、解决方案：三层兜底，像保险一样层层防

光靠“发一次”肯定不行。

我们要学保险公司，给关键消息上三重保险：

1）自己先复印一份存档 → 客户端本地存
2）邮局签收后锁进保险柜，并异地备份 → 服务端落盘 + 副本
3）如果没收到回执，隔段时间再寄，但对方只认一次 → 超时重试 + 幂等去重

每一层都不贵，合起来却能扛住99%的异常。下面看每层怎么落地。

5、第一层：客户端兜底 —— 消息先存本地，解决网络不稳定问题

记住一句话：只要没收到 ACK，就当没发成功。

所以第一步不是联网，而是先把消息塞进手机本地数据库（比如 SQLite）。

就像下面这样：

db.saveLocalMsg(msg); // 先落库，保命
boolean sendOk = network.send(msg);
if (!sendOk) {
scheduleRetry(msg, 1000); // 发失败？排队重试
}

再加上客户端scheduleRetry 采用阶梯式重试策略：

1）第1次失败 → 1秒后重试
2）第2次失败 → 3秒后重试
3）第3次失败 → 5秒后重试

避免雪崩式刷屏，既保障可靠性，又不压垮服务。只有等到服务端明确说“我收到了”，才把这条消息从本地删掉。

就像快递发货单：客户签收了，你才能撕票。

这样哪怕 App 崩溃、手机重启，下次打开照样继续发——用户体验无缝衔接。而如果不做这一步？一旦断网或崩溃，消息直接蒸发，用户永远不知道。

6、第二层：服务端兜底 —— 实现服务端持久化的高可靠

客户端发来了，服务端能不能直接处理完就返回？绝对不行！

如果此时机器宕机，消息还在内存里没来得及持久化，那就真的丢了。

正确做法是两步走：

1）收到消息立刻写入 RocketMQ（支持刷盘、集群同步）；
2）同步复制到至少3个副本节点，确保单点故障不丢数据。

伪代码如下：

rocketMQ.send(msg); // 必须落盘，断电也不怕
replicaService.syncTo3Replicas(msg); // 多副本容灾
response.sendAck(msg.getUniqueKey()); // 此时才能回 ACK

这一步的关键是：ACK 必须在落盘之后发！否则就是“虚假确认”，等于骗客户端“我收到了”，其实自己也没保住。

这一层扛住了服务端单机崩溃的风险，是整个链路的数据基石。

7、第三层：幂等性设计 —— 保障exact one

前面两层解决了“存得住”的问题，但这还不够。现实是：网络可能超时、包可能丢失、ACK 可能没传回来。

于是客户端必须重试。但重试带来新问题：

“我已经处理过了，再来一遍怎么办？”

解决办法是：用唯一键 + 幂等控制。

每个消息生成全局唯一的 key（如 sessionID:msgID），服务端通过 Redis 的原子操作判断是否已处理。

就像下面的代码这样：

String uniqueKey = msg.getUniqueKey();
if (redis.setNx(uniqueKey, "processed", 86400)) {
processMsg(msg); // 第一次来，正常处理
} else {
log.info("重复消息，忽略：{}", uniqueKey);
}

setNx 是关键：只有 key 不存在时才设置成功，保证多实例并发下也不会重复消费。

8、IM消息可靠性架构的核心流程总结

上面三层如何联动？一张图讲清楚全链路生命周期：

整条链路形成闭环：任何环节出问题，都有对应兜底机制接管。

9、本文小结

至此，《如何保障分布式IM聊天系统的消息有序性和可靠性》这期文章的上下两篇就完结了（上篇点此查看），上篇涉及到的分布式IM聊天系统架构中关于消息有序性问题，下篇则主要聚焦的是消息可靠性问题。

如果你是IM开发新人，想要系统地学习移动端IM开发的话，建议从我整理的这篇《新手入门一篇就够：从零开发移动端IM》开始，这样能保证IM开发知识能从网络到应用层、再从局部设计到整体架构，都有一个系统的学习脉络而不是在信息碎片中苦苦总结。

10、参考资料

[1] 什么是IM聊天系统的可靠性？

[2] 什么是IM聊天系统的消息时序一致性？

[3] 微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）

[4] 马蜂窝旅游网的IM系统架构演进之路

[5] 一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等

[6] 从新手到专家：如何设计一套亿级消息量的分布式IM系统

[7] 企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等

[8] 融云技术分享：全面揭秘亿级IM消息的可靠投递机制

[9] 阿里IM技术分享(四)：闲鱼亿级IM消息系统的可靠投递优化实践

[10] 阿里IM技术分享(八)：深度解密钉钉即时消息服务DTIM的技术设计

[11] 基于实践：一套百万消息量小规模IM系统技术要点总结

[12] 一套分布式IM即时通讯系统的技术选型和架构设计

[13] 转转平台IM系统架构设计与实践(一)：整体架构设计

[14] 移动端弱网优化专题(一)：通俗易懂，理解移动网络的“弱”和“慢”

[15] 移动端弱网优化专题(二)：史上最全移动弱网络优化方法总结

[16] Web端即时通讯实践干货：如何让你的WebSocket断网重连更快速？

[17] 从客户端的角度来谈谈移动端IM的消息可靠性和送达机制

[18] IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递

[19] 移动端IM中大规模群消息的推送如何保证效率、实时性？

[20] 如何保证IM实时消息的“时序性”与“一致性”？

[21] 一个低成本确保IM消息时序的方法探讨

即时通讯技术学习：
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文已同步发布于：http://www.52im.net/thread-4889-1-1.html）

Jack Jiang 2026-02-02 15:42 发表评论

如何保障分布式IM聊天系统的消息有序性（即消息不乱）

Jack Jiang — Mon, 19 Jan 2026 13:29:00 GMT

本文引用了45岁老架构师尼恩的技术分享，有修订和重新排版。

1、引言

分布式IM聊天系统中，IM消息怎么做到不丢、不重、还按顺序到达？

这个问题，涉及到IM系统的两个核心：

1）消息不能丢（可靠性）：比如用户点了发送，不能因为服务宕机或网络抖动，消息石沉大海。比如地铁隧道、电梯间，网络断了又连，消息不能卡住不动（要确保弱网也能用）。

2）顺序不能乱（有序性）：比如“在吗？” 回成 “吗在？”，群聊时间线错乱，体验直接崩盘。

这二大痛点，是IM聊天系统架构的命门所在。

下面是一张IM消息从发出到接收的关键路径：

2、系列文章

为了更好以进行内容呈现，本文拆分两了上下两篇。

本文是2篇文章中的第 1 篇：

《如何保障分布式IM聊天系统的消息有序性（即消息不乱）》（☜ 本文）
《如何保障分布式IM聊天系统的消息可靠性（即消息不丢）》（稍后发布..）

本篇主要总结和分享分布式IM聊天系统架构中关于消息有序性的设计和实践。

3、传统技术方案的瓶颈，怎么破？

早期做消息有序，很多人第一反应是搞个“全局发号器”——所有消息排一队，挨个编号再发。

理想很丰满，现实很骨感：高并发下一拥而上抢号，发号器直接被打满；更致命的是，它一旦宕机，全链路雪崩。

这就像春运火车站只开一个售票窗——再快也撑不过三分钟。

所以，我们必须换思路：不搞大一统，而是分片独立发号，让每个“窗口”自给自足，互不干扰。

4、痛点拆解：为什么消息会乱？

我们先还原一个真实场景：想象一下你和朋友聊天：

你说：“1 吃饭了吗？”
他回：“2 刚吃完。”
你又说：“3 吃啥呢？”

结果对方手机上显示成：

“3 吃啥呢？” → “1 吃饭了吗？” → “2 刚吃完。”

这不是 bug，是分布式系统的常态。

三条消息走不同服务节点、经不同网络路径，到达时间完全不可控，最终呈现顺序错乱。

会乱问题本质是什么？一个要“串行等”，一个想“并发冲”，天然冲突。

这时候有人会说：那我加个全局排序服务不就行了？

可以，但代价太大——一个中心节点最多撑几万 QPS，面对百万群聊、亿级用户，还没上线就已过载。

所以，全局有序不是解，而是枷锁。我们要的不是“天下大同”，而是“各聊各的别乱就行”。

5、最终方案：分而治之 + 局部有序

真正的突破口在于：我们根本不需要全局有序，只需要“会话内有序”。

你和张三的聊天记录不能乱，但你和李四的聊天跟王五的完全无关——何必放一起排序？

这就引出了经典策略：分而治之 + 局部有序。

具体怎么做？两步走稳：

* 第一步 - 业务分区：哈希分片，锁定归属

用 sessionId 做一致性哈希，确保同一个会话的所有消息始终路由到同一个处理节点。按“会话ID”做哈希，算出该消息该由哪个节点处理。同一会话 → 哈希值一样 → 路由到同一台机器 → 所有消息串行处理，天然避免跨节点乱序。

这样一来，单个会话内的消息在服务端就是串行处理的，天然不会乱。

* 第二步 - 局部序号：独立发号，局部递增

每个会话独立维护一个计数器，每来一条消息就+1，作为它的“官方序号”。每个会话,可以配一个独立计数器（比如 Redis 的 INCR），每来一条消息就+1，生成唯一 SEQ。客户端不管什么时候收到消息，只认这个序号，按序号从小到大排列展示。

这个 SEQ 就是这条消息的“官方身份证号”，客户端只认这个，不看接收时间。这就像电影院检票——你可以早到晚到，但座位按票号定。哪怕后排观众先进场，也不会坐到前排去。

PS：IM消息ID生成相关的文章可详细阅读以下资料：

6、实践落地（核心片段伪代码）

1）服务端分片路由逻辑：

来看关键实现：如何把消息精准投递给“对的人”。

String sessionId = msg.getSessionId();
//这里是伪代码，实际代码以mq 的负载均衡机制为准
int nodeIndex = Math.abs(sessionId.hashCode()) % clusterNodeCount;
//这里写个伪代码，代表mq 主从复制
ClusterNode targetNode = clusterNodes.get(nodeIndex);
targetNode.sendMsg(msg);

核心就一句：基于会话 ID 哈希取模，固定路由。

从此，每个会话都有了自己的“专属服务通道”，不再受其他会话影响。

2）服务端序号分配逻辑：

接下来，给每条消息发“通行证”：

long msgSeq = redis.incr("msg_seq_" + sessionId);
msg.setSeq(msgSeq);
msg.setUniqueKey(sessionId + "_" + msgSeq);

这里用了 Redis 的 INCR，保证同一个会话下的 SEQ 绝对递增，且线程安全。同时用 sessionId_seq 作为唯一键，既能幂等去重，也能防止重试导致消息重复入库。

实战提示：

如果你的 Redis 是集群模式，记得确保同一个会话的 key 落在同一 slot，否则 INCR 可能跨节点失效。

3）客户端排序逻辑：

最后一步，客户端收尾：别急着渲染，先排好队。

//这里是伪代码，先排序
List sortedMsgs = msgList.stream()
.sorted(Comparator.comparingLong(Msg::getSeq))
.collect(Collectors.toList());
//这里是伪代码，再渲染
renderMsgList(sortedMsgs);

无论消息以什么顺序到达，统统按 seq 升序排列后再上屏。哪怕第100条先到，第1条后到，也能正确归位。这也是为什么我们强调“客户端必须信任服务端 SEQ”——它是唯一真相源。

7、方案总结：放弃全局有序，换高可用与高性能

总结一下，这套方案的核心思想就一句话：

不要为“假需求”买单——我们不需要全局有序，只需要业务上有意义的有序。

你看微信、钉钉、飞书，哪一个是把全平台消息排成一条队列的？没有。

它们都选择了“会话级隔离 + 局部有序”的设计，这才是工业级系统的通用解法。

背后的分布式哲学也很清晰：

最终换来的是：

1）高并发支持（水平扩展）；
2）高可用（无单点）；
3）强一致体验（用户无感知）。

这正是中高级开发者必须掌握的权衡思维：

不是技术做不到，而是要不要做。

有时候，“不做全局有序”，反而是最正确的选择。

8、 IM消息有序性架构的核心流程总结

最后，一张图串起全流程：

从发起到渲染，全程围绕“会话隔离”和“局部发号”展开。每一个环节都在为同一个目标服务：在分布式环境下，低成本实现用户可感知的“顺序正确”。

—— 下篇《如何保障分布式IM聊天系统的消息可靠性（即消息不丢）》稍后发布，敬请期待 ——

9、参考资料

[1] 什么是IM聊天系统的可靠性？

[2] 什么是IM聊天系统的消息时序一致性？

[3] 微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）

[4] 马蜂窝旅游网的IM系统架构演进之路

[5] 一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等

[6] 从新手到专家：如何设计一套亿级消息量的分布式IM系统

[7] 企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等

[8] 融云技术分享：全面揭秘亿级IM消息的可靠投递机制

[9] 阿里IM技术分享(四)：闲鱼亿级IM消息系统的可靠投递优化实践

[10] 阿里IM技术分享(八)：深度解密钉钉即时消息服务DTIM的技术设计

[11] 基于实践：一套百万消息量小规模IM系统技术要点总结

[12] 一套分布式IM即时通讯系统的技术选型和架构设计

[13] 转转平台IM系统架构设计与实践(一)：整体架构设计

[14] 移动端弱网优化专题(一)：通俗易懂，理解移动网络的“弱”和“慢”

[15] 移动端弱网优化专题(二)：史上最全移动弱网络优化方法总结

[16] Web端即时通讯实践干货：如何让你的WebSocket断网重连更快速？

[17] 从客户端的角度来谈谈移动端IM的消息可靠性和送达机制

[18] IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递

[19] 移动端IM中大规模群消息的推送如何保证效率、实时性？

[20] 如何保证IM实时消息的“时序性”与“一致性”？

[21] 一个低成本确保IM消息时序的方法探讨

即时通讯技术学习：
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文已同步发布于：http://www.52im.net/thread-4887-1-1.html）

Jack Jiang 2026-01-19 21:29 发表评论

B站即时通讯IM消息系统的新架构升级实践

Jack Jiang — Tue, 06 Jan 2026 09:34:00 GMT

本文由B站技术团队比奇堡、Xd、三木森分享，有修订和重新排版。

1、引言

本文要分享的是B站IM消息系统的新架构升级实践总结，内容包括原架构的问题分析，新架构的整体设计以及具体的升级实现等。

B站技术团队的其它技术文章：

2、消息系统业务解读

按业务全域现状，在服务端角度分成客服系统、系统通知、互动通知和私信4个业务线，每个业务线内按现状标识了服务分层。私信内分为用户单聊、bToC的批量私信、群聊和应援团小助手四类，这四类细分私信没有技术解耦，单聊和批量私信比较接近系统天花板。

私信单聊发送到触达的pv转化和uv转化不足10%，有明显通过业务优化提升触达率的潜力。

3、消息系统中的私信业务

私信域内的几个概念解释：

1）会话列表：按聊天人排序的列表。即B站首页右上角信封一跳后看到的历史聊天人列表，以及点击未关注人等折叠会话看到的同属一类的聊天人列表。传达对方账号、最新私信和未读数的信息。点击一个会话后看到的是对聊历史，也称会话历史。

2）会话详情：描述和一个聊天人会话状态的原子概念，包括接收人uid、发送人uid、未读数、会话状态、会话排序位置等。

3）会话历史：按时间线对发送内容排序的列表。一份单聊会话历史既属于自己，也属于另一个和自己的聊天的人。群聊的会话历史属于该群，不属于某个成员。会话历史是收件箱和消息内容合并后的结果。

4）收件箱：将一次发送的时序位置映射到发送内容唯一id的kv存储，可以让服务端按时间序读取一批发送内容唯一id。

5）私信内容：一个包括发送内容唯一id、原始输入内容、消息状态的原子概念。批量私信把同一个发送内容唯一id写入每个收信人的收件箱里。

6）timeline模型：时间轴的抽象模型，模型包括消息体、已读位点、最大位点、生产者、消费者等基本模块，可以用于基于时间轴的数据同步、存储和索引。私信涉及timeline模型的包括会话列表和会话历史。

7）读扩散：pull模式。群聊每条私信只往群收件箱写一次，让成百上千的群成员在自己的设备都看到，是典型的读扩散。

8）写扩散：push模式。单聊每条私信既更新接收人会话也更新发送人会话，是轻微的写扩散，无系统压力。群聊有另一个不一样的特点，就是当群成员发送消息后，需要通过长链接通知其他群成员的在线设备，以及发送人其他的在线设备，这是一个写扩散的技术模型，但是这个写扩散是通知后即时销毁的，并且具有过期时间，所以仅临时占用资源，并不对存储造成压力，且能有较好的并发量。

私信核心概念关系表达：

4、消息系统问题1：会话慢查询

当会话缓存过期时，Mysql是唯一回源，Mysql能承载的瞬时QPS受当时应用总连接数和sql平均响应速度的影响，连接数打满时会给前端返回空会话列表。虽然可以增加POD数量、增大akso proxy连接数、优化sql和索引来作为短线方案，来提升瞬时请求Mysql容量，但是这种短线方案无法加快单次响应速度，mysql响应越来越慢的的问题依然在。另外增加POD数量也会降低发版速度。

会话Mysql使用用户uid%1000/100分库，用户uid%100分表，table总量是1000。

单表会话量在1kw-3.2kw。单个大up的会话积累了10W条以上，会话量最大的用户有0.2亿条会话。单个Up的会话会落到一张表中，每张表都有比较严重的数据倾斜。如果考虑增加分库分表的方案，sql查找条件依然需要用户uid，所以相当于倾斜数据要转移到新的单表，问题没有解决。另外，重新分库分表过程中新旧table增量同步和迁移业务读写流量的复杂度也很大，有比较大的业务风险。

Mysql的规格是48C 128G和32C 64G。由于会话数据量大，Mysql buffer_pool有限，数据比较容易从内存淘汰，然后mysql需要进行磁盘扫描并将需要的数据加载到内存进行运算，加之比较多的磁盘扫描数据，这时的响应一般在秒级别，接口会给前端返回超时错误，会话列表页空白。

为了适配业务发展，Mysql 会话表已经添加了9个非聚集索引，如果通过增加索引使用业务需要，需要更大的Mysql资源，且解决不了冷数据慢查询的问题。增加更多索引也会让Mysql写入更慢。

5、消息系统问题2：私信内容单表空间和写性能接近天花板

每条私信内容都绑定私信自己的发号器生成的msgkey，即私信内容唯一id，该msgkey包含私信发送时的时间戳（消息ID生成可参阅读《微信的海量IM聊天消息序列号生成实践》）。读写私信内容Mysql之前先从msgkey解析出时间，用这个时间路由分库分表。

私信内容库按季度分库，分库内按月度分表，单表数据量数亿，数据量最大的用户日增私信351.9W条。按照曲率预测，25年全年数据量有近百亿，如果继续按照月度分表，分表规则不适应增长。

当前该Mysql最大写qps 790，特别活动时写qps峰值预计是20k，但是为了保障Mysql服务整体的可靠，单库写流量我们需要控制在3000qps以下，无法满足写入量峰值时的需要。

此外，消息内容表结构包含了群聊、单聊和应援团小助手全部的属性，增加业务使用难度。绝大部分私信内容是单聊的。

6、消息系统问题3：服务端代码耦合

B站的四类私信包括：

1）单聊；
2）群聊；
3）B端批量私信；
4）应援团小助手。

这些私信都需要实现发送和触达两条核心链路，四种私信核心链路的代码逻辑和存储耦合在一起，代码复杂度随着业务功能上线而不断增加，熵增需要得到控制。

从微服务这方面来说，实例和存储耦合会带来资源随机竞争，当一方流量上涨，可能给对方的业务性能带来不必要的影响，也会带来不必要的变更传导。

7、消息系统新架构的升级路径

基于对私信现状的论述，可以确定我们要优化的是一个数据密集型 >> 计算密集型，读多写少（首页未读数）、读少写多（会话）场景兼具的系统。

同时需要拥有热门C端产品的稳定性、扩展性和好的业务域解耦。针对读多写少和读少写多制定了针对的技术方案。

具体的实施情况请继续往下阅读。

8、新架构的整体设计

结合B站业务现状，我觉得比较合理的架构：

一个兼顾复杂列表查询架构和IM架构的消息域框架，整体分四层：

1）接入层：即toC的BFF和服务端网关；
2）业务层：按复杂查询设计系统，用于各种业务形态的支撑；
3）平台层：按IM架构设计系统，目标是实时、有序的触达用户，平台层可扩展；
4）触达层：对接长链和push。

9、新架构具体升级1：端上本地缓存降级

端上应该支持部分数据缓存，以确保极端情况下用户端可展示，可以是仅核心场景，比如支付小助手、官号通知，用户在任何情况下打开消息页都不应该白屏。

10、新架构具体升级2：BFF架构升级

BFF网关吸收上浮的业务逻辑，控制需求向核心领域传导。服务端基于业务领域的能力边界，抽象出单聊、群聊、系统通知、互动通知和消息设置共五个新服务，提升微服务健康度。

新服务剥离了历史包袱，也解决一些在老服务难解的功能case，优化了用户体验，比如消息页不同类型消息的功能一致性；重新设计会话缓存结构和更新机制，优化Mysql索引，优化Mysql查询语句，减少了一个量级的慢查询。

11、新架构具体升级3：服务端可用性升级

11.1 概述

服务端按四层拆分后，集中精力优化业务层和平台层。

业务层：按复杂查询设计系统，用于各种业务形态的支撑

1）冷热分离：多级缓存 redis(核心数据有过期)+taishan(有限明细数据)+mysql(全部数据)；
2）读写分离：95%以上复杂查询可以迁移到从库读。

平台层：按IM架构设计系统，目标是实时、有序的触达用户，平台层可扩展

1）Timeline模型：依赖雪花发号器，成熟方案；
2）读写扩散：单聊-写扩散，群聊-读扩散。

11.2 单聊会话

1）缓存主动预热：

用户在首页获取未读数是一个业务域内可以捕捉的事件，通过异步消费这个事件通知服务端创建会话缓存，提高用户查看会话的缓存命中率。鉴于大部分人打开B站并不会进私信，此处可以仅大UP预热。大UP的uid集合可以在数平离线分析会话数据后写入泰山表，这个泰山表更新时效是T+1。

监控UP会话数量实时热点，触发突增阈值时，通过异步链路自动为热点用户主动预热会话列表缓存。

对预热成功率添加监控，并在数平离线任务失败或者预热失败时做出业务告警，及时排查原因，避免功能失效。

2）泰山和Mysql双持久化：

增加泰山存储用户有限会话明细，作为redis未命中后的第一回源选择，Mysql作为泰山之后的次选。基于用户翻页长度分析后确定泰山存储的有限会话的量级。

redis 存储24小时数据，taishan 存储 600条/用户（20页），预设到的极端情况才会回源mysql从库。

对于ZSET和KV两种数据结构，评估了各自读写性能的可靠性，符合业务预期。业务如果新增会话类型，可以跟本次新增泰山有限明细一样，基于会话类型的具体规则新增泰山Key。

3）泰山长尾优化：

查询redis未命中时会优先回源泰山，考虑到泰山99分位线在50ms以下，而且Mysql多从实例都能承受来自C端的读请求，所以采用比泰山报错后降级Mysql稍微激进的对冲回源策略。

在泰山出现“长尾”请求时，取得比较好的耗时优化效果。可以使用大仓提供的error group结合quit channel实现该回源策略，同时能避免协程泄漏。整个处理过程在业务响应和资源开销中维持中间的平衡，等待泰山的时间可以灵活调整。

泰山最初没有数据，可以在泰山未命中时进行被动加载，保证用户回访时能命中。

4）一致性保证：

虽然我们重构了新服务，但是老服务也需要保留，用来处理未接入BFF的移动端老版本和web端请求，这些前端在更新会话时（比如ACK）请求到了老服务，新服务需要通过订阅会话Mysql binlog异步更新本服务的redis和泰山。为了避免分区倾斜，订阅binlog的dts任务使用id分区，这样方便的是一条会话在topic的分区是固定的。

为了避免两次请求分别命中泰山和Mysql时给用户返回的数据不一样，需要解决三大问题：

a. 当出现分区rebalance需要避免重复消费；
b. 当Mysql一条会话记录在短时间内（秒级）多次更新，要保证binlog处理器不会逆时间序消费同一个会话的binlog，即跳过较早版本的binlog；
c. 保证泰山写入正确并且从Mysql低延迟同步。

这三个问题都要保证最终一致性，具体解决方案是用redis lua脚本实现compare and swap，lua脚本具有原生的原子性优势。dts每同步一条binlog都会携带毫秒级mtime，当binlog被采用时，mtime被记入redis10分钟，如果下一条binlog的mtime大于redis记录的mtime，这条binlog被采用，否则被丢弃。

这个过程可以考虑使用gtid代替mtime，但这个存在的问题是每个从实例单独维护自己的gtid，当特殊情况发生mysql主从切换，或者dts订阅的从节点发生变更，gtid在CAS计算中变得不再可靠，所以我们选择了使用mtime作为Mysql会话记录的版本。

通过消费路线高性能设计保证泰山异步更新的延迟在1秒以内，并在特殊情况延迟突破1s时有效告警。高性能消费路线中，每个库的binlog分片到50个partition，业务提供不低于50个消费pod，单pod配置100并发数，按照写泰山999分位线20ms计算，每秒可以消费 50*100*(1000/20)=250000 条，大约线上峰值8.3倍，考虑dts本身的max延迟在600~700毫秒，同步泰山和redis的延迟会在700毫秒至1秒以内，符合业务预期。