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

JackJiang · 4 年前

本文引用了唐小智发表于InfoQ公众号上的“钉钉企业级IM存储架构创新之道”一文的部分内容，即时通讯网收录时有改动，感谢原作者的无私分享。

1、引言

业界的 IM 产品在功能上同质化较高，而企业级的 IM 产品对于高可用、安全性又有更高的要求，如何打造具备差异化的产品，又在高可用、安全性、数据一致性等方面具备较高的品质，是企业级 IM 产品成功的关键。钉钉在过去短短几年时间里，用户数已破 2 亿，企业组织数破千万，钉钉是在规划企业级 IM 产品的架构上有何过人之处？本文将围绕这个话题进行展开。

阿里IM技术分享(一)：企业级IM王者——钉钉在后端架构上的过人之处_timg-(3)-opti.jpg

阿里IM技术分享(一)：企业级IM王者——钉钉在后端架构上的过人之处_timg-(3)-opti.jpg

阅读提示：本文适合有一定IM后端架构设计经验的开发者阅读，或许出于商业产品技术秘密的考虑，分享者在本次所分享的内容上有所保留，鉴于阿里对于钉钉在技术上的内容分享做的非常少，所以本文虽然内容不够全面，但仍然值得一读。

相关文章：

2、系列文章

本文是系列文章的第1篇，总目录如下：

相关文章：

《现代IM系统中聊天消息的同步和存储方案探讨》
《钉钉——基于IM技术的新一代企业OA平台的技术挑战(视频+PPT) [附件下载]》（* 推荐）

3、不同的场景，钉钉的架构思路不同

钉钉的技术栈继承自阿里巴巴集团。阿里有着”大中台，小前台“的组织战略，所以钉钉在大的框架上是复用集团的能力，包括集团的中间件、存储引擎、微服务框架等。在此之上，钉钉聚焦在核心能力的研发，比如：IM 核心系统、系统单元化、音视频通讯，弱网优化，图片收发极致体验等等。

钉钉作为 ToB 产品，业务场景跟 ToC 的 IM 产品有很大区别，架构上也各有侧重。

3.1万人大群的架构设计思路

阿里IM技术分享(一)：企业级IM王者——钉钉在后端架构上的过人之处_11.jpg

（本图引用自：《钉钉——基于IM技术的新一代企业OA平台的技术挑战(视频+PPT)》）

在钉钉里，企业的组织关系映射到 IM 的群，产生了为数众多的超级大群。和 500 群人数上限相比，钉钉支持万人大群，大幅提升了群的触达人数。

如此数目繁多的万人群给 IM 系统的流量冲击巨大。在节假日，特别是元旦、春节或者双 11 这样的重大活动时期，管理层和员工在大群高频互动，流量洪峰瞬间流过 IM 系统，挑战着系统的极限。

为支撑好超级大群，我们做了以下多点的优化。

3.1.1）降低存储扩散量：

最早 IM 使用写扩散模型，一万人的群发一条消息写一万次消息收件箱。优化为读扩散模型后，一条消息只需写一次消息收件箱，扩散量降低到万分之一。

3.1.2）智能限流：

在节日场景下，一些大群的消息发送频率过高，可能超过系统整体容量，影响 IM 系统稳定性。如果对每个群设置较低的发送阈值，系统又没有完全发挥出容量，从而提供足够流畅的用户体验。针对这个问题，我们设计了一种智能限流的方法，当总体流量超过系统阈值时，自动根据当时情况对消息发送频率相对较高的大群进行限流。

3.1.3）万人群成员多级缓存：

我们在客户端、服务端建立了群成员的多级缓存。

一方面增强了用户打开 at 列表、查看群成员列表的体验。因为群成员人数增大时，打开群成员列表的延迟提升明显，用户能感受到长达数十秒的卡顿。增加客户端缓存后，用户输入 @立刻响应成员列表，即使群里有几万个群成员。另一方面避免了大量群成员读写对 DB 的压力。如果压力直接打到 DB 层，万行记录的扩散量过大，很容易造成热点，影响系统稳定性。

3.1.4）端到端的体验保证：

客户端定期做极限压测，在群消息大规模刷屏的情况，保证用户体验流畅不卡顿。

万人群聊相关文章推荐阅读：

