初識消息隊列之 消息隊列的主要作用

主要作用

消息隊列的主要作用，有解耦，異步，消峯

• 解耦

將消息寫入消息隊列，需要消息的系統自己從消息隊列中訂閱，從而系統不需要做任何修改。

• 異步

將消息寫入消息隊列，非必要的業務邏輯以異步的方式運行，加快響應速度

• 削峯

系統慢慢的按照數據庫能處理的併發量，從消息隊列中慢慢拉取消息。在生產中，這個短暫的高峯期積壓是允許的

• 一個小栗子

拿某寶的“運動”項目舉例，它每天記錄你的步數，比如3000步。這時候 “種樹”項目來了，希望通過的你步數，看你是否進行了環保運動，如果運動達標，則產生對應的獎勵（比如可以讓你的樹更好的生長）。又過了一段時間，一個新的項目產生了，它也希望通過步數來達到一個目的，比如通過你的步數，可以模擬在線運動，比如通過累計步數，通過計算多少步，來展示你繞地球幾圈。 我們分別標記 運動項目爲A，種樹項目爲B，模擬在線運動項目爲C
結構如下圖

我們發現，每當有相關子系統接入希望獲取到A產生的步數的時候，A系統必定要修改代碼去發起調用對應子系統去通知其完成業務。那有什麼更好的辦法呢？

設計模式中，觀察者模式是一個很好的解耦的反感，A產生數據，然後去批量通知監聽者去發起業務。B和C分別作爲監聽者，當接收到通知時自主去進行相關業務操作。 但是再思考一下A要處理的事情。
1）產生數據（0.7s）
2）通知被監聽者B和C發起業務（0.032s + 0.032s）

這裏我思考有個問題，第一個當產生數據後第二步的時間是隨着被監聽者的增多而增加的，如果數量過多，會對A系統自身的業務執行造成影響，比如用戶體驗度下降。如果將第二步操作改爲異步線程去執行呢，當第一步操作完成後，異步通知第二步去操作通知各個監聽者。這樣做是可以解決問題，但是考慮到A系統自身線程池資源的消耗，以及多個雷同A系統的業務發生時，我們是否都需要去考慮這麼一套模式去實現呢，有沒有一個東西，我們去通知它，然後它來幫我們合理的完成這麼一個工作呢。此時，我們的消息中間件就登場了。

這時候A系統的執行過程就變成
1）產生數據（0.7s）
2）發送數據給消息隊列(0.045s)

這個時候我們A系統的過程執行時間就可預估了，並且也無需再考慮其他系統的執行過程了。

上例是別人看了某寶後的自己的假想實現方式，並未真正瞭解某寶，請勿作準，只是爲了闡述自己的觀點

缺點

當然，使用了消息隊列，也會產生對應的一些問題

• 系統可用性降低
  任何系統都有宕機的風險，所以要考慮MQ中間件不穩定情況，做好集羣和災備是必須的

• 系統複雜性增加
  需要考慮其他更多影響系統因素，比如一致性問題，消息的重複消費等

常用的消息隊列

當然，綜上所訴的一切，並不需要我們去實現它，我們已經有一些開源的MQ中間件供我們選用

• activemq
• rabbitmq
• rocketmq
• kafka
• …