原文链接:要做重试机制,就只能选择 DelayQueue ?其实 RabbitMQ 它上它也行!

一、场景

最近研发一个新功能,后台天气预警:后台启动一条线程,定时调用天气预警 API,查询现有城市的相关天气预警信息,如果发现有预警或取消预警的信息,给指定预警部门配置的相关人员发送短信;而如果第一次发送失败,我们需要隔几分钟再重新发送,最多可以重发5次。

二、技术选型

1、JDK 原生 DelayQueue:

重试机制最简单的就是直接利用 JDK 提供的 DelayQyeye,而 DelayQueue 里面存放的任务需要是实现 Delay 接口的实现类,需要重写 getDelay 方法和 compareTo 方法。getDelay 方法主要用做判断任务是否到期要出队列,而 compareTo 方法主要用做入队时任务的判断,过期时间短的任务应放在队列的前面,通过这个方法,我们可以知道,DelayQueue 的底层是利用 PriorityQueue 实现的。

下面上一个 DelayQueue 的简单的使用例子:

/**
* @author Howinfun
* @desc
* @date 2020/8/1
*/
public class TestDelayQueue { public static void main(String[] args) throws InterruptedException {
DelayQueue<UserMsg> delayQueue = new DelayQueue();
UserMsg userMsg1 = new UserMsg(1,"15627272727","你好,下单成功1",5, TimeUnit.SECONDS);
UserMsg userMsg2 = new UserMsg(2,"15627272727","你好,下单成功2",3, TimeUnit.SECONDS);
UserMsg userMsg3 = new UserMsg(3,"15627272727","你好,下单成功3",4, TimeUnit.SECONDS);
UserMsg userMsg4 = new UserMsg(4,"15627272727","你好,下单成功4",6, TimeUnit.SECONDS);
UserMsg userMsg5 = new UserMsg(5,"15627272727","你好,下单成功5",2, TimeUnit.SECONDS);
delayQueue.add(userMsg1);
delayQueue.put(userMsg2);
delayQueue.put(userMsg3);
delayQueue.put(userMsg4);
delayQueue.put(userMsg5); for (int i=0;i<5;i++){
// take方法会一直阻塞,直到有任务
UserMsg userMsg = delayQueue.take();
System.out.println(userMsg.toString());
}
}
}
@Data
@ToString
public class UserMsg implements Delayed { private int id;
private String phone;
private String msg;
private int failCount;
// 过期时间
private long time; public UserMsg(int id,String phone,String msg,long time,TimeUnit unit){
this.id = id;
this.phone = phone;
this.msg = msg;
this.time = System.currentTimeMillis() + (time > 0 ? unit.toMillis(time) : 0);
this.failCount = 0;
} @Override
public long getDelay(TimeUnit unit) {
// 和当前时间比较,判断是否到期
return this.time - System.currentTimeMillis();
} @Override
public int compareTo(Delayed o) {
// 入队时需要判断任务放到队列的哪个位置,过期时间短的放在前面
UserMsg item = (UserMsg) o;
long diff = this.time - item.time;
if (diff <= 0) {
return -1;
}else {
return 1;
}
}
}

扩展点:PriorityQueue的优化点

讲到 PriorityQueue,有一个优化点我是觉得挺有意思的:它的 take() 方法,是会一直阻塞直到有任务过期出队列。它里面主要是利用 for 死循环去读取队列的头节点,判断头节点是否为空,如果为空,则直接调用 Condition#await() 进入阻塞状态;而如果队列的头节点不为空,但是任务还未过期,则会判断之前是否有线程(leader)尝试获取过期任务了,如果有的话就调用 Condition#await() 方法,否则就继续在死循环里面继续尝试获取过期任务。这样的话,避免所有尝试获取过期任务的线程一直在死循环,这样能让多余的线程进入阻塞状态,从而释放系统资源。当然了,只要 leader 拿到过期任务了,那么就会判断队列是否还有任务,如果有则调用 Condition#signal() 唤醒等待状态的线程们。我们可以看看源码:

