万亿级消息背后: 小米消息队列的实践

  万亿级消息背后的小米消息队列实践

往期文章回顾：Mysql数据实时同步实践

目录

1. 业务背景

2. 架构与关键问题

3. 性能与资源优化

4. 平台化效率

5. 小米消息中间件的规划与愿景

前文《消息队列价值思考》讲述了消息中间件在企业 IT 架构中的重要价值，本文将呈现这些价值在落地小米业务过程中的遇到的问题和实践经验；其主要内容是流式平台团队在 SACC 2019 （sacc.it168.com）大会上分享的主题，这里简单整理成文，供大家参考，其中一些重要问题的细节会在后续文章陆续展开；

今天的主题主要包括以下几个方面的内容：

• 业务背景：消息队列在小米落地的业务背景

• 架构与关键问题：小米自研分布式消息队列 Talos 的架构和关键问题

• 性能与资源优化：业务爆发式增长，Talos 在性能和资源方面的挑战与实践经验

• 平台化效率：举例 Talos 在平台化过程中提升效率的一些实践

• 未来规划：小米消息中间件的规划和愿景

业务背景

小米内部在 2015 年之前使用的是 Kafka 0.8 版本，当时的痛点比较多，由于 Kafka 本身是存储计算耦合的架构，使得数据不均衡的问题经常凸显，集群扩容、故障恢复也变得异常麻烦，给运维工作带来不少痛苦；同时，由于 Consumer 的 Rebalance 算法每次都是全部重新计算，使得业务的消费体验也不是很好； 
作者批注：存储计算耦合的架构在扩容和故障转移时都需要进行数据搬迁；故障恢复时一般要经历复杂的算法先选举 Leader，且提供服务前要先保证各副本数据是一致的

我们期望能有一个快速扩容、无状态无感知的消息队列，同时具有很好的容错机制，故障时可以快速恢复，减少运维的复杂度；消费端希望发生变化时能有一个最小损失的算法，让消费尽量平滑；同时这个系统需要高度定制化，以满足小米内部业务和生态链公司的需求，比如多租户相关的特性，跨机房的 Replication 机制等； 
作者批注：当时开源的消息队列在多租户方面都不是很完备，更多倾向在数据管道或解耦RPC调用的特性上

在这样的背景下，有了小米自研的分布式消息队列：Talos，它立项的目标是对内满足小米各部门的业务需求，对外为生态链公司输出中间件能力，系统本身对标 AWS Kinesis 与 Apache Kafka。

我们来看一下 Talos 目前在小米系统架构中的角色，主要有两种：在线的消息队列与数据集成平台的总线；

在线消息队列主要是直接使用 Talos 的 SDK — Producer