為什麼我要用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來實現訂閱通知,當然我已經實現了,但是因為寫這篇文章的時候精神不佳,就先寫到這裡, 當然你們也可以直接看我的程式碼. 需要我分析的等下一次部落格的更新.

程式碼地址