RabbitMq消息中间件的学习（详细，通俗）

首先在正式学习之前我们来看一下RabbitMq的一些应用场景以及RabbitMq与一些其他的消息中间件有啥区别，为什么RabbitMq在现在的市场上这么多人去使用

1. 削峰 ，当我们业务遭遇到一些高并发例如秒杀的时候：我们就可以选用rabbitmq进行对高并发的请求进行削峰：原理是当我们有大量的请求去访问我们的服务器时，容易造成数据库和服务器的压力过大导致冲垮服务器或者数据库，这时候就要用rabbitmq将一些用户请求先放在我们的rabbitmq服务器上，然后根据我们在rabbitmq上设定的规则去将这些请求发送到我们的服务器上，比如设置延时等等，这样根据我们的需求去获取这些请求；
2. 异步请求很简单的道理就是当我们通过一些串行的去走我们的业务的时候，就得等我们前面的业务走完才能进行下一个业务，而使用我们的rabbitmq时就可以将我们前面的业务获取到的数据存入到rabbitmq中，其他业务就可以异步的获取这些数据进行相对应的业务，（其实异步的实现也是实现了削峰的效果：将一些请求异步的调用也是可以减缓我们的请求压力）
3. 解耦例如生成订单的时候就要将存库的数量减一，但是如果将这两个连起来的业务一旦库存业务失败也就会导致生成订单失败，所以就得解耦将两个业务分开，可以通过rabbitmq来进行数据的传递，这样库存失败了也不会影响用户下单这一个业务

现在的市场上流行的消息中间件还有很多ActiveMq，RocketMq，kafka以及我们正在学习的RabbitMq，这是我网上找到的一个图，可以进行对比一下没啥还说的，也就是性能，可靠性，可用性，高并发这些的处理谁比较使用（没有说哪个中间件比较厉害，知识针对不同的需求，各个中间件都有各自的好处）

接下来开始进入RabbitMq的学习之路

1 ，安装

安装就不用多讲，要注意的时rabbitmq是基于erlang语言下的，所以首先要部署一个erlang环境，官网下载RabbitMq的安装包，window的话直接启动，另外如果要下载可视化工具就有顺便在bin的目录下安装下来就行了，linux的话用docker一键安装更快，docker真是个好东西

2 ，RabbitMq的各个组件介绍

Exchange：交换机就是我们的接受信息或者发送消息的一个中转站，可以通过交换机去绑定一个队列这样就是消息就是通过发送到交换机上再通过交换机绑定的队列将消息存入到指定的队列上

Queue：队列，而队列就是存储消息的一个载体，我们在敲代码的时候就是通过指定的queue去获取里面的消息，而不是直接去获取消息

Channel：管道，我的理解就是基于tcp/ip协议上面去通过管道去进行交换机队列直接的联系，而我们rabbitmq遵循的协议时amqp协议这个协议也是基于tcp/ip协议上的

3，RabbitM的六种工作模式

simple简单模式

1消息产生着§将消息放入队列
2消息的消费者(consumer) 监听(while) 消息队列,如果队列中有消息,就消费掉,消息被拿走后,自动从队列中删除(隐患 消息可能没有被消费者正确处理,已经从队列中消失了,造成消息的丢失)应用场景:聊天(中间有一个过度的服务器;p端,c端)

work工作模式

而工作模式分为两种，1轮询工作模式：就是一个消息队列里面的消息可以平分到我们的消费者上，，，，2公平分发模式：就是一个消息队列上的消息条数，根据消费者的能力（服务器性能，获取的速度等等）分配到消费者中，但是消费者获取到的消息是不同的，没有获取到一样的消息的

fanout（发布与订阅）模式

1X代表交换机rabbitMQ内部组件,erlang 消息产生者是代码完成,代码的执行效率不高,消息产生者将消息放入交换机,交换机发布订阅把消息发送到所有消息队列中,对应消息队列的消费者拿到消息进行消费
2相关场景:邮件群发,群聊天,广播(广告)

direct（路由key）模式

1，消息生产者将消息发送给交换机按照路由判断,路由是字符串(info) 当前产生的消息携带路由字符(对象的方法),交换机根据路由的key,只能匹配上路由key对应的消息队列,对应的消费者才能消费消息;
2，根据业务功能定义路由字符串
3，从系统的代码逻辑中获取对应的功能字符串,将消息任务扔到对应的队列中业务场景:error 通知;EXCEPTION;错误通知的功能;传统意义的错误通知;客户通知;利用key路由,可以将程序中的错误封装成消息传入到消息队列中,开发者可以自定义消费者,实时接收错误;

topic 主题模式(路由模式的一种)

1 星号井号代表通配符
2星号代表多个单词,井号代表一个单词
3路由功能添加模糊匹配
4消息产生者产生消息,把消息交给交换机
5交换机根据key的规则模糊匹配到对应的队列,由队列的监听消费者接收消息消费

还有一个RPC模式我就先不说了没咋用到

4，RabbitMq集成springboot并实现相应的操作

导入springboot集成rabbitmq的jar包

声明一个queue队列，里面可以设置一些参数，name: 队列的名称，durable:是否持久化，autoDelete:是否自动删除，exclusive: 是否独享、排外的；arguments：队列的其他属性参数（比如是设置队列的过期时间，队列过期时间等等）

声明一个交换机，参数其实也跟声明一个队列差不多参考上面的队列就行了