public E take() throws InterruptedException {
final ReentrantLock lock = this.lock;
lock.lockInterruptibly();
try {
for (;;) {
E first = q.peek();
if (first == null)
available.await();
else {
long delay = first.getDelay(NANOSECONDS);
if (delay <= 0)
return q.poll();
first = null; // don't retain ref while waiting
if (leader != null)
available.await();
else {
Thread thisThread = Thread.currentThread();
leader = thisThread;
try {
available.awaitNanos(delay);
} finally {
if (leader == thisThread)
leader = null;
}
}
}
}
} finally {
if (leader == null && q.peek() != null)
available.signal();
lock.unlock();
}
}

2、消息中间件 RabbitMQ :

可能很多同学看到这个标题后会有点疑惑,消息中间件还能做重发机制?其实一开始我都没想到,关于 RabbitMQ 我也只是简单地学了他的六大使用模式,其他的业务场景还没深究。然后有一天和我的一个好同事聊了一下这个重试机制,他就说了 RabbitMQ 的死信队列可以做到,然后我自己就去研究一下。

他的主要原理是利用消息的 ttl + 死信队列。当短信发送失败时,封装一个消息往指定的业务 queue 发送,并且指定消息的 ttl,当然了,还需要为业务 queue 指定死信队列。当消息过期后,会从业务 queue 转到死信队列中,所以说,我们只需要监听死信队列,拉取其中的消息进行消费,这样就能做到重试了。

这两个怎么选?

使用原生的 DelayQueue 会更加方便点,因为只需要自定义类实现 Delay 接口,启动线程阻塞获取过期任务即可。可是对于想监控这个 DelayQueue 里面任务的情况,可能就要自己写接口来获取了,并且在微服务中,通常一个服务模块有多个实例,这样子的话,统一管理还有监控就更麻烦了。

所以我们可以考虑使用 RabbitMQ 来完成。不但可以统一处理重试机制,并且 RabbitMQ 还提供了自己的后台管理系统,这样监控起来也很方便。

三、RabbitMQ 如何利用消息 ttl 和死信队列做重试机制

下面是基于 spring-boot-starter-amqp 做的。

1、声明业务/死信队列相关组件: Exchange、Routing Key、Queue

第一步还是比较简单的,主要是创建对应的交换器、队列和路由键,特别要注意的是,在创建业务队列时,需要为他设置死信队列的相关信息,代码如下:

@Configuration
public class RabbitMQConfig { /**
* 业务 queue
*/
public static final String BUSINESS_QUEUE_NAME = "business.queue";
/**
* 业务 exchange
*/
public static final String BUSINESS_EXCHANGE_NAME = "business.exchange";
/**
* 业务 routing key
*/
public static final String BUSINESS_QUEUE_ROUTING_KEY = "business.routing.key";
/**
* 死信队列 exchange
*/
public static final String DEAD_LETTER_EXCHANGE_NAME = "dead.letter.exchange";
/**
* 死信队列 queue
*/
public static final String DEAD_LETTER_QUEUE_NAME = "dead.letter.queue";
/**
* 死信队列 routing key
*/
public static final String DEAD_LETTER_QUEUE_ROUTING_KEY = "dead.letter.routing.key"; /**
* 声明业务交换器
* @return
*/
@Bean("businessExchange")
public DirectExchange businessExchange(){
return new DirectExchange(BUSINESS_EXCHANGE_NAME);
} /**
* 声明业务队列
* @return
*/
@Bean("businessQueue")
public Queue businessQueue(){
Map<String, Object> args = new HashMap<>(3);
// 这里声明当前队列绑定的死信交换机
args.put("x-dead-letter-exchange", DEAD_LETTER_EXCHANGE_NAME);
// 这里声明当前队列的死信路由key
args.put("x-dead-letter-routing-key", DEAD_LETTER_QUEUE_ROUTING_KEY);
return QueueBuilder.durable(BUSINESS_QUEUE_NAME).withArguments(args).build();
} /**
* 声明业务队列绑定业务交换器,绑定路由键
* @param queue
* @param exchange
* @return
*/
@Bean
public Binding businessBinding(@Qualifier("businessQueue") Queue queue,
@Qualifier("businessExchange") DirectExchange exchange){
return BindingBuilder.bind(queue).to(exchange).with(BUSINESS_QUEUE_ROUTING_KEY);
} /**
* 声明死信交换器
* @return
*/
@Bean("deadLetterExchange")
public DirectExchange deadLetterExchange(){
return new DirectExchange(DEAD_LETTER_EXCHANGE_NAME);
} /**
* 声明死信队列
*/
@Bean("deadLetterQueue")
public Queue deadLetterQueue(){
return QueueBuilder.durable(DEAD_LETTER_QUEUE_NAME).build();
} /**
* 声明死信队列绑定死信交换器,绑定路由键
* @param queue
* @param exchange
* @return
*/
@Bean
public Binding deadLetterBinding(@Qualifier("deadLetterQueue") Queue queue,
@Qualifier("deadLetterExchange") DirectExchange exchange){
return BindingBuilder.bind(queue).to(exchange).with(DEAD_LETTER_QUEUE_ROUTING_KEY);
}
}

