消息队列 - 基础篇
消息队列 - 基础篇
前言
常见问题：
- 技术选型
- 高可靠、高可用、高性能
- 不重复、不丢失
- 水平扩展
底层技术：
- 分布式系统
- 海量数据
- 海量并发
消息模型
消息模型：
- 队列模型
生产者 - 队列 - 消费者 - 发布订阅模型
发布者 - 主题 - 订阅者
RabbitMQ 消息模型：
- Queue - Consumer
Producer - Exchange
- Queue - Consumer
RocketMQ / Kafka 消息模型：
- Queue/Partition -
Producer Group - Topic - Consumer Groups
- Queue/Partition -
- 一个主题可以有多个分区，以支持多实例并行生产和消费
- 一个主题可以被多个消费者组订阅，每个消费者组都会接收全量消息，同一个消息只能被组内的一个消费者消费
- RocketMQ 只在队列上保证消息的有序性，无法在主题层面保证消息的严格顺序
kafka 叫分区，RocketMQ 叫队列
消息丢失
消息丢失检测
- 分布式链路追踪系统
- 给消息添加序号
序号检测方式：
- 在生产者和消费者的拦截器注入和验证序号的连续性
- 确保生产者、消费者、消息队列分区的数量一致
消息可靠传递
消息传递的三个阶段：
- 生产阶段 (Producer)
- 存储阶段 (Broker)
- 消费阶段 (Consumer)
生产阶段：
- 消息队列通过请求确认机制和失败重试机制确保消息不丢失
- 生产者要确保处理消息发送失败的异常
存储阶段：
- 写入磁盘并且刷盘后再发送确认
- 集群环境要确保消息复制到两个副本后到发送确认
消费阶段：
- 消息队列通过请求确认和失败重试确保消息不丢失
- 消费者要在执行消费逻辑后再发送确认
消息重复
服务质量标准
MQTT 协议的三种服务质量标准：
at most once：至多一次，允许丢失消息。at least once：至少一次，不允许消息丢失，但允许消息重复。exactly once：精确一次，不允许消息丢失，也不允许消息重复。
大多数消息队列产品都提供至少一次的服务质量标准。
用幂等性解决消息重复
处理消息重复，需要保证消费者的消费逻辑具有幂等性。
at least once + 幂等消费 = exactly once
幂等性操作：一个操作执行任意多次和执行一次对系统的影响是相同的。
常用的幂等设计：
- 利用数据库的唯一约束或
SETNX实现幂等 - 增加一个版本号字段
- 使用 token 或 GUID （全局唯一ID），在操作前检查 token 是否有效，操作后销毁 token
检查、操作、销毁需要保证原子性和同步。
避免出现 A 检查后未销毁时 B 检查通过导致重复操作。
消息积压
Producer 性能
- 批量发送：适合离线业务，比较在意吞吐量的场景
- 提高并发：适合在线业务，比较在意时延的场景
Consumer 性能
- 优化消费业务逻辑
- 扩容 Consumer 实例数量（同时扩容分区数量）
要保证 Consumer 数量和分区数量一致，
因为每个分区实际上只支持单线程消费。
消息积压排查
排查方法：
- 监控系统
- 日志
常见原因：
- 突发请求导致生产者发送大量消息（服务降低、扩容消费者）
- 消费者消费失败导致重复消费
- 消费者发生死锁
分布式事物
分布式事务：
- 2PC：二阶段提交
- TCC（Try-Confirm-Cancel）
- 事务消息
事务消息
事务消息适合需要异步更新数据，对数据实时性要求不高的场景。
事务消息执行过程：
- 生产者在消息队列开启事务
- 生产者发送半消息（消息对消费者不可见）
- 生产者执行本地事务（数据库事务）
- 提交/回滚消息队列事务（提交后消息对消费者可见）
提交失败：
- kafka 在事务提交失败时会抛出异常。
- 重试：尝试再次提交事务
- 补偿：删除插入数据
- RocketMQ 使用事务反查机制来处理提交失败
参阅
- 《消息队列高手》- 李玥
