rabbitmq细节说明与效率（三）_rabbitmq性能

---

一、MQ说明

1.1、MQ种类：

1. ActiveMQ
   a.优点：单机吞吐量万级，时效性 ms 级，可用性高，基于主从架构实现高可用性，消息可靠性较低的概率丢失数据
   
   b.缺点:官方社区现在对 ActiveMQ 5.x 维护越来越少，高吞吐量场景较少使用。
   
   

2. Kafka
   a.大数据的杀手锏，谈到大数据领域内的消息传输，则绕不开 Kafka，这款为大数据而生的消息中间件，以其百万级 TPS 的吞吐量名声大噪，迅速成为大数据领域的宠儿，在数据采集、传输、存储的过程中发挥着举足轻重的作用。
   
   b.优点: 性能卓越，单机写入 TPS 约在百万条/秒，最大的优点，就是吞吐量高。时效性 ms 级可用性非常高。
   
   c.kafka 是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用,消费者采用 Pull 方式获取消息, 消息有序, 通过控制能够保证所有消息被消费且仅被消费一次;
   
   d.有优秀的第三方Kafka Web 管理界面 Kafka-Manager；
   
   e.在日志领域比较成熟，被多家公司和多个开源项目使用；功能支持：功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用
   
   d.缺点：Kafka 单机超过 64 个队列/分区，Load 会发生明显的飙高现象，队列越多，load 越高，发送消息响应时间变长，使用短轮询方式，实时性取决于轮询间隔时间，消费失败不支持重试；
   
   e.支持消息顺序，但是一台代理宕机后，就会产生消息乱序，社区更新较慢；
   
   

3. RocketMQ
   a.RocketMQ 出自阿里巴巴的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进。
   
   b.被阿里巴巴广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog 分发等场景。
   
   c.优点:单机吞吐量十万级,可用性非常高，分布式架构,消息可以做到 0 丢失,MQ 功能较为完善，还是分布式的，扩展性好,支持 10 亿级别的消息堆积，不会因为堆积导致性能下降,源码是 java 我们可以自己阅读源码，定制自己公司的 MQ
   
   d.缺点：支持的客户端语言不多，目前是 java 及 c++，其中 c++不成熟；社区活跃度一般,没有在 MQ核心中去实现 JMS 等接口,有些系统要迁移需要修改大量代码
   
   

4. RabbitMQ
   a.2007 年发布，是一个在 AMQP(高级消息队列协议)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。
   
   b.优点:由于 erlang 语言的高并发特性，性能较好；吞吐量到万级，MQ 功能比较完备,健壮、稳定、易用、跨平台、支持多种语言 如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持 AJAX 文档齐全；
   
   c.开源提供的管理界面非常棒，用起来很好用,社区活跃度高；更新频率相当高
   
   d.缺点：商业版需要收费,学习成本较搞
   
   e. 官网：https://www.rabbitmq.com/news.html
   
   

1.2、MQ选择：

1. Kafka
Kafka 主要特点是基于 Pull 的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输，适合产生大量数据的互联网服务的数据收集业务。
大型公司建议可以选用，如果有日志采集功能，肯定是首选 kafka 了。

2. RocketMQ
天生为金融互联网领域而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况。
RoketMQ 在稳定性上可能更值得信赖，这些业务场景在阿里双 11 已经经历了多次考验，如果你的业务有上述并发场景，建议可以选择 RocketMQ。

3. RabbitMQ
结合 erlang 语言本身的并发优势，性能好时效性微秒级，社区活跃度也比较高，管理界面用起来十分方便，如果你的数据量没有那么大，中小型公司优先选择功能比较完备的 RabbitMQ。

---

二、rabbitmq3种发送消息的策略和模式

1.1、策略

1. 轮训分发消息
2. 不公平分发
3. 批量发送，异步回调模式

推荐使用第三种，发送消息时，给消息附上唯一的id，用于消息的幂等性，避免重复消费

轮训分发消息
就是你一个消息，我一个消息，公平分发，但是因为机器性能的差异，这样就无法充分利于其性能

不公平分发
设置：channel.basicQos(1)，在设定其预取值
这个就相当于权重，性能好就多发点，性能不好就少发一点

批量发送，异步回调模式
这个就是生产者主管发送消息，信息会在信道里面有个自增的tag，开启应答模式，根据消息的tag进行签收和拒签，这样就能知道消费是否发送成功。
最好加上数据库的记录保证消息发送的万无一失

1.2、模式

1. 单独发布消息
2. 批量发布消息，没有使用回调
3. 批量发布消息，异步回调

优缺点：
单独发布消息：同步等待确认，简单，但吞吐量非常有限。

批量发布消息，没有使用回调
批量同步等待确认，简单，合理的吞吐量，一旦出现问题但很难推断出是那条消息出现了问题。

