面试题答案
一键面试保证数据最终一致性的方法
- 本地消息表
- 原理：在数据库中创建一张本地消息表，与业务操作在同一个事务中。业务操作执行成功后，向本地消息表插入一条待发送消息记录。通过定时任务或异步线程不断扫描本地消息表，将待发送消息发送至消息队列，发送成功后更新消息表状态。接收方处理完消息后，发送确认消息，本地消息表收到确认后删除对应记录。
- 优点：实现相对简单，利用数据库事务保证业务操作与消息记录的一致性。
- 缺点：依赖数据库，可能对数据库性能产生一定影响；消息表扫描频率需合理设置，频率过高影响性能，过低影响消息发送及时性。
- 事务消息（以 RocketMQ 为例）
- 原理：生产者发送半消息（Half Message）到消息队列，此时消息对消费者不可见。生产者执行本地事务，根据事务执行结果向消息队列发送 Commit 或 Rollback 指令。消息队列根据指令决定是否将消息投递给消费者。如果生产者未发送指令，消息队列会定时回查生产者事务状态。
- 优点：不依赖额外的本地消息表，由消息队列自身保证事务性。
- 缺点：实现相对复杂，依赖消息队列对事务消息的支持；不同消息队列实现方式可能不同，兼容性较差。
高并发场景下可能出现的一致性问题及解决方案
- 消息重复消费
- 问题：在高并发环境下，由于网络波动、消费者处理超时等原因，可能导致消息队列重复投递消息，从而使消费者重复消费，破坏数据一致性。
- 解决方案：
- 幂等性处理：消费者在处理消息时，确保相同消息多次处理结果一致。例如，在数据库层面通过唯一索引防止重复插入；在业务逻辑中，先查询再操作，避免重复执行相同业务操作。
- 消息去重表：在数据库中创建消息去重表，记录已消费消息的唯一标识。消费者在消费消息前，先查询去重表，若已存在则不处理。
- 消息丢失
- 问题：生产者发送消息时网络异常、消息队列存储故障、消费者消费失败未重试等情况都可能导致消息丢失，进而影响数据一致性。
- 解决方案：
- 生产者消息确认机制：消息队列提供发送确认机制，生产者发送消息后等待确认，若未收到确认则进行重试。例如，RabbitMQ 支持 Confirm 模式，生产者可通过该模式确认消息是否成功发送到 Broker。
- 消息持久化：消息队列将消息持久化到磁盘，保证在故障恢复后消息不丢失。例如，Kafka 通过副本机制和日志文件持久化保证消息可靠性。
- 消费者消费重试：消费者消费消息失败时，根据业务情况进行重试。可设置重试次数和重试间隔，避免无限重试导致系统资源耗尽。同时，对于重试多次仍失败的消息，可发送到死信队列（Dead Letter Queue）进行后续处理。
- 消息顺序性问题
- 问题：在高并发场景下，消息队列可能为了提高性能而采用并行处理，导致消息消费顺序与发送顺序不一致，影响某些对顺序敏感的业务数据一致性。
- 解决方案：
- 单分区/队列顺序消费：将对顺序敏感的消息发送到同一个分区或队列，消费者采用单线程按顺序消费该分区或队列中的消息。例如，Kafka 可通过设置分区策略，将特定业务的消息发送到同一分区。
- 全局顺序消息（部分消息队列支持）：某些消息队列（如 RocketMQ）支持全局顺序消息，保证所有消息按照发送顺序进行消费。但这种方式性能较低，适用于对顺序要求极高且吞吐量要求不高的场景。
最佳实践结合实际项目经验
在[实际项目名称]中，我们处理订单支付相关业务时使用了消息队列保证数据最终一致性。
- 选择事务消息方式（RocketMQ）：因为订单支付业务对一致性要求较高，且系统架构对消息队列选型为 RocketMQ，利用其事务消息特性，避免了引入额外本地消息表带来的数据库压力。
- 幂等性处理：支付结果处理服务在更新订单状态时，通过订单号作为唯一索引，确保重复的支付结果消息不会造成订单状态多次更新。同时，在业务逻辑中，先查询订单当前状态，若已处理过相同支付结果则直接返回成功。
- 消息持久化与确认机制：RocketMQ 开启消息持久化功能，保证消息在服务器故障时不丢失。生产者采用同步发送并等待确认的方式，确保消息成功发送到 Broker。
- 消费重试与死信队列：消费者处理支付结果消息失败时，设置最大重试次数为 3 次，每次重试间隔 5 秒。若 3 次重试后仍失败，消息发送到死信队列，由人工定期处理死信队列中的消息，排查失败原因并手动恢复业务流程。
- 监控与报警：搭建消息队列监控系统，实时监控消息发送、消费状态，以及消息堆积情况。设置报警阈值，当出现消息发送失败、消费延迟或消息堆积超过一定数量时，及时通知运维和开发人员进行处理，保障系统数据一致性。