对交换机和队列进行绑定关系，是通过Binding里面的子类bindingbuild进行绑定

通过rabbittemplate的convertAndSend方法进行对消息发送，参数就是发送到哪个交换机上exchangeName，routingkey绑定的队列，和要发送的消息

这是基本的配置文件

5，过期时间TTL
过期时间可以设置给队列的过期时间或者是消息的过期时间，设置给队列的话，一旦队列过期，里面的所有消息都会消失，在可视化工具上可以设置，在代码中设置就如下

6，消息的确认机制
消息确认机制可以分为生产者和消费者两方的确认消息
一，生产方的确认消息是到消息发送到我们的rabbitmq的服务器上我们可以受到服务器回调的一个comfirm来确认消息，并需要在配置文件上配置开启comfirm


二，消费者确认机制：分为以下三种确认模式

AcknowledgeMode.NONE：不确认（就是消费者拒绝接受此消息）
AcknowledgeMode.AUTO：自动确认（确认之后会自动删除消息，一般不建议使用）
AcknowledgeMode.MANUAL：手动确认（就是通过我们自己的方式去返回确认消息）

spring-boot中配置方法：
spring.rabbitmq.listener.simple.acknowledge-mode = manual（手动确认）

下面我们会具体讲一下手动确认（可以在既定的异常情况下不进行确认（RabbitMQ 会继续保留该条数据），这样下一次可以继续消费该条数据。）
1，使用 @RabbitListener 来监听队列；
2，从消息头里拿到消息的唯一表示 deliveryTag；
3，使用== channel.basicAck ==来确认消息已经消费；
4，如果有异常，使用 channel.basicNack 把消费失败的消息重新放入到队列中去。

这是一个整体的图

7，rabbitmq持久化
如果我们希望即使在RabbitMQ服务重启的情况下，也不会丢失消息，我们可以将Queue与Message都设置为可持久化的（durable）,就是在声明队列的时候要设置durable在发送消息的时候也要设置durable，设置了队列持久化并不代表消息也能持久化

8，内存磁盘的监控
rabbitmq的内存也是使用本机的内存，所以当消息过多的时候也会造成内存满，而导致queue阻塞而这时候可以通过两个方法对此改进

1，可以对一些不用的消息队列进行过期时间的设置，到达一定的时间就会删除队列，从而为队列腾出空间
2，可以手动的设置rabbitmq服务的内存大小
监控方式是通过可视化工具查看如下：

memory代表当前的内存，而下面显示着可以接受的最大内存
disk space代表本地的内存，当当前的内存不足的时候就可以从本地的内存进行分配到内存上分配方法是打开本地的rabbitmq安装路径下的conf配置文件的vm_memory_high_watermark ：0.6参数进行修改，修改一下memory与dist的一个比例即可，如果在linux系统下的进入docker的rabbitmq容器后rabbitmqctl set_vm_memory_high_watermark 0.6设置

9可靠性和插件
可靠性指的也是也就是
1，发送消息时的确认机制，上面就有说到，发送者可以通过comfirm去获取rabbitmq服务的相应，而接收者就是通过设置手动应答channel.basicAck去应答服务器给与回应消息确保消息被消费
2，存储可靠性：broker端对消息的持久化，确保消息不会丢失。
rabbirmq可以支持插件可以协助来完成工作

10，rabbitmq实现分布式事务
分布式事务模拟场景

通过rabbitmq实现分布式的原理图

1，防止rabbitmq服务器出现问题导致消息丢失
2，创建数据的备份一个表去存储rabbitmq出现问题后的数据
3，采用发送消息后的消息确认机制comfirm来获取是否发送成功如果失败放回一个效应这时候就将消息多存一份在备份表上
4，然后设置定时器重新发表的数据到消息队列上面，如果出现多次放回就证明异常
5，如果消费者出现问题，我们就要设置一个死信队列，将故障后设置手动应答，将消息存储在死信队列中
5，通过这样的机制去确保消息的不会丢失

11，死信队列
死信队列就是用来存储我们队列中一些如下，主要声明跟普通的队列一样
1过期的消息
2被拒绝的消息
3达到最大队列长度
然后死信队列的运作流程接收流程：在声明业务的队列和交换机之后还要声明一个死信队列和交换机，在然后再业务的队列中绑定一个私信交换机，然后就会发送在私信交换机上然后到死信队列
生产者–>发送消息–>交换机–>队列–>变成死信队列–>DLX交换机–>队列–>监听–>消费者

12，延时队列
一些应用场景：（结合理解）
1，订单在十分钟之内未支付则自动取消。
2，新创建的店铺，如果在十天内都没有上传过商品，则自动发送消息提醒。
3，账单在一周内未支付，则自动结算。
4，用户注册成功后，如果三天内没有登陆则进行短信提醒。
5，用户发起退款，如果三天内没有得到处理则通知相关运营人员。
6预定会议后，需要在预定的时间点前十分钟通知各个与会人员参加会议。

延时队列，不就是想要消息延迟多久被处理吗，TTL则刚好能让消息在延迟多久之后成为死信，另一方面，成为死信的消息都会被投递到死信队列里，这样只需要消费者一直消费死信队列里的消息就万事大吉了，因为里面的消息都是希望被立即处理的消息。

13，HA集群
https://blog.csdn.net/weixin_45492007/article/details/106378360