rabbitMQ笔记

RabbitMQ是有erlang语言开发，所以必须erlang环境才能运行

 

对比：

 

Erlang语言最初目的是进行大型电信交换机设备的软件开发，是一种适合于大规模并发处理的高性能编程语言。

 

管理平台：http://127.0.0.1:15672

默认账号：guest/guset

 

Virtual hosts:

想mysql有数据库的概念并且可以指定用户对库和表等操作的权限，rabbitmq也有类似的权限管理，每个virtualhost都是独立，隔离的，不能互通；

 

好处：

1. 不同团队有不同的virtualhost，好处就是相互进行隔离；
2. 适合于大型公司区分不同业务

 

Rabbitmq协议端口号：5672

 

 

 

五种形式模式：

1. 点对点的模式（少用）

一对一模式，一个生产者投递消息给队列，只允许有一个消费者进行消费；

注意；如果集群的话，会进行均摊消费；

 

队列：以先进先出原则进行存放消息的集合。

 

长连接：节约客户端连接消耗，但是长时间连接会消耗资源；

 

案例：

创建maven项目，引入依赖：

 

创建链接工具类：

 

生产者类：

 

后台管理看到发送的信息：

 

消费者：

 

消费者启动之后不能关闭，一直监听消息，当生产者发送消息的时候，消费者会打印：

 

1. 工作队列模式（少用）

能者多劳；

 

公平队列原理：队列服务器想消费者发送消息的时候，消费者采用手动应答模式，队列服务器必须要收到消费者发送ack结束通知，才会继续发送下一个；

案例：

 

运行结果：

 

1. 发布订阅模式（多用）

这个可能是消息队列中最重要的队列了，其他的都是在他的基础上进行扩展。

 

思路解读：

1. 一个生产者，多个消费者
2. 每一个消费者都有自己的一个队列
3. 生产者没有直接发消息到队列中，而是发到交换机
4. 每个消费者的队列都绑定到交换机上
5. 消息队列通过交换机到么每个消息队列

该模式就是fanout exchange（扇型交换机），交换机有多种类型：direct exchange(直连)，fanout exchange(扇型交换机)，topic exchange（主题交换机），header exchange(头交换机)

注意：交换机没有存储信息功能，如果消息发送到没有绑定消费队列的交换机，消息则丢失；

生产者：（连接工具类共用了）

 

邮件消费者：

 

短信消费者：

 

运行结果：

 

1. 路由模式routingKey（多用）

生产者发送消息到交换机并指定一个路由key,消费者队列绑定到交换机是要指定路由key（key匹配就能接收消息，否则不能接收消息）

 

 

生产者：

 

邮件消费者：

 

短信消费者：

 

邮件只能接收邮件的，短信只能接收短信的；

运行结果：

 

1. 通配符模式topics

 

在路由key模式的基础上，使用通配符来管理消费者信息。生产者发送消息到交换机，type=topic,交换机根据绑定队列的routingkey的值进行通配符匹配：

 

符号#：匹配一个或者多个词，如msg.# 可以匹配msg.aaa或者msg.aa.bb;

符号*：只能匹配一个词，如msg.* 可以匹配msg.aaa或者msg.bb

 

应答模式：

 

RabbitMQ没有超时概念，只有消费者挂掉时，rabbitMq才会重新投递；

 

自动应答：均摊消费，不在乎消费者对消息处理是否成功，都会告诉队列删除该消息，如果处理消息失败情况下，需要实现自动补偿；

 

手动应答：消费者处理完业务逻辑，手动返回ack通知，告诉队列服务器是否删除该消息；

 

手动应答的区别：设置应答模式为false,然后在监听方法里面手动应答消费消息；

 

消息转发机制是平均分配，所有的奇数给一个消费者，偶数给另一个消费者；

 

解放方法：

通过设置channel。BasicQos(1)；这样告诉rabbitmq不要在同一时间给一个消费者超过一条信息。

 

生产者：

 

邮件消费者：

 

短信消费:

 

验证结果：

 

删除队列信息：

 

如果rabbitMq服务器宕机了，消失会丢失吗？

rabbitMQ服务器支持消息持久化机制，会把消息持久化在硬盘上，需要在代码中为true:

 

 

AMQP事务机制：

 

如果消息发送之后，代码报异常，则服务器可以收到消息，但是代码报异常；

利用amqp事务机制处理异常；报异常之后事务回滚；

处理生产者异常：

 

RabbitMQ解决注册发送消息思路：

 

创建两个项目：1生产者，2消费者（邮件消费者，短信消费者）

 

一个项目中可以有多个消费者，生产者；

 

 

消息重试机制

 

在消费端业务逻辑出现异常，这时候应该使用消息重试机制处理；

 

如何合适选择重试机制：

情况一、消费者获取到消息后，调用第三方接口，但是接口展示无法访问，需要重试机制；

情况二、消费者获取到消息后，抛出数据转换异常，不需要重试机制，需要重新发布解决；

应该采用日志记录+定时任务job健康检查+人工进行补偿

 

rabbit默认情况下，如果消费者程序出现异常，会自动实现补偿机制（重试机制）

 

底层使用AOP进行拦截，如果程序没有抛出异常，自动提交事务；

如果aop使用异常通知拦截获取异常信息的话，自动实现补偿机制，该消息会一直缓存到rabbitmq服务器端存放；

 

案例：

 

默认情况下，重试机制5秒重试一次

 

修改方法：

 

消息幂等性，重复消费问题；

 

产生原因：网络延迟传输中，消费出现异常或者消息延迟消费，会造成mq进行重试机制，在重试过程中，可能会造成重复消费；

 

解决方法：

1. 使用全局messageID判断消费方使用同一个，解决幂等性。
2. 或者使用业务逻辑保证唯一（比如订单ID）

 

思路：

 

 

开启手动应答模式：

 

死信队列：

 

产生的原因：

1. 消息被拒绝
2. 消息TTL过期
3. 队列到达最大长度（队列已满）

在定义业务队列的时候，可以考虑指定一个死信交换机，并绑定一个死信队列；当消息变成死信时，该消息就会被发送到死信队列上，这样就方便我们查看消息失败的原因了。

 

Rabbitmq解决分布式事务原理：采用最终一致性

 

需要保证三大要素：

1. 确保生产者一定要将数据投递到mq服务器中（采用mq消息确认机制）
2. MQ消费者消费能够正确消费信息，采用手动ack模式（注意重试幂等性问题）
3. 如何保证第一个事务先执行，采用补偿机制，在创建一个补偿消费者进行监听，如果订单没有创建成功，进行补单。

 

开源代码路径：https://gitee.com/DaiMaLvXingZhe/rabbitMQ