2、模拟业务处理失败,发送需要重试的短信:

代码如下:

UserMsg userMsg1 = new UserMsg(1,"15627236666","你好,麻烦充值",1);
UserMsg userMsg2 = new UserMsg(2,"15627236667","你好,麻烦支付",1);
UserMsg userMsg3 = new UserMsg(3,"15627236668","你好,麻烦下单",1);
String msgJson1 = JSON.toJSONString(userMsg1);
String msgJson2 = JSON.toJSONString(userMsg2);
String msgJson3 = JSON.toJSONString(userMsg3); userMsgMapper.insert(userMsg1);
userMsgMapper.insert(userMsg2);
userMsgMapper.insert(userMsg3); MessagePostProcessor messagePostProcessor = message -> {
// 如果配置了 params.put("x-message-ttl", 5 * 1000); 那么这一句也可以省略,具体根据业务需要是声明 Queue 的时候就指定好延迟时间还是在发送自己控制时间
message.getMessageProperties().setExpiration(1 * 1000 * 60 + "");
return message;
};
// 往业务 Queue 发送需要重试的短信
rabbitTemplate.convertAndSend(RabbitMQConfig.BUSINESS_EXCHANGE_NAME,RabbitMQConfig.BUSINESS_QUEUE_ROUTING_KEY,msgJson1,messagePostProcessor);
rabbitTemplate.convertAndSend(RabbitMQConfig.BUSINESS_EXCHANGE_NAME,RabbitMQConfig.BUSINESS_QUEUE_ROUTING_KEY,msgJson2,messagePostProcessor);
rabbitTemplate.convertAndSend(RabbitMQConfig.BUSINESS_EXCHANGE_NAME,RabbitMQConfig.BUSINESS_QUEUE_ROUTING_KEY,msgJson3,messagePostProcessor);

我们可以看到,在发送消息时,会利用 MessagePostProcessor 来完成给消息添加 ttl。

3、监听死信队列,消费消息:

这是最重要的一步,我们需要监听死信队列,一旦有消息,证明有任务需要重试了,我们只需要拉取下来然后消费即可。

这里需要注意的有一个点:为了避免出现消息丢失的情况,我们需要开启手动 ack,然后配合 fetch = 1,保证客户端每次只能拉取一个消息,当客户端消费完此消息后,需要手动调用 channel#basicAck() 方法去确认此消息已经被消费了。

下面是相关的配置:

# 开启手动 ack
spring.rabbitmq.listener.simple.acknowledge-mode=manual
# 设置 false,消息才能进入死信队列
spring.rabbitmq.listener.simple.default-requeue-rejected=false
# 消费者每次只读取一个消息
spring.rabbitmq.listener.simple.prefetch=1

接着我们看看如何监听死信队列,先上代码:

//@RabbitListener(queues = {RabbitMQConfig.DEAD_LETTER_QUEUE_NAME})
@Component
public class DeadLetterQueueListener { @Resource
private RabbitTemplate rabbitTemplate;
@Resource
private UserMsgMapper userMsgMapper; @RabbitListener(queues = {RabbitMQConfig.DEAD_LETTER_QUEUE_NAME})
@RabbitHandler
public void processHandler(String msg, Channel channel, Message message) throws IOException { try {
UserMsg userMsg = JSON.parseObject(new String(message.getBody()), UserMsg.class);
// 模拟发送短信
int num = new Random().nextInt(10);
if (num >5){
// 发送成功
// 更新数据库记录
System.out.println("消息【" + userMsg.getId() + "】发送成功,失败次数:" + userMsg.getFailCount());
userMsgMapper.update(userMsg);
}else {
// 重新发到业务队列中
int failCount = userMsg.getFailCount()+1;
if (failCount > 5){
System.out.println("消息【"+ userMsg.getId() +"】发送次数已到上线");
userMsgMapper.update(userMsg);
}else {
userMsg.setFailCount(failCount);
String msgJson = JSON.toJSONString(userMsg);
System.out.println("消息【"+ userMsg.getId() +"】发送失败,失败次数为:"+ userMsg.getFailCount());
userMsgMapper.update(userMsg);
MessagePostProcessor messagePostProcessor = message2 -> {
// 如果配置了 params.put("x-message-ttl", 5 * 1000); 那么这一句也可以省略,具体根据业务需要是声明 Queue 的时候就指定好延迟时间还是在发送自己控制时间
message2.getMessageProperties().setExpiration(1 * 1000 * 60 + "");
return message2;
};
rabbitTemplate.convertAndSend(RabbitMQConfig.BUSINESS_EXCHANGE_NAME,RabbitMQConfig.BUSINESS_QUEUE_ROUTING_KEY,msgJson,messagePostProcessor);
}
}
channel.basicAck(message.getMessageProperties().getDeliveryTag(),false);
} catch (Exception e) {
System.err.println("消息即将再次返回队列处理...");
channel.basicNack(message.getMessageProperties().getDeliveryTag(), false, true);
}
}
}

其实非常简单,首先在 @RabbitListener 注解中加上自己需要监听的死信队列,我们可以发现这个注解可加载类上,也可以加载处理消息的方法上;当然了,还需要在消费消息的方法上加上注解 @RabbitHandler。

在消费消息的逻辑中,如果是业务处理成功了,也就是重试成功了,此时不需做其他操作;而如果重试失败了,需要重新发送一个消息到业务 Queue,表示又要重试一次。最后,我们需要调用 channel#basicAck() 表示消息消费成功~

在给业务 Queue 发送消息之前,我们记得给消息设置一下过期时间,还是利用 MessagePostProcessor 来完成。

四、最后

到此基本就结束了。

但是我们还有一个点要注意:就是如果我们使用 RabbitMQ 来做重试机制,我们一定要保证 RabbitMQ 的高可用,这时候我们一般推荐使用镜像集群模式,而不是普通集群模式。因为普通集群模式中,每个实例都只是保存其他实例中 queue 的元数据,只要一个实例宕机的,它所负责的 queue 都不能再被使用了。而镜像集群模式中,每个实例都会保存所有 queue ,这样能保证数据 100% 的不丢失!当然了,如果不追求高并发,使用主备模式也还是可以滴~

大家如果对上面的例子还感兴趣,可到我的 github 看看:死信队列完成重试机制

