钉钉IM系统的挑战与实践,,,,万人群 历史消息回溯 高可用,,万群的规模,,一万人参与的贝多芬第九号交响曲大合唱,为什么要做万群,,,,,,,,,,万群的技术挑战,,稳定 大群大量发消息，系统压力山大,,体验 选人组件还能再慢点吗？ 发红包根本选不到人,,2016,2018,,2017 成本,成本 很多客户都想有个大群，能不能不要 限制大群数量？,群限流,,热点大群限流 系统容量足够时，尽量允许大群 发消息,消息属性,,可见性,全员可见：所有人都可以看到消息 部分可见：部分人可见，其他人看不到消息,,,多态性,普通：每个人的消息状态完全相同 多态：每个人的消息状态不完全相同,发送者视角,接收者视角,写扩散模型,以用户维度建立消息收件箱,问题：万人群扩散量太大！,读写扩散混合模型,95%以上是普通全员可见消息 相同的状态记录，合并至会话消息表 个性化状态仍然写入消息收件箱，读取时做合并,,写扩散 一份顶一万份，大幅降低写压力和消息存储成本,万群成员,,10S+ 体验差：用户查看群成员耗时长 10000行 稳定性差：拉取万行群成员记 录，易造成DB热点,万群成员,用户查看群成员快快快，服务端DB稳稳稳,,,,,,,,,,, ,%,万人群 历史消息回溯 高可用,,历史消息获取模型,,,,,,,进入会话都从服务端拉取 消息断层时，可确保不丢消息,依靠服务端推送 单次推送超过阈值时丢弃,服务端推送超过上限时，转换为拉模型 只拉取增量会话及lastMsg,消息存储冷热分离,冷热属性 用户通常只访问、修改近期的消息,设计原则,可复用性强，业务改动小 冷库访问尽量少 冷库支持最小范围的功能,实现 热库(POLARDB InnoDB) + 冷库(POLARDB X-Engine),成本降低70%，结构变更从7天变为1小时,,,0,,, 14,,, ,,,Corona(),,,,,,,消息安全保障,,,,,,,,,,,,,0,,,,,/:6,rpc,,,,AliSQL,,,,消息全链路加密。
消息流转的每一个点都是加密的！,万人群 历史消息回溯 高可用,,,,,可,99.995%,可设计,多级冗余,核心中间件冗余 同城双机房 异地容灾,自动降级 保障消息收发核心功能,,,,,,,,,AliSQL,,,,,,,,,AliSQL,,,USF ,,,,,,,,,,,,,,,,,,,,稳定性保障机制,, 1000 ,, 90% ,, 15 ，,更多挑战,平台化 多租户 更灵活的业务模型,做世界最好的企业级IM！,性能成本 数据按需存储 极致弹性,体验 多媒体 低功耗,,,,。