批量发布消息，异步回调
最佳性能和资源使用，在出现错误的情况下可以很好地控制，但是实现起来稍微难些

---

三、rabbitmq信道的方法

rabbitmq中的channel很重要，我们称其为信道，他是在一条长连接中

信道的方法：

1. .Channel.basicAck(用于肯定确认) 表示RabbitMQ 已知道该消息并且成功的处理消息，可以将其丢弃了
2. Channel.basicNack(用于否定确认)
3. Channel.basicReject(用于否定确认)比与 Channel.basicNack 相比少一个参数
4. channel.basicQos(1) 设置不公平分发
5. channel.confirmSelect() 开启确认发布模式
6. channel.basicPublish() 消息的发布

---

四、死信队列和延迟队列

1.1、队列的特点

队列的特性就是先进先出

1.2、死信队列

死信，顾名思义就是无法被消费的消息

1.1.1、应用场景:

a.为了保证订单业务的消息数据不丢失，需要使用到 RabbitMQ 的死信队列机制.
b.当消息消费发生异常时，将消息投入死信队列中
c.还有比如说: 用户在商城下单成功并点击去支付后在指定时间未支付时自动失效

1.1.2、死信的来源

1. 消息 TTL 过期
2. 队列达到最大长度(队列满了，无法再添加数据到 mq 中)
3. 消息被拒绝(basic.reject 或 basic.nack)并且 requeue=false

1.3、延迟队列

1. 延时队列,队列内部是有序的
2. 最重要的特性就体现在它的延时属性上，延时队列中的元素是希望在指定时间到了以后或之前取出和处理
3. 简单来说，延时队列就是用来存放需要在指定时间被处理的元素的队列。

1.1.1、延迟队列使用场景

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

1.4、消息设置过期，还是队列设置

分析：

1. 在消息上设置过期时间的话，这样会灵活
2. 在队列设置消息的存活时间，缺点就是队列一点生成，其特性就无法修改，如果要修改的话，就需要删除队列，重新创建。这样不灵活
3. 这个根据具体场景具体分析

1.1、队列的先进先出的影响

假设第一条消息的过期时间是1分钟。第2条消息的过期时间是5秒。
因为队列的特性，先进先出，这样会导致，第2条信息之间虽然到了，可以消费了但是出不去，因为第一条信息，还没过期，堵住了。

怎么解决这个问题：

方案：引入Rabbitmq 插件实现延迟队列

1. 在官网上下载 https://www.rabbitmq.com/community-plugins.html

原理就是转移至交换机，设置一个类型为 "x-delayed-type" 的交换机>有交换机还决定

1.5、归纳

1. 延时队列在需要延时处理的场景下非常有用，使用 RabbitMQ 来实现延时队列可以很好的利用RabbitMQ 的特性，
2. 如：消息可靠发送、消息可靠投递、死信队列来保障消息至少被消费一次以及未被正确处理的消息不会被丢弃。
3. 另外，通过 RabbitMQ 集群的特性，可以很好的解决单点故障问题，不会因为单个节点挂掉导致延时队列不可用或者消息丢失。

当然，延时队列还有很多其它选择，
比如利用 Java 的 DelayQueue，
利用 Redis 的 zset，
利用 Quartz或者
利用
kafka 的时间轮，
这些方式各有特点,看需要适用的场景

---

五、消息兜底方案

也是回退消息

1.1、Mandatory 参数

1. 在仅开启了生产者确认机制的情况下，交换机接收到消息后，会直接给消息生产者发送确认消息，如果发现该消息不可路由，那么消息会被直接丢弃，此时生产者是不知道消息被丢弃这个事件的。
2. 那么如何让无法被路由的消息帮我想办法处理一下？最起码通知我一声，我好自己处理啊。
3. 通过设置 mandatory 参数可以在当消息传递过程中不可达目的地时将消息返回给生产者。
4. 设置 mandatory 参数会增加生产者的复杂性

1.1.1、问题所在

1. 有了 mandatory 参数和回退消息，我们获得了对无法投递消息的感知能力，有机会在生产者的消息无法被投递时发现并处理。
2. 但有时候，我们并不知道该如何处理这些无法路由的消息，最多打个日志，然后触发报警，再来手动处理。
3. 而通过日志来处理这些无法路由的消息是很不优雅的做法，特别是当生产者所在的服务有多台机器的时候，手动复制日志会更加麻烦而且容易出错。
4. 而且设置 mandatory 参数会增加生产者的复杂性，需要添加处理这些被退回的消息的逻辑。如果既不想丢失消息，又不想增加生产者的复杂性，该怎么做呢？

方法：使用备份交换机

可以为队列设置死信交换机来存储那些处理失败的消息，可是这些不可路由消息根本没有机会进入到队列，因此无法使用死信队列来保存消息。
在RabbitMQ 中，有一种备份交换机的机制存在，可以很好的应对这个问题。

