RabbitMQ —— 零、AMQP —— 选择 RabbitMQ 的原因

RabbitMQ —— 零、AMQP —— 选择 RabbitMQ 的原因

       工作原因，笔者最初接触使用的是 RabbitMQ，后又在闲暇时间对各开原 MQ 产品进行对比，什么功能、性能、稳定性、持久化、事务、支持的协议等，看到 RabbitMQ 时介绍说支持 AMQP 协议，起初不以为然，觉得性能、稳定性才是最重要的，直到在生产环境使用了某云商的 MQ 服务，需要在多业务线消费同一条消息时才恍然大悟，原来这就是 AMQP。

       简单来说，符合下图工作模式的 MQ，基本上就可认为是支持 AMQP 协议的消息队列服务：

一、事情起因

       笔者近期在参与一个电商类项目，需要实时统计代理商的业绩情况，而计算逻辑较为复杂，与运维同学沟通后，选择了直接使用某云商平台提供的成熟 MQ 服务，项目上线，一切良好，对了我们的 Web 应用还是用 Go 写的，性能也是棒棒的。不多久之后，仓库配送也开始做自动化，因从一开始就计划做数据异构，各自打造数据闭环，因此两边系统的交互方式就只剩下了 rpc 和 mq，再因仓库系统的抗压能力较差，最终决定也使用 mq 进行通信。

       而这时再调研发现，我们购买的云商的 MQ 服务不支持 exchange + queue 模式，只能在订单生成一方再发送一条消息到一个新的队列，之后重新走流程，又申请一个新的队列，然后排期、改代码、再次上线，这时问题发生了，项目初期 “百废待兴”，需求都很急，选择了夜里上线，结果分配的正式线队列死活推不进数据，程序出错，致使用户下单流程失败，又由于夜里人员不齐，就此发生了重大生产事故，好在经历过多年的 To C 项目历练，上线前都打过 tag，因此很快进行了版本回滚，算是临时屏蔽了问题。

二、事后总结

       事后回想起以前用过的 MQ 服务，为什么正在用的这一款不支持一次发送，多队列消费的模式，还以为这种模式是 MQ 的标配呢。接下来就是恍然大悟，原来这就是 AMQP 的好处，新业务线要消费同样的消息，不需要生产端重复发送，重新上线，只需在 MQ 的控制中心上配置一下就好了，无论新上线的服务是否有问题，都不会影响生产端的服务运行。

       以上就是开启 RabbitMQ 系列文章的起因，好了，就说到这，后面开始上干货。