更多有关群聊的架构设计文章：

3.2历史消息的架构设计思路

钉钉中的历史消息是可回溯的。在 ToB 场景下，数据属于企业的资产。企业有需求查看历史消息，因为它是关键的沟通信息。

3.2.1）首先是既省流量，又不遗漏的历史消息回溯协议：最近的消息通过同步协议推送到达客户端本地。而历史的消息，服务端不曾推送，客户端本地没有入库。在用户进入会话时，如果客户端发现本地消息不足，自动从服务端拉取不足的历史消息。采用这种推拉结合的协议，保证了消息不管多么久远，都可以毫无遗漏的从服务端同步下来。

3.2.2）然后是低成本的历史消息存储架构：消息具有典型的冷热属性: 用户访问的绝大部分都是最近的数据。我们自研了一套冷热分离架构，在冷库使用低成本高压缩率的存储引擎，大幅下降存储成本。

3.2.3）最后是达到金融级安全保障的历史消息加密：为了保证历史消息的安全性，我们在全链路使用金融级的加密算法，不留死角，确保没有任何人可以非法获取历史消息。

3.3场景化

ToC IM 产品的场景都比较通用。比如微信群，每个人能够使用的功能集合是一样的，大家进群聊天，都可以改群昵称，群名称。

钉钉则是面向场景打造极致体验。以班级群为例，班级群里面没有用户的概念，变成了老师、家长、学生。进群后家长无法修改群昵称，完全由系统设置，比如"小明爸爸"。所以，班级群的进群路径、群管理、昵称展示，都是面向家校沟通场景的特殊优化，目的是做到家校场景的极致用户体验。

这给技术团队带来两方面的挑战。一方面是系统模型必须做到可扩展性强，足够灵活，能够快速地支持业务场景化的需求；另一方面是在维持业务快速迭代的情况下，保持核心 IM 系统的高可用性。因此钉钉的架构必须做到同时满足这两点需求。

还是以班级群为例。它使用小程序开发，不需要发版就可以做 bugfix、实现业务需求。同时服务端切分为了业务层和 IMCore 层。业务层做灵活多变的业务逻辑，迭代速度快。IMCore 层提供基础能力和扩展点，改动频次低，主要是提供高稳定性和单元化能力。服务分层后，基本做到了新需求不改动 IMCore 层。迭代速度快，系统稳定性强，达到了业务、技术皆大欢喜的局面。

3.4单元化

单元化在钉钉有多层需求。

3.4.1）高可用：钉钉要保证 vip 用户在地域灾难的情况下可用。因此我们设计了一套基于单元化的异地容灾方案。当中心宕机，两分钟内一键把 vip 用户调度到容灾单元，确保用户能够正常使用 IM 基本功能。

3.4.2）国际化：海外地区的对于数据有合规的要求。同时，钉钉在当地部署应用，也给海外用户提供了更流畅的用户体验。

3.4.3）支持大客户及特殊行业：钉钉今天不仅承接中小企业的沟通办公，也承接不少政务大客户。他们对钉钉的诉求是具备专有云部署能力。

3.4.4）容量：随着业务发展，所有流量在中心处理不可扩展。把流量分散到多地域是一个必然选择。

钉钉通过一套代码部署，一套运维体系实现单元化，满足了以上多层次的需求。我们开发了单元化基础组件，动态路由，业务层数据同步组件等一系列基础设施，可以将钉钉部署在任何一个国家或地区，甚至客户的自有机房。

4、钉钉的高可用、安全性如何保证

阿里IM技术分享(一)：企业级IM王者——钉钉在后端架构上的过人之处_22.jpg

企业级 IM 产品对于高可用和安全性的要求远高于 ToC 场景下的 IM 产品。一旦钉钉的消息发不出去或者收消息出现延迟，就会大面积影响企业的核心业务运转。同时，聊天数据长期保存，历史消息可实时回溯，一方面对数据存储提出了更高要求，另一方面也对数据的安全性带来了新的挑战。

钉钉在高可用性方面的努力，主要包括以下几个方面：

