🔥 深度揭秘钉钉即时消息服务DTIM的技术设计原创

阿里I'M技术分享系列文章的第8篇，深度揭秘钉钉即时消息服务DTI'M的技术事迹本文是国内企业I'M的事时王者钉钉首次对外深度解密其及时消息服务及丁臭IM简称DTI'M的技术设计事件。本篇文章内容将从模型设计原理到具体的技术架构、最底层的存储模型到跨地域的单元化等，全方位展现了DTIM在实际生产应用中所遇到的各种技术挑战及相应的解决方案。希望借本文内容的分享，能为国内企业及I'M的开发带来思考和启发。一、钉钉的技术挑战构建稳定高效的企业应用服务。DTI'M主要面临的挑战主要是三个方面，1、企业I'M极致的体验要求，对于系统架构设计的挑战，2、极限场景冲击，依赖系统错误带来的可用性问题。3、不断扩大的业务规模对于系统。

部署架构的挑战二、DTIMIM系统架构低延迟、高触达、高可用一直是DTIMI设计的第一原则。依据这个原则，在架构上，DTIM将系统拆分为三个服务做能力的承载。三个服务分别是消息服务、同步服务、通知服务、同步服务和通知服务。除了服务与消息服务，也面向其他钉钉业务，比如音视频、直播、定文档等多端多设备数据同步。三、消息收发链路一、消息发送消息发送接口由瑞receiver提供钉钉统一接入层，将用户从客户端发送的消息请求转发到receiver模块，Receiver校验消息的合法性以及成员关系的有效性，校验通过后为该消息生成一个全局唯一的message ID随消息体以及接收者列表打包成消息数据包，投递给一部队列，由下游processor处理。消息投递成功之。

之后receive返回消息，发送成功的回执给客户端。2、消息处理processor消费到I'M发送事件首先做按接收者的地域分布做消息事件分流，将本月用户的消息做本地存储入库，最后将消息体以及本域接收者列表打包为应同步事件，通过异步队列转发给同步服务。3、消息接收同步服务按接收者维度写入各自的同步队列，同时查取当前用户设备在线状态，当用户在线时，捞取队列中微同步的消息，通过接入层长连接推送到各端。当用户离线时，打包消息数据以及离线用户状态列表为I'M通知事件转发给通知服务的PNS模块，PNS查询离线设备做三方厂商通道推送。至此，一条消息的推送流程结束。四存储模型设计了解I'M服务最快的途径就是掌握它的存储模型。业界主流。

I'M服务对于消息绘画、绘话与消息的组织关系虽然不尽相同，但是归纳起来主要是两种形式，写扩散、读聚合。读扩散写聚合在DTIM的存储实现上，钉钉采取了混合的方案，将读扩散和写扩散针对不同场景做了适配，最终在用户视角系统会做统一合并。五、消息存储设计。DTIM底层使用了表格存储作为消息系统的核心存储系统，表格存储是一个典型LFM存储架构，读写放大是此类系统的典型问题。在存储的性能分析中，我们发现6%的用户贡献了50%左右的消息量，20%的用户贡献了74%的消息量。我们采用分而治之方法，将高频用户和低频用户的消息区别对待。6多端同步机制设计。DTI'M、面向办公场景和面向普通用户的产品在服务端到客户端的数据同步上最大的区别是消息量巨大，变更事件复杂，对多端同步有着强烈的诉求。同步服务是一套多端的数据同步服务，由两部分组成，不属于服务端的同步服务和由客户端来PP集成的同步服务。SDK工作原理类似于MQ消息队列用户ID近似消息队列中的topic用户设备近似消息队列中的consumer group.

7全量消息存储逻辑。在同步服务中，采用以用户为中心，将所有要推送给此用户的消息汇聚在一起，并为每个消息分配为一切递增的PTF及位点。英文术语point处于sequence服务端，保存每个设备推送的位点。