rabbitMq性能测试及消息丢失处理_rabbitmq 性能压测结果

参考：

https://blog.csdn.net/u012129558/article/details/82425276

 

一.RabbitMq性能测试

对项目中的RabbitMq进行测试，测试结果如下

可以看出，在同一个机器上，一个消费者，一个生产者，使用不同类型的exchange，速度很接近。

当有多个生产者和消费者去处理相同的数据时，速度会更快一点。

 
 

二.消息丢失处理

生产者 confirms ：

rabbitTemplate的发送流程是这样的：

1 发送数据并返回(不确认rabbitmq服务器已成功接收)

2 异步的接收从rabbitmq返回的ack确认信息

3 收到ack后调用confirmCallback函数

为了防止生产者发送的消息，刚发送一半，产生了网络抖动，就有可能到不了 RabbitMQ。所以生产者需要使用rabbitMq的确认机制。

 

同时需要在配置文件中开启ack

必须 rabbitTemplate.setMandatory(true)，不然当 发送到交换器成功，但是没有匹配的队列，不会触发 ReturnCallback 回调。而且 ReturnCallback 比 ConfirmCallback 先回调。

 

ReturnCallback 的触发条件：

开启publisher-returns，发送到交换器成功，但是没有匹配的队列会触发，这样消息也会丢失。

ConfirmCallback 的触发条件：

开启publisher-confirms，当消息发生到exchange成功时，ack为true。当发送exchange失败时，ack为false。

为了防止消息发送异常,我们需要在发送消息前，进行消息本地缓存。在ReturnCallback 中可以直接进行消息的重新发送。

如果ConfirmCallback中ack返回true，这里需要注意的是，当exchange没有找到匹配队列，ack也会返回true，说明消息发到exchange中成功，这个时候需要查看ReturnCallback 中有没有发生异常，如果消息正常投递，可以通过correlationData删除redis或者数据库中的本地消息，否则也需要做异常处理。

ack返回false。则需要做异常处理

 

 

消费者confirms:

RabbitMQ 默认使用的是自动的确认模式，在投递成功之前，如果消费者的 TCP 连接 或者 channel 关闭了，这条消息就会丢失。

为了防止重要的消息丢失，我们需要手动的进行确认。

1.首先，我们需要开启手动消息确认

 

2.在监听类中，使用刚刚配置的containerFactory

channel.basicAck：

代表消费者确认收到当前消息，语义上表示消费者成功处理了当前消息。

channel.basicNack：

代表消费者拒绝一条或者多条消息。basicNack 算是 basicReject 的一个扩展，因为 basicReject 不能一次拒绝多条消息。

channel.basicReject：

代表消费者拒绝这条消息，语义上表示消费者没有处理当前消息。

 

注意：

如果开启了消费者手动 ack 模式， 但是又没有调用手动确认方法 （比如：channel.basicAck）， 那问题就大了，RabbitMQ 会在当前 channel 上一直阻塞，等待消费者 ack 。

需要注意如果是自动重发的话,消费端需要做幂等或去重处理