1）高可用架构：通过异地容灾、中间件冗余、存储冗余，在架构上避免单个中间件、存储或者地域的灾难对系统可用性产生影响。比如今天 IM 依赖的 DB 宕机，并不会影响用户的消息收发成功率；
2）变更管理：核心系统控制发布频率，每一次发布必须 checklist 校验。发布可灰度、可监控、可回滚，控制问题引入的影响面；
3）持续精进：通常大的故障都是由小的隐患累计产生。如何发现并解决系统中的隐患？得有机制性的解决方案。我们每天投入专人，去发现系统中的稳定性问题。常年累计下来，系统的健康度越来越高。

作为企业级应用，安全是钉钉的立身之本，也是企业客户最敏感的关注点。

钉钉在数据安全方面的努力，主要包括以下几个方面：

1）钉钉 IM 拥有高强度的链路加密，达到银行级数据加密级别：IM 在全链路上都是加密的，因为即使有一个点疏漏，数据就可能泄漏。所以在客户端、长连接、mq、存储、业务上下游，都做了加密。在接口访问层面，我们也有完善的鉴权、访问控制，确保数据不会被非法使用。
2）数据安全上，企业还可以选择第三方加密：聊天数据同时被钉钉、三方双重加密，数据只属于企业。
3）长期的安全技术沉淀：钉钉背后有阿里集团数千名工程师建立的安全保障机制。我们每一次发布都会有代码安全扫描，一般的水平权限漏洞都可以在扫描中发现，用工具把大部分漏洞扼杀在上线前。同时自主研发了动态防入侵系统，实时监测平台的安全状况，对于入侵事件具备分钟级快速发现能力及进行事件的快速响应、止血与溯源能力。
4）攻防演练：平时多演练，战时不流血。我们有专门的安全团队对系统进行攻防演练，红蓝对抗，及时发现潜在的安全问题，提升入侵检测及安全应急响应能力。

PS：以上有自high的成分存在，各位选择性阅读即可。

5、钉钉在存储等方面的创新

不同于传统 IM，钉钉在存储方面的业务需求与技术实现都有新的要求。

由于消息需要长期保存，钉钉做存储的一个重点必然是降低长期数据的存储成本。钉钉在其中做了很多事情，比如冷热分离，读写扩散，消息清理。没有成本上的优化，业务的增长带来的是不可持续的成本增长，这是无法接受的。

另一点是存储的单元化。一般 ToC 产品的单元化主要是由国际化驱动。海外市场有合规的要求，消息必须存储在当地。对于钉钉来说，除了国际化的需求，也有组织专有部署的需求，因此钉钉的存储架构上也支持单元化部署，以及多单元的互通。

除了业务场景变化给技术带来的新要求，技术同学也会有一些 geek 的想法，从而反哺业务。比如钉钉的聊天机器人，就是 IM 技术同学自发发起的。最初，很难说清楚聊天机器人对业务的贡献，因此技术同学就自己偷偷把 MVP 做出来。做出来以后，慢慢发现确实在工作中很有价值，包括 IM 的系统报警、用户 VOC 问题解决率提醒，命令行重启单台机器等等场景，用聊天机器人非常方便，很好的提高了工作效率。所以最终决定开放给用户，也受到了用户的广泛好评。

PS：本节内容有点水，各位选择阅读性即可。

以下有关IM存储设计方面的文章也值得一读：

附录：更多即时通讯大厂的技术分享

[1] 来自阿里巴巴的技术文章：
《阿里钉钉技术分享：企业级IM之王——钉钉在后端架构上的过人之处》
《现代IM系统中聊天消息的同步和存储方案探讨》
《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》
《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》
《来自阿里OpenIM：打造安全可靠即时通讯服务的技术实践分享》
《钉钉——基于IM技术的新一代企业OA平台的技术挑战(视频+PPT) [附件下载]》
《阿里技术结晶：《阿里巴巴Java开发手册(规约)-华山版》[附件下载]》
《重磅发布：《阿里巴巴Android开发手册(规约)》[附件下载]》
《作者谈《阿里巴巴Java开发手册(规约)》背后的故事》
《《阿里巴巴Android开发手册(规约)》背后的故事》
《干了这碗鸡汤：从理发店小弟到阿里P10技术大牛》
《揭秘阿里、腾讯、华为、百度的职级和薪酬体系》

