在使用 MQ 的时候，怎么确保消息 100% 不丢失？
这个问题在实际工作中很常见，既能考察候选者对于 MQ 中间件技术的掌握程度，又能很好地区分候选人的能力水平。接下来从这个问题出发，探讨应该掌握的基础知识和答题思路，以及延伸的面试考点。
案例背景
以京东系统为例，用户在购买商品时，通常会选择用京豆抵扣一部分的金额，在这个过程中，交易服务和京豆服务通过 MQ 消息队列进行通信。在下单时，交易服务发送“扣减账户 X 100 个京豆”的消息给 MQ 消息队列，而京豆服务则在消费端消费这条命令，实现真正的扣减操作。
分析
引入 MQ 消息中间件最直接的目的：做系统解耦合流量控制，解决互联网系统的高可用和高性能问题。
- 系统解耦：用 MQ 消息队列，可以隔离系统上下游环境变化带来的不稳定因素。
京豆服务的系统需求无论如何变化，交易服务不用做任何改变，即使当京豆服务出现故障，主交易流程也可以将京豆服务降级，实现交易服务和京豆服务的解耦，做到了系统的高可用。 - 流量控制：遇到秒杀等流量突增的场景，通过 MQ 还可以实现流量的“削峰填谷”的作用，可以根据下游的处理能力自动调节流量。
引入 MQ 也会带来其他问题：
- 实现了系统解耦，会影响系统之间数据传输的一致性。
- 解决流量控制， 会使消费端处理能力不足从而导致消息积压。
问题的几个要点：
- 哪些环节可能丢消息？
- 如何知道有消息丢失？
- 如何确保消息不丢失？
解决方案
消息丢失的环节
一条消息从生产到消费完成这个过程，可以划分三个阶段：消息生产阶段，消息存储阶段和消息消费阶段。
- 消息生产阶段：从消息被生产出来，然后提交给 MQ 的过程中，只要能正常收到 MQ Broker 的 ack 确认响应，就表示发送成功，所以只要处理好返回值和异常，这个阶段是不会出现消息丢失的。
- 消息存储阶段：这个阶段一般会直接交给 MQ 消息中间件来保证，Broker 会做副本，保证一条消息至少同步两个节点再返回 ack。
- 消息消费阶段：消费端从 Broker 上拉取消息，只要消费端在收到消息后，不立即发送消费确认给 Broker，而是等到执行完业务逻辑后，再发送消费确认，也能保证消息的不丢失。
方案每个阶段都能保证消息的不丢失，但在分布式系统中，故障不可避免，作为消息生产端并不能保证 MQ 是不是弄丢了消息，所以还是需要一种机制来检查消息是否丢失了。
消息检测
总体方案解决思路：在消息生产端，给每个发出的消息都指定一个全局唯一 ID，或者附加一个连续递增的版本号，然后在消费端做对应的版本校验。
利用拦截器机制实现：
- 在生产端发送消息之前，通过拦截器将消息版本号注入消息中（版本号可以采用连续递增的 ID 生成，也可以通过分布式全局唯一 ID生成）。
- 然后在消费端收到消息后，再通过拦截器检测版本号的连续性或消费状态。
这样实现的好处是消息检测的代码不会侵入到业务代码中，可以通过单独的任务来定位丢失的消息，做进一步的排查。
怎么解决消息被重复消费的问题？
回答完“如何确保消息不会丢失？” 之后，面试官通常会追问“怎么解决消息被重复消费的问题？”
分析
在消息消费的过程中，如果出现失败的情况，通过补偿的机制发送方会执行重试，重试的过程就有可能产生重复的消息。
解决方案
在数据库中建一张消息日志表， 这个表有两个字段：消息 ID 和消息执行状态。将消费消息的逻辑变为：在消息日志表中增加一条消息记录，然后再根据消息记录，异步操作更新用户京豆余额。
每次都会在插入之前检查是否消息已存在，所以就不会出现一条消息被执行多次的情况，这样就实现了一个幂等的操作。
全局ID生成策略
想要解决“消息丢失”和“消息重复消费”的问题，有一个前提条件就是要实现一个全局唯一 ID 生成的技术方案，这也是面试官喜欢考察的问题。
在分布式系统中，全局唯一 ID 生成的实现方法有数据库自增主键、Redis、UUID、Twitter-Snowflake 算法。
自动增长列
优点：数据库自带功能，有序，性能佳。
缺点：单库单表无妨，分库分表时如果没有规划，ID可能重复。
解决方案：
1、设置自增偏移和步长
### 假设总共有 10 个分表
### 级别可选: SESSION(会话级), GLOBAL(全局)
SET @@SESSION.auto_increment_offset = 1; ### 起始值, 分别取值为 1~10
SET @@SESSION.auto_increment_increment = 10; ### 步长增量
如果采用该方案，在扩容时需要迁移已有数据至新的所属分片。
2、全局ID映射表
在全局 Redis 中为每张数据表创建一个 ID 的键，记录该表当前最大 ID；
每次申请 ID 时，都自增 1 并返回给应用；
Redis 要定期持久至全局数据库。
UUID(128位)
在一台机器上生成的数字，它保证对在同一时空中的所有机器都是唯一的。通常平台会提供生成UUID的API。
UUID 由4个连字号(-)将32个字节长的字符串分隔后生成的字符串，总共36个字节长。形如：550e8400-e29b-41d4-a716-446655440000。
UUID 的计算因子包括：以太网卡地址、纳秒级时间、芯片ID码和许多可能的数字。
UUID 是个标准，其实现有几种，最常用的是微软的 GUID(Globals Unique Identifiers)。
优点：简单，全球唯一；
缺点：存储和传输空间大，无序，性能欠佳。
Snowflake(雪花) 算法
Snowflake 是 Twitter 开源的分布式 ID 生成算法，其结果为 long(64bit) 的数值。
其特性是各节点无需协调、按时间大致有序、且整个集群各节点单不重复。
该数值的默认组成如下(符号位之外的三部分允许个性化调整)：
- 1bit: 符号位，总是 0(为了保证数值是正数)。
- 41bit: 毫秒数(可用 69 年)；
- 10bit: 节点ID(5bit数据中心 + 5bit节点ID，支持 32 * 32 = 1024 个节点)
- 12bit: 流水号(每个节点每毫秒内支持 4096 个 ID，相当于 409万的 QPS，相同时间内如 ID 遇翻转，则等待至下一毫秒)
几种方案的特点
消息积压
除了“怎么解决消息被重复消费的问题？”之外，面试官还会问到“消息积压”。
原因在于消息积压反映的是性能问题，解决消息积压问题，可以说明候选者有能力处理高并发场景下的消费能力问题。
分析
如果出现积压，那一定是性能问题，想要解决消息从生产到消费上的性能问题，就首先要知道哪些环节可能出现消息积压，然后在考虑如何解决。
因为消息发送之后才会出现积压的问题，所以和消息生产端没有关系，又因为绝大部分的消息队列单节点都能达到每秒钟几万的处理能力，相对于业务逻辑来说，性能不会出现在中间件的消息存储上面。所以出问题的肯定是消息消费阶段。
解决方案
从消费端入手：
- 如果是线上突发问题，要临时扩容，增加消费端的数量，与此同时，降级一些非核心的业务。
通过扩容和降级承担流量，表明了对应急问题的处理能力。 - 其次排查解决异常问题，如通过监控，日志等手段分析是否消费端的业务逻辑代码出现了问题，优化消费端的业务处理逻辑。
- 如果是消费端的处理能力不足，可以通过水平扩容来提供消费端的并发处理能力。
注意在kafka中在扩容消费者的实例数的同时，必须同步扩容主题 Topic 的分区数量，确保消费者的实例数和分区数相等。如果消费者的实例数超过了分区数，由于分区是单线程消费，所以这样的扩容就没有效果。
