💡 使用消息队列的背景
- 在单体应用时代，组件之间紧密耦合。
- 以电商系统为例，下订单时需要订单服务与库存服务进行通信，通信完毕后才能有后续的订单再和库存服务通信。如果订单与库存无法连接产生大量重试，或者订单太多库存服务跟不上，系统将出现问题。
- 因此，使用消息队列。
✅ 消息队列
- 消息队列能够让订单服务源源不断生产消息，并排队，排队后即可处理下一个任务了；库存服务可以不断地消费订单服务给它生产的消息。
- 因此，订单服务和库存服务就解耦合了。
- 同时，如果我们有多个库存服务，那么消息队列就可以让订单的服务去找到合适的库存服务来处理，能够提升扩展性。
- 另外，消息队列可以在服务本地的机器上，能够卸载一些不必要的Web组件完成的工作，提升性能。
🐰 RabbitMQ
RabbitMQ是AMQP（Advanced Message Queuing Protocol，高级消息队列协议）的一种实现。
中间的部分就是RabbitMQ的工作，也叫做Message broker，消息代理。
这样的结构保证系统非常灵活，能够保证多种不同类型的消息交换。
📝 消息交换的类型
1️⃣ Fanout 发布/订阅模式
生产者生产出消息后，经过exchange把消息直接发到所有消息队列里面。
2️⃣ Direct 路由模式
生产者生产的消息会有一个Routing Key，这个将会和Binding Key进行对比，匹配的才会发送到对应队列里面。
3️⃣ Topic 通配符模式
在Routing Key和Binding Key之间进行部分匹配，例如Routing Key里面是”ship.shoes”，而Binding Key里面是”ship.any”，那么就能匹配通过。
4️⃣ Header 头模式
和Topic模式类似，但是它不看Routing Key，只看消息的Header。
5️⃣ Default 默认模式
RabbitMQ独有的模式。
Routing Key匹配到队列名字。比如Routing Key叫做”abc”，那么直接匹配到名字为”abc”的队列里面去。
✅ RabbitMQ的优点
- 灵活性高。消息队列传递很大程度上取决于应用程序设计者而非队列管理员。
- 对云友好。可以在Docker上部署，可以作为集群运行，具有容错性、高可用性和高吞吐量。
- 支持跨语言。生产者和消费者的处理可以使用不同的语言来实现。
- 安全性高。支持FASL、LDAP、TLS进行身份验证和授权。
- 有消息确认机制。除非消费者告知队列它已经收到了消息，否则不会释放这条消息。能够防止系统丢失任何消息。
- 具有良好的管理界面，通过Web界面即可进行管理。
- 开源插件丰富。甚至可以支持其他消息模型。