[2] QQ、微信团队原创技术文章：
《微信朋友圈千亿访问量背后的技术挑战和实践总结》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)》
《微信团队分享：微信移动端的全文检索多音字问题解决方案》
《腾讯技术分享：Android版手机QQ的缓存监控与优化实践》
《微信团队分享：iOS版微信的高性能通用key-value组件技术实践》
《微信团队分享：iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的？》
《腾讯技术分享：Android手Q的线程死锁监控系统技术实践》
《微信团队原创分享：iOS版微信的内存监控系统技术实践》
《让互联网更快：新一代QUIC协议在腾讯的技术实践分享》
《iOS后台唤醒实战：微信收款到账语音提醒技术总结》
《腾讯技术分享：社交网络图片的带宽压缩技术演进之路》
《微信团队分享：视频图像的超分辨率技术原理和应用场景》
《微信团队分享：微信每日亿次实时音视频聊天背后的技术解密》
《QQ音乐团队分享：Android中的图片压缩技术详解（上篇）》
《QQ音乐团队分享：Android中的图片压缩技术详解（下篇）》
《腾讯团队分享：手机QQ中的人脸识别酷炫动画效果实现详解》
《腾讯团队分享：一次手Q聊天界面中图片显示bug的追踪过程分享》
《微信团队分享：微信Android版小视频编码填过的那些坑》
《微信手机端的本地数据全文检索优化之路》
《企业微信客户端中组织架构数据的同步更新方案优化实战》
《微信团队披露：微信界面卡死超级bug“15。。。。”的来龙去脉》
《QQ 18年：解密8亿月活的QQ后台服务接口隔离技术》
《月活8.89亿的超级IM微信是如何进行Android端兼容测试的》
《以手机QQ为例探讨移动端IM中的“轻应用”》
《一篇文章get微信开源移动端数据库组件WCDB的一切！》
《微信客户端团队负责人技术访谈：如何着手客户端性能监控和优化》
《微信后台基于时间序的海量数据冷热分级架构设计实践》
《微信团队原创分享：Android版微信的臃肿之困与模块化实践之路》
《微信后台团队：微信后台异步消息队列的优化升级实践分享》
《微信团队原创分享：微信客户端SQLite数据库损坏修复实践》
《腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（下篇）》
《腾讯原创分享(三)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
《微信Mars：微信内部正在使用的网络层封装库，即将开源》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《开源libco库：单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》
《微信团队原创分享：Android版微信从300KB到30MB的技术演进》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
《微信异步化改造实践：8亿月活、单机千万连接背后的后台解决方案》
《微信朋友圈海量技术之道PPT [附件下载]》
《微信对网络影响的技术试验及分析（论文全文）》
《一份微信后台技术架构的总结性笔记》
《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《快速裂变：见证微信强大后台架构从0到1的演进历程（二）》
《微信团队原创分享：Android内存泄漏监控和优化技巧总结》
《全面总结iOS版微信升级iOS9遇到的各种“坑”》
《微信团队原创资源混淆工具：让你的APK立减1M》
《微信团队原创Android资源混淆工具：AndResGuard [有源码]》
《Android版微信安装包“减肥”实战记录》
《iOS版微信安装包“减肥”实战记录》
《移动端IM实践：iOS版微信界面卡顿监测方案》
《微信“红包照片”背后的技术难题》
《移动端IM实践：iOS版微信小视频功能技术方案实录》
《移动端IM实践：Android版微信如何大幅提升交互性能（一）》
《移动端IM实践：Android版微信如何大幅提升交互性能（二）》
《移动端IM实践：实现Android版微信的智能心跳机制》
《移动端IM实践：WhatsApp、Line、微信的心跳呗苑治�》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《移动端IM实践：iOS版微信的多设备字体适配方案探讨》
《信鸽团队原创：一起走过 iOS10 上消息推送(APNS)的坑》
《腾讯信鸽技术分享：百亿级实时消息推送的实战经验》
《IPv6技术详解：基本概念、应用现状、技术实践（上篇）》
《IPv6技术详解：基本概念、应用现状、技术实践（下篇）》
《腾讯TEG团队原创：基于MySQL的分布式数据库TDSQL十年锻造经验分享》
《微信多媒体团队访谈：音视频开发的学习、微信的音视频技术和挑战等》
《了解iOS消息推送一文就够：史上最全iOS Push技术详解》
《腾讯技术分享：微信小程序音视频技术背后的故事》
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《微信多媒体团队梁俊斌访谈：聊一聊我所了解的音视频技术》
《腾讯音视频实验室：使用AI黑科技实现超低码率的高清实时视频聊天》
《腾讯技术分享：微信小程序音视频与WebRTC互通的技术思路和实践》
《手把手教你读取Android版微信和手Q的聊天记录(仅作技术研究学习)》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《腾讯技术分享：GIF动图技术详解及手机QQ动态表情压缩技术实践》
《微信团队分享：Kotlin渐被认可，Android版微信的技术尝鲜之旅》
《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》
《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》
《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》
《社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》
《社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》
《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》
《社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等》
《QQ设计团队分享：新版 QQ 8.0 语音消息改版背后的功能设计思路》
>> 更多同类文章 ……