1.2、备份交换机

什么是备份交换机？

1. 备份交换机可以理解为 RabbitMQ 中交换机的“备胎”，当我们为某一个交换机声明一个对应的备份交换机时，就是为它创建一个备胎，当交换机接收到一条不可路由消息时，将会把这条消息转发到备份交换机中，由备份交换机来进行转发和处理
2. 通常备份交换机的类型为 Fanout ，这样就能把所有消息都投递到与其绑定的队列中，然后我们在备份交换机下绑定一个队列，这样所有那些原交换机无法被路由的消息，就会都进入这个队列了。
3. 当然，我们还可以建立一个报警队列，用独立的消费者来进行监测和报警。

示例：交换机和备份交换机绑定

@Bean("confirmExchange")
 public DirectExchange confirmExchange(){
 ExchangeBuilder exchangeBuilder =
 ExchangeBuilder.directExchange(CONFIRM_EXCHANGE_NAME)
 .durable(true)
//设置该交换机的备份交换机
.withArgument("alternate-exchange", BACKUP_EXCHANGE_NAME);
 return (DirectExchange)exchangeBuilder.build();
 }
1
2
3
4
5
6
7
8
9

---

六、优先级队列

1.1、使用场景

1. 在我们系统中有一个订单催付的场景，我们的客户在天猫下的订单,淘宝会及时将订单推送给我们，如果在用户设定的时间内未付款那么就会给用户推送一条短信提醒
2. 很简单的一个功能对吧但是，tmall商家对我们来说，肯定是要分大客户和小客户的对吧，比如像苹果，小米这样大商家一年起码能给我们创造很大的利润
3. 所以理应当然，大客户的订单必须得到优先处理，如果后端系统是使用 redis 来存放的定时轮询，大家都知道 redis 只能用 List 做一个简简单单的消息队列，并不能实现一个优先级的场景，
4. 所以订单量大了后采用 RabbitMQ 进行改造和优化,如果发现是大客户的订单给一个**相对比较高的优先级**
5. 否则就是默认优先级。

1.2、使用

控制台添加如图：

代码实现-- 2部分 队列+消息

== 队列==

Map<String, Object> params = new HashMap();
//10是我们自己设置的，就好像下标一样1-10.消息过来对其进行重新排序
params.put("x-max-priority", 10);
channel.queueDeclare("hello", true, false, false, params);
1
2
3
4

消息中代码添加优先级

//有这个熟悉的数据会进行优先级排序，priority(5)不能大于队列设置的书如上面的10
AMQP.BasicProperties properties = new AMQP.BasicProperties().builder().priority(5).build();
1
2

---

七、惰性队列

1.1、场景

1. RabbitMQ 从 3.6.0 版本开始引入了惰性队列的概念。
2. 惰性队列会尽可能的将消息存入磁盘中，而在消费者消费到相应的消息时才会被加载到内存中
3. 它的一个重要的设计目标是能够支持更长的队列，即支持更多的消息存储。
4. 当消费者由于各种各样的原因(比如消费者下线、宕机亦或者是由于维护而关闭等)而致使长时间内不能消费消息造成堆积时，惰性队列就很有必要了。
5. 默认情况下，当生产者将消息发送到 RabbitMQ 的时候，队列中的消息会尽可能的存储在内存之中，这样可以更加快速的将消息发送给消费者。
6. 即使是持久化的消息，在被写入磁盘的同时也会在内存中驻留一份备份。当 RabbitMQ 需要释放内存的时候，会将内存中的消息换页至磁盘中，这个操作会耗费较长的时间，也会阻塞队列的操作，进而无法接收新的消息。
7. 虽然 RabbitMQ 的开发者们一直在升级相关的算法，但是效果始终不太理想，尤其是在消息量特别大的时候。

1.2、两种模式

1. 队列具备两种模式：default 和 lazy。
2. 默认的为 default 模式，在 3.6.0 之前的版本无需做任何变更。
3. lazy模式即为惰性队列的模式，可以通过调用channel.queueDeclare 方法的时候在参数中设置，也可以通过Policy 的方式设置，如果一个队列同时使用这两种方式设置的话，那么 Policy 的方式具备更高的优先级。
4. 如果要通过声明的方式改变已有队列的模式的话，那么只能先删除队列，然后再重新声明一个新的。

示例

Map<String, Object> args = new HashMap<String, Object>();
args.put("x-queue-mode", "lazy");
channel.queueDeclare("myqueue", false, false, false, args);
1
2
3

1.3、内存开销对比

在发送 1 百万条消息，每条消息大概占 1KB 的情况下：

1. 普通队列占用内存是 1.2GB，
2. 而惰性队列仅仅占用 1.5MB

---

第一篇：rabbitMQ介绍与安装说明（一）

第二篇：springboot整合rabbitmq和延时队列(二)