获得徽章 7
如何保障分布式IM聊天系统的消息可靠性（即消息不丢）💦 聊天消息总是丢？不是网络差，是设计没兜底。本文主要聚焦分布式IM聊天系统消息可靠性问题，即如何保证消息不丢失。
1️⃣ 痛点拆解
产品做着做着，用户开始投诉：“我明明发了消息，对方怎么没收到？”。
你查日志发现——消息真丢了。但更可怕的是：你也不知道它什么时候丢的。问题本质不是“快不快”，而是：“宁可慢点，也不能丢；就算重发，也不能重复。”
这就是我们常说的可靠消息投递 ——一个看似简单的需求，却是高可用IM即时通讯聊天系统的分水岭。
2️⃣ 解决方案：三层兜底
光靠“发一次”肯定不行。我们要给关键消息上三重保险：
1）客户端本地存；
2）服务端落盘 + 副本；
3）超时重试 + 幂等去重。
每一层都不贵，合起来却能扛住99%的异常。
️ 全文阅读：
展开
评论
点赞
全平台开源即时通讯IM框架MobileIMSDK：7端+TCP/UDP/WebSocket协议
MobileIMSDK 是一套全平台开源IM即时通讯聊天框架，超轻量级、高度提炼，一套API优雅支持UDP 、TCP 、WebSocket 三种协议，客户端支持iOS、Android、H5、小程序、Uniapp、标准Java、纯血鸿蒙等，服务端基于Netty编写，性能卓越、易于扩展。
MobileIMSDK的设计目标是让开发者专注于应用逻辑的开发，底层复杂的即时通讯算法交由SDK开发人员，从而解偶即时通讯应用开发的复杂性。
MobileIMSDK一直在持续开发和升级中，纯血鸿蒙Next客户端是 MobileIMSDK 工程的最新成果。
️当前源码仓库：
❶ GitHub：
github.com；
❷ 码云gitee：gitee.com；
❸ Gitcode：gitcode.com。
MobileIMSDK 是一套全平台开源IM即时通讯聊天框架，超轻量级、高度提炼，一套API优雅支持UDP 、TCP 、WebSocket 三种协议，客户端支持iOS、Android、H5、小程序、Uniapp、标准Java、纯血鸿蒙等，服务端基于Netty编写，性能卓越、易于扩展。 MobileIMSDK的设计目标是让开发者专注于应用逻辑的开发，底层复杂的即时通讯算法交由SDK开发人员，从而解偶即时通讯应用开发的复杂性。 MobileIMSDK一直在持续开发和升级中，纯血鸿蒙Next客户端是 MobileIMSDK 工程的最新成果。️当前源码仓库：❶ GitHub：
github.com；❷ 码云gitee：
gitee.com；❸ Gitcode：
gitcode.com。
展开
评论
1
⭐️ 如何保障分布式IM聊天系统的消息有序性（即消息不乱）
💦 分布式IM聊天系统中，IM消息怎么做到不丢、不重、还按顺序到达？
这个问题，涉及到IM系统的两个核心：1）消息不能丢（可靠性），2）顺序不能乱（有序性）。这二大痛点，是IM聊天系统架构的命门所在。
本篇主要总结和分享分布式IM聊天系统架构中关于消息有序性的设计和实践。
💦 分布式IM聊天系统中，IM消息怎么做到不丢、不重、还按顺序到达？
这个问题，涉及到IM系统的两个核心：1）消息不能丢（可靠性），2）顺序不能乱（有序性）。这二大痛点，是IM聊天系统架构的命门所在。
本篇主要总结和分享分布式IM聊天系统架构中关于消息有序性的设计和实践。
展开
评论
1
⭐️ 技术分享：《B站IM即时通讯消息系统的新架构升级实践》
💦 按业务全域现状，在服务端角度分成客服系统、系统通知、互动通知和私信4个业务线，每个业务线内按现状标识了服务分层。
私信内分为用户单聊、bToC的批量私信、群聊和应援团小助手四类，这四类细分私信没有技术解耦，单聊和批量私信比较接近系统天花板。
💦 服务端按四层拆分后，集中精力优化业务层和平台层。
业务层：按复杂查询设计系统，用于各种业务形态的支撑
1）冷热分离：多级缓存 redis(核心数据有过期)+taishan(有限明细数据)+mysql(全部数据)；
2）读写分离：95%以上复杂查询可以迁移到从库读。
平台层：按IM架构设计系统，目标是实时、有序的触达用户，平台层可扩展
1）Timeline模型：依赖雪花发号器，成熟方案；
2）读写扩散：单聊-写扩散，群聊-读扩散。
💦 我们逐步发现技术升级不是一蹴而就的，它是一个逐步优化的过程。
设计技术方案前设立合适和有一些挑战的目标，但这个目标要控制成本，做好可行性。
设计技术方案的时候，需要清楚现有架构与理想架构的差距和具体差异点，做多个方案选型，并确定一个，这个更多从技术团队考虑。
其次要保证功能在新老架构平稳过渡，保证业务的稳定性。后面持续关注新老架构的技术数据，持续优化，老架构要持续关注它的收敛替换。
IM系统是一个老生常谈的话题，也是融合众多有趣技术难点的地方，欢迎感兴趣的同行交流研讨。
（️全文阅读：juejin.cn）
💦 按业务全域现状，在服务端角度分成客服系统、系统通知、互动通知和私信4个业务线，每个业务线内按现状标识了服务分层。
私信内分为用户单聊、bToC的批量私信、群聊和应援团小助手四类，这四类细分私信没有技术解耦，单聊和批量私信比较接近系统天花板。
💦 服务端按四层拆分后，集中精力优化业务层和平台层。
业务层：按复杂查询设计系统，用于各种业务形态的支撑
1）冷热分离：多级缓存 redis(核心数据有过期)+taishan(有限明细数据)+mysql(全部数据)；
2）读写分离：95%以上复杂查询可以迁移到从库读。
平台层：按IM架构设计系统，目标是实时、有序的触达用户，平台层可扩展
1）Timeline模型：依赖雪花发号器，成熟方案；
2）读写扩散：单聊-写扩散，群聊-读扩散。
💦 我们逐步发现技术升级不是一蹴而就的，它是一个逐步优化的过程。
设计技术方案前设立合适和有一些挑战的目标，但这个目标要控制成本，做好可行性。
设计技术方案的时候，需要清楚现有架构与理想架构的差距和具体差异点，做多个方案选型，并确定一个，这个更多从技术团队考虑。
其次要保证功能在新老架构平稳过渡，保证业务的稳定性。后面持续关注新老架构的技术数据，持续优化，老架构要持续关注它的收敛替换。
IM系统是一个老生常谈的话题，也是融合众多有趣技术难点的地方，欢迎感兴趣的同行交流研讨。
（
️全文阅读：juejin.cn）
展开
评论
点赞
⭐️ AI大模型爆火的SSE技术到底是什么？万字长文，一篇读懂SSE！
💦 SSE（Server-Sent Events）是一种基于 HTTP 协议的服务器推送技术，允许服务端主动向客户端发送数据流。SSE 可以被理解为 HTTP 的一个扩展或一种特定用法。
SSE 就像是服务器打开了一个“单向数据管道”，服务器通过HTTP 扩展 可以持续不断地流向浏览器，无需客户端反复发起请求。
SSE 提供了一种简单、可靠的方式来实现服务器向客户端的实时数据推送。它非常适合通知、实时数据更新、日志流和类似 ChatGPT 的逐字输出场景。如果你只需要单向通信，SSE 往往是比 WebSocket 更简单、更轻量的选择。
所以，目前几乎所有主流浏览器都原生支持SSE。
💦 在 SSE 技术出现之前，Web 应用要实现服务器向客户端的实时数据推送，主要依赖短轮询、长轮询、Flash 、 WebSocket这几种技术，但它们都存在明显的缺陷。
Web 领域迫切需要一种标准化的、高效的、由浏览器原生支持的服务器到客户端的单向通信机制。这就是 SSE 诞生的核心背景。
💦 AI 应用需要“打字机”式的逐 token 输出体验，而 SSE 作为一种基于 HTTP 的、简单的、单向的服务器推送技术，是实现这种体验最自然、最高效、最可靠的技术选择。
它就像是为这个场景量身定做的工具，没有多余的功能，只有恰到好处的设计。因此，当 ChatGPT 等应用席卷全球时，其背后默默无闻的 SSE 技术也终于从幕后走到了台前，被广大开发者所重新认识和重视。（️全文阅读：www.52im.net）
💦 SSE（Server-Sent Events）是一种基于 HTTP 协议的服务器推送技术，允许服务端主动向客户端发送数据流。SSE 可以被理解为 HTTP 的一个扩展或一种特定用法。
SSE 就像是服务器打开了一个“单向数据管道”，服务器通过HTTP 扩展 可以持续不断地流向浏览器，无需客户端反复发起请求。
SSE 提供了一种简单、可靠的方式来实现服务器向客户端的实时数据推送。它非常适合通知、实时数据更新、日志流和类似 ChatGPT 的逐字输出场景。如果你只需要单向通信，SSE 往往是比 WebSocket 更简单、更轻量的选择。
所以，目前几乎所有主流浏览器都原生支持SSE。
💦 在 SSE 技术出现之前，Web 应用要实现服务器向客户端的实时数据推送，主要依赖短轮询、长轮询、Flash 、 WebSocket这几种技术，但它们都存在明显的缺陷。
Web 领域迫切需要一种标准化的、高效的、由浏览器原生支持的服务器到客户端的单向通信机制。这就是 SSE 诞生的核心背景。
💦 AI 应用需要“打字机”式的逐 token 输出体验，而 SSE 作为一种基于 HTTP 的、简单的、单向的服务器推送技术，是实现这种体验最自然、最高效、最可靠的技术选择。
它就像是为这个场景量身定做的工具，没有多余的功能，只有恰到好处的设计。因此，当 ChatGPT 等应用席卷全球时，其背后默默无闻的 SSE 技术也终于从幕后走到了台前，被广大开发者所重新认识和重视。（
️全文阅读：www.52im.net）
展开
评论
1
IM即时通讯系统的技术本质是“即时消息技术”，是互联网实时互动场景的底层架构，包括聊天、直播、在线客服等业务领域在内，所有需要实时互动、高实时性的场景，都需要用到IM技术。💦 而为了让即时通讯更安全，高安全场景下的IM系统通常会使用端到端加密技术进行通讯加密。
💦 一般的数据加密可以在通信的3个层次来实现：链路加密、节点加密和端到端加密。
💦 端到端加密允许数据在从源点到终点的传输过程中始终以密文形式存在。采用端到端加密(又称脱线加密或包加密)，消息在被传输时到达终点之前不进行解密，因为消息在整个传輸过程中均受到保护，所以即使有节点被损坏也不会使消息泄露。
💦 在IM系统中，当用户A发送消息给用户B时，IM系统会生成一对公钥和私钥，并将公钥发送给用户B。用户A使用用户B的公钥对消息进行加密，然后将加密后的消息发送给用户B。
💦 在用户B接收到消息后，使用自己的私钥对消息进行解密，从而获取明文内容。由于私钥只有用户B拥有，因此除了用户B之外，任何人都无法解密消息。
（
️ 阅读全文：www.52im.net ）
展开
评论
1
![[太阳]](http://lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_135.5741bcc.png)
零基础IM开发入门：什么是IM聊天系统的消息时序一致性？所谓的一致性，在IM中通常指的是消息时序的一致性，那就是：
1）聊天消息的上下文连续性；
2）聊天消息的绝对时间序。
再具体一点，IM消息的一致性体现在：
1）单聊时：要保证发送方发出聊天消息的顺序与接收方看到的顺序一致；
2）群聊时：要保证所有群员看到的聊天消息，与发送者发出消息时的绝对时间序是一致的。
IM系统中消息时序的一致性问题是个看似简单，实则非常有难度的技术热点话题之一。
![[666]](http://lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_128.e55728c.png)
在普通IM用户的眼里，消息无非是从一台手机传递到另一台手机而已，保证时序有何困难？
是的，普通用户这么认为，从技术上讲，他只是单纯的将IM消息的收发过程理解为单线程的工作模式而已。
实际上，在IM这种高性能场景下，服务端为了追求高吞吐、高并发，用到了多线程、异步IO等等技术。
在这种情况下，“高并发”与“顺序”对于IM服务端来说，本来就是矛盾的，这就有点鱼与熊掌的味道了（两者很难兼得）。
所以，要实现IM场景下的消息时序一致性，需要做出权衡，而且要考虑的技术维度相当多。这就导致具体技术实施起来没有固定的套路，而由于开发者技术能力的参差不齐，也就使得很多IM系统在实际的效果上会有较大问题，对于用户而言也将直接在产品体验上反应出来。（全文阅读：
www.52im.net）
展开
评论
点赞