[3] 有关QQ、微信的技术故事：
《技术往事：微信估值已超5千亿，雷军曾有机会收编张小龙及其Foxmail》
《QQ和微信凶猛成长的背后：腾讯网络基础架构的这些年》
《闲话即时通讯：腾讯的成长史本质就是一部QQ成长史》
《2017微信数据报告：日活跃用户达9亿、日发消息380亿条》
《腾讯开发微信花了多少钱？技术难度真这么大？难在哪？》
《技术往事：创业初期的腾讯——16年前的冬天，谁动了马化腾的代码》
《技术往事：史上最全QQ图标变迁过程，追寻IM巨人的演进历史》
《技术往事：“QQ群”和“微信红包”是怎么来的？》
《开发往事：深度讲述2010到2015，微信一路风雨的背后》
《开发往事：微信千年不变的那张闪屏图片的由来》
《开发往事：记录微信3.0版背后的故事（距微信1.0发布9个月时）》
《一个微信实习生自述：我眼中的微信开发团队》
《首次揭秘：QQ实时视频聊天背后的衩刈橹�》
《为什么说即时通讯社交APP创业就是一个坑？》
《微信七年回顾：历经多少质疑和差评，才配拥有今天的强大》
《前创始团队成员分享：盘点微信的前世今生——微信成功的必然和偶然》
《即时通讯创业必读：解密微信的产品定位、创新思维、设计法则等》
《QQ的成功，远没有你想象的那么顺利和轻松》
《QQ现状深度剖析：你还认为QQ已经被微信打败了吗？》
《[技术脑洞] 如果把14亿中国人拉到一个微信群里技术上能实现吗？》
《QQ和微信止步不前，意味着即时通讯社交应用创业的第2春已来？》
《那些年微信开发过的鸡肋功能，及其带给我们的思考》
《读懂微信：从1.0到7.0版本，一个主流IM社交工具的进化史》
《同为IM社交产品中的王者，QQ与微信到底有什么区别》
《还原真实的腾讯：从最不被看好，到即时通讯巨头的草根创业史》
《QQ设计团队分享：新版 QQ 8.0 语音消息改版背后的功能设计思路》
《社交应用教父级人物的张小龙和马化腾的同与不同》
《专访马化腾：首次开谈个人经历、管理心得、技术创新、微信的诞生等》
《一文读懂微信之父张小龙：失败天才、颠覆者、独裁者、人性操控师》
>> 更多同类文章 ……

2 楼: Shahala · 4 年前

看到钉钉就恶心
除了讨好老板
谁想用它

3 楼: inrg · 4 年前

有广告嫌疑，我建议是开源吧，还可以成为企业im的标杆，卖卖服务器插件服务什么的，斗不过微信的，虽然很烂，先入为主

4 楼: JackJiang · 4 年前

引用：inrg 发表于 2019-12-09 11:03
有广告嫌疑，我建议是开源吧，还可以成为企业im的标杆，卖卖服务器插件服务什么的，斗不过微信的，虽然 ...

是有吹水的嫌疑，但我没收钉钉的好处费，只是看到文章里有些地方，稍有些养分，对自已有用吸收它就好了，管它怎么吹

5 楼: 妮子 · 4 年前

确实学到了一些点，智能限流，推拉结合，冷热数据分离，不过干货太少了

6 楼: JackJiang · 4 年前

引用：妮子发表于 2019-12-12 18:07
确实学到了一些点，智能限流，推拉结合，冷热数据分离，不过干货太少了

