前言
我們前面的文章中講解過RabbitMQ的用法，所謂MQ就是一種發布訂閱模式的消息模型。在Spring中其實本身也為我們提供了一種發布訂閱模式的事件處理方式，就是ApplicationEvent和 ApplicationListener，這是一種基于觀察者模式實現事件監聽功能。也已幫助我們完成業務邏輯的解耦，提高程序的擴展性和可維護性。
但是這里要注意ApplicationEvent和 MQ隊列雖然實現的功能相似，但是MQ還是有其不可替代性的，最本質的區別就是MQ可以用于不同系統之間的消息發布，而SpringEvent這種模式只能在一個系統中，也就是要求必須是同一個Spring容器。
好了接下來我們就來演練一番。
在這個模型中，有兩個重要的類，一個是事件，一個是監聽。事件要繼承ApplicationEvent類，監聽要實現ApplicationListener接口。
一、開發ApplicationEvent事件
事件其實就是我們要發送的消息體，這個一般要根據我們的實際業務進行封裝，需要什么類型的數據，就是用什么類型，需要哪些字段就添加哪些字段。我們來給一個案例。
二、 開發監聽器
監聽器就相當于我們的MQ的消費者，當有時間推送過來的時候，監聽器的代碼就可以執行。這里通過泛型來設置好我們的事件類型。
三、推送事件
推送事件需要使用ApplicationEventPublisher。這個對象在Spring容器加載的時候就已經在容器中了。所以我們可以直接注入使用,也可以使用ApplicationContext,因為ApplicationContext本身就繼承了ApplicationEventPublisher。 我們通過一個Controller來驗證一下。
我們定義兩個推送的方法。一個推送我們的MyApplicationEvent類型，還有一個方法推送一個字符串。
當我們調用第一個方法的時候，控制臺可以打印出我們推送的數據信息。
調用推送字符串的時候，我們的監聽器不會執行，原因是我們的攔截器里已經加了泛型MyApplicationEvent，也就是只會監聽MyApplicationEvent類型的消息。其他類型的消息不會被監聽到。
那如果我們把泛型去掉會有什么效果呢，我們來試試。
每次推送都會發送兩條（可能有什么內部機制，不管了），但是兩個都打印了，說明如果不加泛型，不管誰推，這邊都能收到消息。
四、注解方式實現監聽器
除了上面的通過實現接口的方式開發監聽器，我們還可以通過注解的方式來實現，具體代碼如下。
這里加入了@EventListener 注解代表了這是一個監聽器。方法名隨意，方法里的參數代表監聽的事件類型。
再次調用push方法：
發現兩個監聽器的數據都會打印。這一特點大家要注意一下。
好了，關于Spring中的ApplicationEvent和ApplicationListener我們就介紹這么多。
