简介
特点
优缺点
原理

1.RabbitMQ简介

RabbitMQ是应用最广泛的开源的消息中间件。

RabbitMQ拥有数万用户，是最流行的开源消息代理之一。从T-Mobile到Runtastic，RabbitMQ在世界各地的小型初创公司和大型企业中使用。

RabbitMQ轻量级，易于在本地和云中部署。它支持多种消息传递协议。RabbitMQ可以在分布式和联邦配置中部署，以满足高规模、高可用性需求。

RabbitMQ运行在许多操作系统和云环境上，并为最流行的语言提供了广泛的开发工具。

总结特点：
广泛流行、轻量级、兼容性高、开源、插件丰富

2.优缺点

image.pngimage.png

优点：

1.特点（广泛流行、轻量级、兼容性高、开源、插件丰富）
2.时延低，微秒级，同行是毫秒级

缺点：

1.吞吐量低，万级，同行可达十万级
2.可靠性略逊一筹
3.消息累积时性能下降

3.工作原理

image.png
image.png

4种交换机类型

最新版本的RabbitMQ有四种交换机类型，分别是直接(direct), 主题(topic) ,标题(headers) , 扇出(fanout)

  • Direct Exchange

处理路由键。需要将一个队列绑定到交换机上，要求该消息与一个特定的路由键完全匹配。这是一个完整的匹配。如果一个队列绑定到该交换机上要求路由键 “abc”，则只有被标记为“abc”的消息才被转发，不会转发abc.def，也不会转发dog.ghi，只会转发abc。
image.png

  • Fanout Exchange

不处理路由键。你只需要简单的将队列绑定到交换机上。一个发送到交换机的消息都会被转发到与该交换机绑定的所有队列上。很像子网广播，每台子网内的主机都获得了一份复制的消息。Fanout交换机转发消息是最快的。
image.png

  • Topic Exchange

将路由键和某模式进行匹配。此时队列需要绑定要一个模式上。符号“#”匹配一个或多个词，符号“”匹配不多不少一个词。因此“abc.#”能够匹配到“abc.def.ghi”，但是“abc.” 只会匹配到“abc.def”。
image.png

  • Headers Exchanges

不处理路由键。而是根据发送的消息内容中的headers属性进行匹配。在绑定Queue与Exchange时指定一组键值对；当消息发送到RabbitMQ时会取到该消息的headers与Exchange绑定时指定的键值对进行匹配；如果完全匹配则消息会路由到该队列，否则不会路由到该队列。headers属性是一个键值对，可以是Hashtable，键值对的值可以是任何类型。而fanout，direct，topic 的路由键都需要要字符串形式的。
匹配规则x-match有下列两种类型：
x-match = all ：表示所有的键值对都匹配才能接受到消息
x-match = any ：表示只要有键值对匹配就能接受到消息

4.常用命令

  1. //停止服务
  2. rabbitmq-service stop
  3. //启动服务
  4. rabbitmq-service start    
  5. //重启命令
  6. net stop RabbitMQ && net start    
  7. //帮助命令
  8. rabbitmqctl help                        
  9. //查看所有队列
  10. rabbitmqctl list_queues            
  11. //清除所有队列
  12. rabbitmqctl reset                        
  13. //查看所有交换器
  14. rabbitmqctl list_exchanges    
  15. //添加用户
  16. rabbitmqctl add_user username password    
  17. //分配角色
  18. rabbitmqctl set_user_tags username administrator    
  19. //查看交换器和队列的绑定关系
  20. rabbitmqctl list_bindings     
  21. //健康检查
  22. rabbitmqctl status
  23. //启动监控管理器
  24. rabbitmq-plugins enable rabbitmq_management
  25. //关闭监控
  26. rabbitmq-plugins disable rabbitmq_management

5.消息可靠性

5.1 可靠性投递

什么是生产端的可靠性投递？
1、保障消息的成功发出；
2、保障MQ节点的成功接收；
3、发送端收到MQ节点（Broker）确认应答ACK；
4、完善的消息进行补偿机制。

5.2 解决方案

互联网大厂的解决方案：
消息落库，对消息状态进行打标；
消息的延迟投递，做二次确认，回调检查。
1、消息落库/持久化
消息信息落库（即消息持久化），对消息状态进行打标：
image.png
注：这种方案需要对数据库进行两次持久化操作。
2、延迟投递
消息落库在高并发场景下，数据库IO压力大，不适用。互联网大厂一般采用的是延迟投递，做二次检查，回调检查。
image.png
注：upstream表示生产端，downstream表示消费端。
1、首先，数据库持久化，然后发送first send消息；
2、同时发送一个延迟的检查消息（检查第一次发送消息消费情况）；
3、消费端消费消息；
4、消费端发送一个确认消息给Broker；
5、回调服务检测到消费端的确认消息，进行数据库的状态持久化（这样相当于数据库一次操作，异步持久化）；
6、回调服务响应第二个延时消息，确认消息成功消费，如果出现异常，回调服务调用RPC给生产者，再次发送。

6.SpringBoot整合