消息队列和应用工具产品体系（一）

第 4 章把因果链走到了微服务和 Serverless。这一章往下一环走：服务拆得越细、调用链越长，"一个环节顶不住、拖垮一整条链路"就越容易发生。这一节先看第一道防线——消息队列。

企业应用的评判指标

在讲具体产品之前，先明确一下"系统好不好"是拿什么衡量的，这几个指标是这一整章内容存在的意义：

可用性：系统能正常对外服务的时间比例，常说的"几个 9"就是这个——99.9%（三个 9）一年大概能容忍 8.7 小时故障，99.99%（四个 9）只能容忍约 52 分钟
性能：响应时间（一次请求要多久）、吞吐量（单位时间能处理多少请求，常用 QPS 衡量）
可扩展性：流量涨了，能不能通过加机器/加实例线性地把处理能力提上去
可靠性：数据会不会丢、消息会不会重复处理

后面要讲的消息队列、限流降级、混沌工程、监控，都是为了让这几个指标在真实的高压场景下依然达标。

高并发场景下的可靠性难题

设想一个电商大促场景：瞬时涌入的下单请求远超平时几十倍。如果上游服务直接同步调用下游（比如下单服务直接同步调它去调库存服务、支付服务），会出现：

下游处理能力跟不上，请求在下游堆积、超时
超时的请求还占着上游的连接和线程资源没释放，上游自己也开始变慢
压力沿着调用链一级一级往上传导，最终演变成第 1 章提过的级联故障（雪崩）

问题的根源是同步调用把"生产请求的速度"和"处理请求的速度"绑在了一起，只要两边速度不匹配，系统就会被压垮。

微服务架构引发的问题

微服务把一个大应用拆成了几十上百个小服务，如果这些服务之间还是两两同步调用、强依赖，问题只会被放大：任何一个服务的抖动，都可能顺着调用链影响一大片本来毫不相干的功能。

需要一种机制，把"实时的强依赖"变成"异步的弱依赖"——这正是消息队列要解决的问题。

消息队列的基本概念

消息队列围绕几个核心角色展开：

生产者（Producer）：发送消息的一方
消息队列 / Broker：中间的缓冲区，负责暂存消息
消费者（Consumer）：订阅并处理消息的一方
Topic（主题）：给消息分类的逻辑通道，生产者往某个 Topic 发消息，消费者订阅某个 Topic 接收消息

引入消息队列之后，生产者发完消息就可以立刻返回，不用等消费者处理完——这带来两个直接价值：

异步解耦：生产者和消费者不再有直接的强依赖，一方的抖动不会立刻传导给另一方
削峰填谷：流量洪峰先堆积在队列里，消费者按自己的处理能力慢慢消费，不会被瞬时流量直接打垮

顺带还有一个好处：一条消息可以被多个下游系统同时订阅消费，天然支持"一次生产、多方消费"的广播场景。

阿里云消息队列产品简介

阿里云的消息队列产品家族里，最核心的两个是消息队列 RocketMQ 版和消息队列 Kafka 版，都是把对应的开源引擎做成全托管服务——免去自建集群的运维成本，同时保持和开源协议兼容。

消息队列 RocketMQ 版

RocketMQ 是阿里巴巴 2012 年自研的消息中间件，最初是为了扛住淘宝内部万亿级的消息处理量而设计的，同年就开源了第一个版本。2015 年陆续补上事务消息、定时消息、消息轨迹追踪等重量级功能。2016 年，阿里把 RocketMQ 捐给 Apache 基金会，仅用 10 个月就在 2017 年毕业成为 Apache 顶级项目——是中国第一个非 Hadoop 生态的 Apache 顶级项目。

它的核心能力：

低延迟、高可靠：消息落盘采用顺序写（commitlog 单文件顺序写入），消费定位快，延迟做得比大多数同类产品更低
事务消息：原生支持——这正是第 1 章提到的分布式事务几种方案之一，能保证"发消息"和"改本地数据库"这两个操作的最终一致性
顺序消息、定时/延时消息、死信队列：应对各种业务场景里对消息顺序和时效性的要求

阿里云托管版本相比自建，省掉的是集群运维、多可用区容灾这些重活，用户只需要关心 Topic 和消息本身。

RocketMQ 最典型的定位是业务消息：订单状态变更通知、支付结果回调、库存扣减这类和交易强相关、对可靠性和事务性要求高的场景。

消息队列 Kafka 版

Kafka 源自 LinkedIn 开源，核心特点是超高吞吐量——它的存储模型基于顺序追加的日志（log），Partition（分区）数量可以按需扩展，每个 Partition 独立顺序写，天然适合海量数据的高吞吐写入。

阿里云 Kafka 版是全托管服务，兼容开源 Kafka 协议，已经在用开源 Kafka 的应用基本不用改造代码就能迁移过来。

它最典型的定位是海量数据管道：日志采集聚合、大数据实时处理、流式计算的输入源，这些场景对吞吐量的要求远高于对复杂事务语义的要求。

RocketMQ 还是 Kafka：怎么选

	RocketMQ	Kafka
延迟	更低	略高于 RocketMQ
吞吐量	较高，但事务等功能会有一定取舍	更高，为海量吞吐而生
事务消息	原生支持，功能丰富（延迟消息、死信队列）	主要服务于 Exactly-Once 语义，功能相对基础
典型场景	订单、支付、库存这类业务消息	日志采集、大数据管道、流处理

简单记：业务事务选 RocketMQ，海量数据管道选 Kafka。

反过来也要知道 Kafka 不适合什么：数据分析（MaxCompute / Spark 的活）和数据分发到终端用户（CDN 的活）。Kafka 管的是数据的搬运和缓冲，不管计算也不管最后一公里的分发。