要做重试机制,就只能选择 DelayQueue ?其实 RabbitMQ 它上它也行!的更多相关文章

  1. ENode 1.0 - 消息的重试机制的设计思路

    项目开源地址:https://github.com/tangxuehua/enode 上一篇文章,简单介绍了enode框架中消息队列的设计思路,本文介绍一下enode框架中关系消息的重试机制的设计思路 ...

  2. Selenium 定位元素原理,基本API,显示等待,隐式等待,重试机制等等

    Selenium  如何定位动态元素: 测试的时候会遇到元素每次变动的情况,例如: <div id="btn-attention_2030295">...</di ...

  3. SpringCloud | FeignClient和Ribbon重试机制区别与联系

    在spring cloud体系项目中,引入的重试机制保证了高可用的同时,也会带来一些其它的问题,如幂等操作或一些没必要的重试. 今天就来分别分析一下 FeignClient 和 Ribbon 重试机制 ...

  4. spring-retry 重试机制

    业务场景 应用中需要实现一个功能: 需要将数据上传到远程存储服务,同时在返回处理成功情况下做其他操作.这个功能不复杂,分为两个步骤:第一步调用远程的Rest服务逻辑包装给处理方法返回处理结果:第二步拿 ...

  5. [转载]rabbitmq可靠发送的自动重试机制

    转载地址http://www.jianshu.com/p/6579e48d18ae http://www.jianshu.com/p/4112d78a8753 接这篇 在上文中,主要实现了可靠模式的c ...

  6. 【Dubbo 源码解析】07_Dubbo 重试机制

    Dubbo 重试机制 通过前面 Dubbo 服务发现&引用 的分析,我们知道,Dubbo 的重试机制是通过 com.alibaba.dubbo.rpc.cluster.support.Fail ...

  7. Rocket重试机制,消息模式,刷盘方式

    一.Consumer 批量消费(推模式) 可以通过 consumer.setConsumeMessageBatchMaxSize(10);//每次拉取10条 这里需要分为2种情况 Consumer端先 ...

  8. Spring Cloud重试机制与各组件的重试总结

    SpringCloud重试机制配置 首先声明一点,这里的重试并不是报错以后的重试,而是负载均衡客户端发现远程请求实例不可到达后,去重试其他实例. ? 1 2 3 4 5 6 7 8 @Bean @Lo ...

  9. Dubbo超时重试机制带来的数据重复问题

    Dubbo的超时重试机制为服务容错.服务稳定提供了比较好的框架支持,但是在一些比较特殊的网络环境下(网络传输慢,并发多)可能 由于服务响应慢,Dubbo自身的超时重试机制(服务端的处理时间超过了设定的 ...

  10. rabbitmq 不发送ack消息如何处理:rabbitmq可靠发送的自动重试机制

    转载地址:http://www.jianshu.com/p/6579e48d18ae http://www.jianshu.com/p/4112d78a8753 接这篇 在上文中,主要实现了可靠模式的 ...

随机推荐

  1. 经验分享:CSS浮动(float,clear)通俗讲解

    很早以前就接触过CSS,但对于浮动始终非常迷惑,可能是自身理解能力差,也可能是没能遇到一篇通俗的教程. 前些天小菜终于搞懂了浮动的基本原理,迫不及待的分享给大家. 写在前面的话: 由于CSS内容比较多 ...

  2. 基情四射的两个css样式

    自定义blog样式时,代码段的line-height继承样式post的line-height,间隔太大了,决定再减小点,css都玩了几年了,感觉中这是很容易的事情.然后,就悲剧了好久,原先自定义样式表 ...

  3. js 神代码

    eval(z='p="<"+"pre>"/* ,.oq#+ ,._, */;for(y in n="zw24l6k\ 4e3t4jnt4q ...

  4. Android 8.0 的部分坑及对应解决方法

    虽然 Android 9.0 都已经面世了,本篇文章写的有点迟了. 但是迟到好过不到,因此基于此这边还是记录一下项目中遇到的 Android 8.0 的坑及对应解决方法. 每次系统升级,虽然系统功能更 ...

  5. emmet-前端开发神器的几种写法

    *常用:类: .  ,id:  # div.a+div#a <div class="a"></div> <div id="a"&g ...

  6. Asp.NET调用有道翻译API

    调用有道API进行翻译,如图: HTML: <%@ Page Language="C#" AutoEventWireup="true" CodeFile= ...

  7. P3110 [USACO14DEC]驮运Piggy Back

    传送门 做过次短路后,再来做这题感觉轻松不少. 这题看着就像最短路模板题. 思路: 虽说题目看起来比较水,但是码起来还是有点难度的.(对我这个蒟蒻来说) 这道题,跟"路障"一题差不 ...

  8. CSAPP lab2 二进制拆弹 binary bombs phase_5

    给出对应于7个阶段的7篇博客 phase_1  https://www.cnblogs.com/wkfvawl/p/10632044.htmlphase_2  https://www.cnblogs. ...

  9. 助你简化开发的 jQuery 插件

    Vanity Toolset vanity toolset是一套方便的UI工具集,可以帮助你快速的搭建幻灯,聚光灯,占位,收放相关的UI,它完成了大部分的UI功能,你只需要花费很少时间就可以构建一个完 ...

  10. BitMap算法详解

    所谓的BitMap就是用一个bit位来标记某个元素所对应的value,而key即是该元素,由于BitMap使用了bit位来存储数据,因此可以大大节省存储空间. 基本思想: 这此我用一个简单的例子来详细 ...