![](https://img-blog.csdnimg.cn/20201014180756927.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
即时消息技术
文章平均质量分 92
即时消息技术
_Rye_
左手代码右手诗
一行代码一行诗
展开
-
22 | 答疑解惑:不同即时消息场景下架构实现上的异同
其实我想问的是,用户加入直播间,网关机本地维护【本机某个直播间有哪些用户】这个数据的话,当用户离开直播间,加入另一个直播间时,业务处理层还要通知网关层更新本地维护的那个数据,有可能会出现数据不一致的情况,导致用户加入新直播间了,但由于网关层数据没有更新,用户收到不到新直播间的消息。所以,在 App 打开建立好长连后,客户端发出的“上线”这个操作,只是会上报一个当前用户信息,不需要、也没有办法再告知自己当前进入了哪个群,因而在服务端网关机也只会建立一个“用户” -> “连接”的映射。原创 2024-02-29 18:18:46 · 934 阅读 · 0 评论 -
21 | 期末实战:为你的简约版IM系统,加上功能
关于这次期末实战,希望能够完成的功能主要包括以下几个部分:1. 支持基于 WebSocket 的长连接。2. 消息收发均通过长连接进行通信。3. 支持消息推送的 ACK 机制和重推机制。4. 支持客户端的心跳机制和双端的 idle 超时断连。5. 支持客户端断线后的自动重连。原创 2024-02-29 17:21:47 · 821 阅读 · 0 评论 -
20 | 存储和并发:万人群聊系统设计中的几个难点
在场景篇的第 10 讲“自动智能扩缩容:直播互动场景中峰值流量的应对”中,分析了直播互动场景中,容易出现瓶颈的原因主要在于:“直播间人数多,短时间内活跃度高,消息的扇出量巨大”。那么,对于同样属于多人互动的群聊场景来说,虽然在“群人数”等方面与高热度的直播间相比要少一些,但由于同时开播的直播间数量一般不会太多,所以群在数量上的总体量级相对要大得多,可能上百万个群同时会有消息收发的情况发生。因此,在整体的流量方面,群聊场景的消息扇出也是非常大的。原创 2024-02-29 16:21:09 · 828 阅读 · 0 评论 -
19 | 端到端Trace:消息收发链路的监控体系搭建
前面的大部分课程,基本都是围绕“如何开发和设计一个 IM 系统”的技术点,来进行分析和讲解的,但在实际项目的工程落地实践中,IM 系统的监控和保障也是极其重要的一环。只有通过对消息收发链路的监控,我们才能够实时地了解到链路是否可用,后端服务是否足够健康;如果监控体系不够完善,我们的业务即使上线了,也是处于“蒙眼狂奔”的状态。所以,我们要在工程上线时有一个“”的意识和原则。今天,我们就一起来聊一聊,消息收发链路中监控体系搭建的问题。原创 2024-02-29 15:18:49 · 1048 阅读 · 0 评论 -
18 | Docker容器化:说一说IM系统中模块水平扩展的实现
在第 10 讲“自动智能扩缩容:直播互动场景中峰值流量的应对”中,较为系统地讲解了直播场景中突发流量的应对策略。其中比较重要的一点就是:当有热点流量进来时,我们能够通过监控指标对服务进行快速扩缩容。而快速扩缩容的一个重要前提,就是部署的服务和资源能够做到水平扩展。那么,今天我们就来聊一聊服务和资源水平扩展的实现问题。原创 2024-02-29 14:30:59 · 730 阅读 · 0 评论 -
17 | Cache:多级缓存架构在消息系统中的应用
作为低成本的解决方案,我们在 L1+ 主从模式的基础上,引入了本地缓存。本地缓存依托应用服务器的本机少量内存,既提升了资源的有效利用,也彻底解决了带宽的问题。同时在性能方面,也比远程缓存获取更加优秀。对于本地缓存的数据一致性问题,我们可以通过“短过期时间”来平衡缓存命中率和数据一致性。面对高并发业务带来的流量压力,我们不可否认的是,缓存的使用是目前为止最有效的提升系统整体性能的手段。作为系统优化的一把利器,如何用好这个强大的工具,是你需要去不断思考和学习的。原创 2024-02-29 11:54:42 · 983 阅读 · 0 评论 -
16 | APNs:聊一聊第三方系统级消息通道的事
DeviceToken 是 APNs 用于区分识别不同 iOS 设备同一个 App 的唯一标识,APNs 的网关和设备通信时,通过系统默认自带的长连接进行连接,并通过 DeviceToken 作为当前连接设备的唯一标识进行系统消息的推送。要通过 APNs 实现系统推送,我们的推送服务(Provider)需要先和 APNs 建立长连,建连时携带的证书包含“准备接收”系统消息推送的 App 的 Bundle Identifier(Bundle Identifier 是一款 App 的唯一标识)。原创 2024-02-29 11:12:16 · 1042 阅读 · 0 评论 -
15 | CDN加速:如何让你的图片、视频、语音消息浏览播放不卡?
上一讲,从即时消息场景中多媒体消息的上传环节出发,介绍了业界常用的几种提升用户上传体验的优化手段。那么这节,会从播放的角度出发,带你了解在浏览和播放图片、视频、语音等多媒体消息时,如何避免灰图和卡顿的问题,以及在节省流量方面,业界都有哪些比较常见的优化策略。原创 2024-02-29 10:23:53 · 1125 阅读 · 0 评论 -
14 | 分片上传:如何让你的图片、音视频消息发送得更快?
在前面几节课中,基本上都是从通用文本消息的角度出发,较为深入地分析讲解了即时消息相关的一些重要特性及核心概念。随着网络环境的大幅改善及网络资费的显著降低,在很多即时消息场景下,人们的互动不再局限于传统的文本消息,越来越多的用户通过图片、语音、视频等丰富的多媒体消息来完成互动。相较于文本消息而言,多媒体消息在易用性和情感表达上更有优势。但是,多媒体消息相对也会大很多。比如,一条文本消息只有不到 100 字节,但一条视频消息可能超过 100MB。因此,多媒体消息在网络传输、实时触达等方面相对更难一些。原创 2024-02-29 09:16:23 · 1047 阅读 · 0 评论 -
13 | HTTP Tunnel:复杂网络下消息通道高可用设计的思考
在第 1 讲“架构与特性:一个完整的 IM 系统是怎样的?”中,有讲到即时消息系统中非常重要的几个特性:实时性、可靠性、一致性、安全性。实际上,这些特性的实现大部分依赖于通道层的稳定和高可用。对于即时消息系统来说,消息的通道主要承载两部分流量:一部分是用户发出的消息或者触发的行为,我们称为;一部分是服务端主动下推的消息和信令,我们称为。由此可见,消息通道如果不稳定,一来会影响用户发送消息的成功率和体验,二来也会影响消息的下推,导致用户没法实时收到消息。原创 2024-02-28 22:29:42 · 1013 阅读 · 1 评论 -
12 | 服务高可用:保证核心链路稳定性的流控和熔断机制
在第 10 讲“自动智能扩缩容:直播互动场景中峰值流量的应对”中,分析了直播互动场景中“突发流量”和“高并发峰值”业务形态下的几个关键技术点,并介绍了具体的应对方式。但是,仅从设计优化、服务拆分、自动扩容等方面进行优化,有时候并不能完全解决问题。比如,有时流量增长过快,扩容流程还来不及完成,服务器可能就已经抗不住了。不仅如此,在即时消息系统的很多实现中,业务上对于外部接口或者资源的依赖比较多。比如:发消息可能需要依赖“垃圾内容识别”的 API 来进行消息内容的过滤;原创 2024-02-28 20:51:43 · 945 阅读 · 0 评论 -
11 | 期中实战:动手写一个简易版的IM系统
在“03 | 轮询与长连接:如何解决消息的实时到达问题?”一讲中,讲到了保证消息实时性的三种常见方式:短轮询、长轮询、长连接。对于消息和未读的自动更新的设计,你可以采用其中任意一种,我实现的简版代码里就是采用的“短轮询”来在联系人页面和聊天页面轮询未读和新消息的。实现上比较简单,Web 端核心代码和服务端核心代码如下。原创 2024-02-28 18:09:07 · 829 阅读 · 0 评论 -
10 | 自动智能扩缩容:直播互动场景中峰值流量的应对
随着近几年各种直播 App 和百万答题 App 的火爆和风靡,具有高实时性要求的直播互动场景开始纷纷借助即时消息技术,来保证直播过程中的各种互动消息和行为能够及时、可靠地投递,比如用户给主播打赏或者送礼的互动行为,不能有超过 10 秒的延迟,更不能丢失,否则会导致主播和房间其他用户看不到。即时消息技术凭借其在实时性和可靠性方面的优势,已经被广泛应用在互动直播场景中。那么,和传统的消息聊天场景相比,直播互动在业务形态上究竟有哪些区别?在技术层面又有哪些高难度的挑战?原创 2024-02-28 17:20:01 · 905 阅读 · 0 评论 -
09 | 分布式一致性:让你的消息支持多终端漫游
今天我们开始进入场景篇的部分,在这个部分中,会介绍在几种典型的垂直业务场景下,IM 系统具体是如何实现的。在即时消息的场景里,消息的多终端漫游是一个相对比较高级的功能,所谓的这个功能对于有多个手机的用户来说是一个非常有用的功能,试想一下用户在交叉使用多个手机进行聊天后,如果不能在多个终端间自动同步所有的聊天记录,使用体验也不会太好。但并不是所有的即时消息 App 都支持这个特性,比如微信虽然支持多端登录,但不知道出于什么考虑并不能在多端同步历史消息,这可能也是微信为数不多被诟病的一个小问题吧。原创 2024-02-28 16:36:23 · 928 阅读 · 0 评论 -
08 | 智能心跳机制:解决网络的不确定性
在前面的章节里,讲到了在即时消息场景中非常重要的两个特性:“可靠投递”和“实时性”。为了让消息能更加实时、可靠、快速地触达到接收方,大部分 IM 系统会通过“长连接”的方式来建立收发双方的通信通道,这些基于 TCP 长连接的通信协议,在用户上线连接时,会在服务端维护好连接到服务器的用户设备和具体 TCP 连接的映射关系,通过这种方式服务端也能通过这个映射关系随时找到对应在线的用户的客户端,而且这个长连接一旦建立,就一直存在,除非网络被中断。原创 2024-02-28 15:38:39 · 925 阅读 · 0 评论 -
07 | 分布式锁和原子性:你看到的未读消息提醒是真的吗?
在前面几节中,着重把即时消息场景中几个核心的特性,进行了较为详细的讲解。在实际用户场景下,除了实时性、可靠性、一致性、安全性这些刚需外,还有很多功能对用户体验的影响也是很大的,比如今天我要讲的“消息未读数”。消息未读数对用户使用体验影响很大,这是因为“未读数”是一种强提醒方式,它通过 App 角标,或者 App 内部 Tab 的数字标签,来告诉用户收到了新的消息。对于在多个社交 App 来回切换的重度用户来说,基本上都是靠“未读数”来获取新消息事件,如果“未读数”不准确,会对用户造成不必要的困扰。原创 2024-02-28 14:35:19 · 713 阅读 · 0 评论 -
06 | HttpDNS和TLS:你的消息聊天真的安全吗?
在开始之前,我们先回顾一下前面几篇的内容。我们陆续讲到了消息实时性、消息投递的可靠性、消息时序一致性在即时系统业务场景中的重要性和难点,以及相应的实现方案。如果说消息的“实时性”“投递可靠性”“时序一致性”是评价一个即时消息服务可用性和先进性的重要指标;那么另一个重要的特性:安全性,就是一个 IM 服务能否存在的底线和立命之本。对于依托即时消息技术之上的各种私密聊天 App、轨迹位置服务、远程工控系统等业务,对于安全性的需要远高于一般业务。原创 2024-02-28 11:07:13 · 1055 阅读 · 0 评论 -
05 | 消息序号生成器:如何保证你的消息不会乱序?
比如说如果有一个全局递增的序号生成器,应该就能避免多服务器时钟不同步的问题了,IM 服务端就能通过这个序号生成器发出的序号,来作为消息排序的“时序基准”。而且这种“全局序号生成器”可以通过多种方式来实现,常见的比如 Redis 的原子自增命令 incr,DB 自带的自增 id,或者类似 Twitter 的 snowflake 算法、“时间相关”的分布式序号生成服务等。原创 2024-02-28 09:04:47 · 825 阅读 · 0 评论 -
04 | ACK机制:如何保证消息的可靠投递?
在第一节中,我们说到了即时消息系统中的四个重要特性,实时性、可靠性、一致性、安全性。上一节我们从如何保证消息实时性方面,了解了业界常用的一些方式以及背后具体的原理。那么今天我们接着来讲一讲,在即时消息的系统架构设计里,如何来保证消息的可靠投递。首先,我们来了解一下,什么是消息的可靠投递?站在使用者的角度来看,消息的可靠投递主要是指:消息在发送接收过程中,能够做到不丢消息、消息不重复两点。这两个特性对于用户来讲都是非常影响体验的。我们先说一下不丢消息。原创 2024-02-27 22:38:44 · 1334 阅读 · 0 评论 -
03 | 轮询与长连接:如何解决消息的实时到达问题?
在前面第一篇文章中,从使用场景的需求方面,讲到了 IM 系统的几个比较重要的特性。其中之一就是“消息到达的实时性”。实时性场景是所有的 IM 系统绕不开的话题,为了支持互联网的“实时互联”的概念,大部分的 App 都需要实时技术的支持。我们现在使用的聊天类 App、直播互动类 App 都已经在实时性方面做得很好了,消息收发延迟基本都能控制在毫秒级别。当然这一方面得益于快速发展的移动网络,让网络延迟越来越低、网络带宽越来越高;另一个重要原因是:社交网络 App 在实时性提升方面的技术,也在不断升级迭代。原创 2024-02-27 21:48:50 · 1144 阅读 · 0 评论 -
02 | 消息收发架构:为你的App,加上实时通信功能
前一篇文章中,我们从使用者的直观角度和从业者的实现维度,了解一个 IM 系统都应该具备哪些要素。但实际上,从我的角度来看,我更倾向于把“IM”看作是一门可以融入到各种业务系统中,为业务系统提供“实时交互”能力的技术模块。比如,极客时间想在它的 App 中增加一个互动模块,支持用户点对点的实时聊天功能。那么,我们就可以相应地通过一些 IM SDK 的方式,快速地把即时消息的技术引入到已有的业务系统中。原创 2024-02-27 21:00:17 · 972 阅读 · 0 评论 -
01 | 架构与特性:一个完整的IM系统是怎样的?
由于手机操作系统的限制,以及资源优化的考虑,大部分 App 在进程关闭,或者长时间后台运行时,App 和 IM 服务端的连接会被手机操作系统断开。这样当有新的消息产生时,就没法通过 IM 服务再触达用户,因而会影响用户体验。为了让用户在 App 未打开时,或者在后台运行时,也能接收到新消息,我们会将消息给到。原创 2024-02-27 20:39:33 · 1182 阅读 · 0 评论 -
开篇词 | 搞懂“实时交互”的IM技术,将会有什么新机遇?
我们不妨先看一段旧闻:2014 年 Facebook 以 190 亿美元的价格,收购了当时火爆的即时通信工具 WhatsApp,而此时 WhatsApp 仅有 50 名员工。是的,也就是说这 50 名员工人均创造了 3.8 亿美元的价值。这里,我们不去讨论当时谷歌和 Facebook 为争抢 WhatsApp 发起的价格战,从而推动这笔交易水涨船高的合理性,从另一个侧面我们看到的是:依托于 IM 技术的社交软件,在完成了“连接人与人”的使命后,体现出的巨大价值。同样的价值体现也发生在国内。原创 2024-02-27 17:54:50 · 863 阅读 · 0 评论