为什么我要用redis来完成异步消息,而不是消息队列mq之类的?

1. 因为很多的单体项目可能只需要需要一个略微简单的消息通知,而不需要如kafka那种完善的消息队列,
2. 而且redis在正常的项目中基本都会引入而mq可能较少会引入,所以使用redis来实现消息通知可以减少不必要的中间件引入和维护.

 

设计思路的来源

主要借鉴了spring对jms的封装,比如使用注解@JmsListener来完成监听.

 

框架设计

对方法上的标有自定义监听注解方法,在订阅的消息发送时,被反射调用,这就需要我们在spring容器启动后,对每个bean进行判断是否方法上有注解. 所以我使用beanPostProcess来实现这件事情.

 

代码分析

定义自定义监听注解

定义自定义beanpostprocess,核心代码如下,包括对bean 的每个方法的扫描并添加订阅

定义redis监听对象,这里主要使用上面传入的对象和方法,在接收到通知是反射调用被注解的方法.

消息发布者,可以直接在redis的客户端命令行来发布消息,这里主要方便自己测试

 

框架的使用

因为我这里基于我之前的自定义的redis-starter(springboot快速启动配置),需要在启动类加上对应注解

然后在某个bean中配置监听(注意beanpostprocess处理的时候可能bean被aop代理了,这种情况需要时jdk的代理,然后再接口中也有对应的接口方法)

配置框架提供的bean

启动项目,看到控制台输出就代表成功了

最后允许的时候发布一个消息,接口就会被反射调用输出接收到的方法

 

redis订阅通知的弊端

redis 的订阅通知是没有持久化的,所以没有被及时消费的消息可能会消失,这里我的解决办法是使用redis 的list来实现订阅通知,当然我已经实现了,但是因为写这篇文章的时候精神不佳,就先写到这里, 当然你们也可以直接看我的代码. 需要我分析的等下一次博客的更新.

 

代码地址

https://github.com/cdy1996/redis-starter/tree/master/src/main/java/com/cdy/redisstarter/subscribe