现象：前端请求接口时候，后端接口无法正常响应结果，只有某个接口会出现这种情况，其他接口全部正常，该接口的响应提比较大，服务端报错如下：Caused by: org.apache.catalina.connector.ClientAbortException: java.io.IOException: Connection reset by peerat org.apache.catalina.co

前面系列文章我们对 Sentinel 的作用及工作流程源码进行了分析，我们知道 Sentinel 的众多功能都是通过规则配置完成的，但是我们前面在演示的时候，发现 Sentinel 一重启，配置的规则就没有了，这是因为规则存储在内存中，本篇我们来实现 Sentinel 规则持久化到 Nacos 中。

需要注意的是 RocketMQ 的延迟消息使用的是 delayLevel 延迟级别来表示的，并不是直接使用时间，例如：delayLevel = 1 延迟时间为 1秒，delayLevel = 2 延迟时间为 5秒，delayLevel = 3 延迟时间为 10秒，delayLevel = 4 延迟时间为 30秒，以此类推。上一篇我们分享了 Spring Boot 整合 RocketMQ 完成单向消

总结：Spring Boot 事件监听机制工作原理其实和 Spring 的事件监听机制原理一样，Spring Boot 只是通过自动配置简化了一些复杂的配置而已，如果我们熟读 Spring 的源码，那对 SpringBoot 的源码解读是有极大帮助的，Spring Boot 很多功能都是基于 Spring 的，最后本篇关于 Spring Boot 事件监听机制工作原理的分享，希望可以帮助到需要的小

线程打断，打断调用者线程，但是 interrupt 方法和 stop 方法有本质区别，它并不会向 stop 方法一样直接中断一个线程的运行，调用 interrupt 方法的线程会继续运行下去，但是会设置一个中断标志 true，由调用者线程决定什么时候来来判执行线程中断，，，，，，，，，，，，，，，，，，。很明显使用 yield 方法，同样的逻辑处理，消耗的时间远大于使用了 yield 方法，证明

Sentinel 是阿里巴巴开源的面向分布式服务架构的高可用流量防护组件，随着微服务的流行，服务和服务之间的稳定性变得越来越重要，Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

上一篇我们分享了 RocketMQ 消息重试的一些基本原理，本篇我们基于 Spring Boot 整合 RocketMQ来分享一下 RocketMQ 消息基于手动提交的案例，在分享手动进行消息 ACK 中也会分享消息重试的使用。

随着微服务的流行，以及一些大型系统的诞生，会使项目产生更多的微服务，服务与服务之间的调用也越发频繁，服务之间的稳定性也就愈发重要，限流降级是保护服务稳定利器，我们熟知的限流组件有 Hystrix 和 Sentinel，Sentinel 是阿里中间件团队开源的，面向分布式服务架构的轻量级高可用流量控制组件，主要以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度来帮助用户保护服务的稳定性。如

在消息中间件领域中 RabbitMQ 也是一种非常常见的消息中间件了，本篇简单分享一下 Spring Boot 项目集成 RabbitMQ 的过程。

看起来代码显示的抛出了异常，也设置了全局异常处理器，但是并没有返回想要的异常状态码，至此感觉走到了死胡同，此时想到了老办法，debug 调试，经过多次 debug 调试，发现全局异常处理器没有拦截到任何异常，这就很能说明问题了，也就是全局异常处理器，根本捕获不到过滤器 filter 抛出的异常，那怎么办呢？技术方案拟定后，就着手开始改造，一切都很顺畅，可是在异常场景模拟的时候，怎么也得不到想要的异