RabbitMQ实现重试次数方法一-SpringRetry

一般来说 RabbitMQ 有个方法 channel.basicNack() 能够让消息回到队列中，这样可以实现重试。但是这样没有明确重试次数，如果当前的消息一直重试的话，则后面的消息就会堆积起来，导致后面的消息无法消费。这是一个致命的缺点。因此这就需要设置重试次数来解决这种问题。下面提供几种解决方案。

这一节介绍使用 spring-rabbit 自带的 retry 功能。

BackOffPolicy ：重试的回退策略，指以何种方式进行下一次重试（第一次重试后什么时候进行第二次重试），比如过了15秒后重试，随机时间重试。

RetryPolicy ：重试策略或条件，可以指定超时重试，一直重试，简单重试等。

MessageRecoverer ：消息回收类，当所有的重试次数都失败后，就会调用该类的 recover 方法

RetryTemplate ：组合了 BackOffPolicy ， RetryPolicy ， RetryListener ，执行重试步骤的具体类。

RetryOperationsInterceptor ：方法执行失败的拦截器类，拦截失败后交给 RertyTemplate 去执行重试。

SimpleMessageListenerContainer ：用于管理消费者。

RetryListener ：重试过程的监听器，第一次重试调用该类的 open ，每次重试不成功调用 onError ，最后一次重试调用 close 。

设置消息确认模式为 auto ， SpringBoot 环境添加以下配置。

配置 SimpleMessageListenerContainer ，并抛出异常重试。使用 simpleRabbitListenerContainerFactory 创建 SimpleMessageListenerContainer 有个好处就是在 application.properties 中对 SimpleMessageListenerContainer 的配置可以生效。比如配置 spring.rabbitmq.listener.simple.acknowledge-mode=auto 就可以直接生效。

方案1：

application.properties里面添加即可

spring.datasource.druid.break-after-acquire-failure=true

spring.datasource.druid.connection-error-retry-attempts=1

1

2

1

2

方案2：动态数据源解决方案

DruidDataSource druidDataSource=new DruidDataSource()

druidDataSource.setUrl(dbInfo.getUrl())

druidDataSource.setUsername(dbInfo.getUserName())

druidDataSource.setPassword(dbInfo.getPassword())

druidDataSource.setConnectionErrorRetryAttempts(1) //失败后重连次数

druidDataSource.setBreakAfterAcquireFailure(true)

1

2

3

4

5

6

1

2

3

4

5

6

完成了，只会试一次，不成功不会无限尝试

1、优点：1，方便解耦，简化开发：通过spring提供的IOC容器，我们可以将对象之间的依赖关系交由Spring进行控制，避免原编码所造成过度程序耦合。有了spring，用户不再为了单列模式类，属性文件解析等这些很底层的需求编写代码，可以专注于上层的应用的2，AOP编程的支持：通过spring提供的AOP功能方便进行面向切面的编程，许多不容易用传统OOP实现的功能可以通过AOP轻松应付.spring的AOP支持允许将一些通用任务如安全，事务，日志等进行集中式管理，从而提供了更好的复用3，声明事务的支持：在spring中，我们可以从单调烦闷的事务管理代码中解脱出来，通过声明方式灵活地进行事务的管理，提高开发效率和质量4，方便程序的测试：可以用非容器依赖编程方式进行几乎所有的测试工作，在spring里，测试不在是昂贵的 *** 作，而是随手课做的事情没列入spring对junit4支持，可以通过注解方便的测试spring程序5，方便集成各种框架：spring不排斥各种优秀的开源框架，相反，spring可以降低各种框架的使用难度，spring提供了对各种哟毓秀框架

2、缺点：-从应用层面来说暂时没有缺点-因为简化开发，如果需要深入给底层去了解就非常困难(上层使用的越简单，底层的封装就越复杂)-源码的缺点：由于spring大并且全(要集成很多框架，提供非常多的扩展点)代码非常庞大，对于学习源码具有一定困难

---