本文以京东系统为例，探讨在使用RabbitMQ时遇到的系统解耦、流量控制及由此引发的数据一致性与消息积压问题。通过分析消息丢失的三个阶段，并提出数据库日志记录和幂等操作的解决方案，以及处理消息积压的方法，如增加消费端实例与分区数量。此外，还强调了解决问题的思考过程和架构设计的重要性。
以京东系统作为一个例子，用户每次购买商品时，通常会选择用京豆抵扣一部分商品的金额，在这个过程中，交易服务和京豆服务通过MQ消息队列进行通信。下单的时候，交易服务发送“扣减账号X100个京豆"消息给MQ消息队列，而京豆服务则在消费端消费这条命令，实现真正的扣减操作
| 交易服务 | 消息中间件 | 京豆 |
这个过程中会遇到什么问题呢？
案例分析
要知道，在互联网面试中，引入 MQ 消息中间件最直接的目的是：做系统解耦合流量控制，追其根源还是为了解决互联网系统的高可用和高性能问题。
1.系统解耦：用 MQ 消息队列，可以隔离系统上下游环境变化带来的不稳定因素，比如京豆服务的系统需求无论如何变化，交易服务不用做任何改变，即使当京豆服务出现故障，主交易流程也可以将京豆服务降级，实现交易服务和京豆服务的解耦，做到了系统的高可用。
2.流量控制：遇到秒杀等流量突增的场景，通过 MQ 还可以实现流量的“削峰填谷”的作用，可以根据下游的处理能力自动调节流量。
不过引入MQ虽然实现了系统解耦合流量控制，也会带来其他问题。
引入 MQ 消
最低0.47元/天 解锁文章
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