钉钉很少分享技术，有的看就不错了

7 楼: Sudo · 4 年前

万人群读扩散, 读的压力也很大啊.

8 楼: Sudo · 4 年前

楼主, 读扩散对于哪些会话有新消息这个我不太懂==, 这个要优化的话应该是要记录下用户有消息的会话吧. 不然每次查所有会话再去查会话是否有新消息这个也不太现实.. 这样优化是不是又退化成了timeline模式了..

9 楼: JackJiang · 4 年前

引用：Sudo 发表于 2020-04-19 23:06
楼主, 读扩散对于哪些会话有新消息这个我不太懂==, 这个要优化的话应该是要记录下用户有消息的会话吧. 不然 ...

新消息这种，用写扩散是比较合理的。

10 楼: Sudo · 4 年前

引用：JackJiang 发表于 2020-04-19 23:10
新消息这种，用写扩散是比较合理的。

看了站里的钉钉的文章,他们是从写扩散优化成了读扩散了.

请问楼主有钉钉怎么给客户端提示哪些会话有新消息的相关资料么?

11 楼: JackJiang · 4 年前

引用：Sudo 发表于 2020-04-19 23:53
看了站里的钉钉的文章,他们是从写扩散优化成了读扩散了.

请问楼主有钉钉怎么给客户端提示哪些会话有新 ...

没有。

12 楼: Sudo · 4 年前

引用：JackJiang 发表于 2020-04-20 10:05
没有。

哈哈,目前想到的方案就是离线状态下缓存有新消息的会话id..

13 楼: Monkey · 3 年前

干货有些少

14 楼: JackJiang · 3 年前

引用：Monkey 发表于 2020-07-28 20:55
干货有些少

钉钉几乎不做技术分享，这样的分享对于钉钉来说已经很少见了

15 楼: 手写的从前 · 3 年前

《最近的消息通过同步协议推送到达客户端本地。而历史的消息，服务端不曾推送，客户端本地没有入库。在用户进入会话时，如果客户端发现本地消息不足，自动从服务端拉取不足的历史消息。采用这种推拉结合的协议，保证了消息不管多么久远，都可以毫无遗漏的从服务端同步下来。》，这里的《如果客户端发现本地消息不足》客户端是怎么发现本地消息不足的啊

16 楼: JackJiang · 3 年前

引用：手写的从前发表于 2021-02-05 10:10
《最近的消息通过同步协议推送到达客户端本地。而历史的消息，服务端不曾推送，客户端本地没有入库。在用户 ...

哈哈哈，关键地方总是一笔带过。。。
你要知道，大厂里的大牛通常都不是全栈，写这种文章的一般是后端，所以，前端到底怎么实现的，他应该是不太清楚的，哈哈

17 楼: Lance_QHT5Z · 3 年前

学习了

18 楼: 深海 · 2 年前

引用：手写的从前发表于 2021-02-05 10:10
《最近的消息通过同步协议推送到达客户端本地。而历史的消息，服务端不曾推送，客户端本地没有入库。在用户 ...

应该是进入一个会话发现不足以展现首屏数据就从服务端拉取

19 楼: 深海 · 2 年前

自high较多，就聊天机器人功能，给它发送打卡，它回复好的马上去打卡，简直是个沙雕设计，Apple store评分2.4，从哪里得出受到了用户广泛好评的结论

20 楼: 椎锋陷陈 · 2 年前

「万人群成员多级缓存」那里我们的App也采用了类似的实现，当时考虑的是，大量群成员频繁的@操作去调用群组接口获取数据,
一方面会增加服务端的请求压力，另一方面输入@后弹出群成员列表的动作也会因网络操作延迟，因此在客户端也实现了一层缓存，
记录了群组资料的数据。

但是增加客户端缓存又可能造成群成员列表更新不及时的问题，因此我们还增加了一个「最后更新时间」的记录值，
这个值会在每次有群成员列表更新的动作(如打开App时同步群组、查看群资料、群组更新主动通知)时更新。

当触发@操作时，会去检查这个最后更新时间是否超过限定值，如果超过就需要调用群组接口获取数据并更新本地缓存，
如果未超过就直接使用本地缓存，通过这样平衡服务端请求压力与数据更新不及时的问题。

本文目录

1、引言

2、系列文章