每日一句
You must try things that may not work. And you must not let anyone define your limits because of where you come from. Your only limit is your soul.
千萬不要怕失敗，也不要因為出身低就讓別人限制了你的發展，成敗在于你自己，
概述
訊息佇列已經逐漸成為企業IT系統內部通信的核心手段，它具有低耦合、可靠投遞、廣播、流量控制、最終一致性等一系列功能，成為異步RPC的主要手段之一，
常見的訊息中間件有：
- ActiveMQ
- RabbitMQ
- Kafka
- RocketMQ
傳統Http協議呼叫介面存在的缺陷
傳統方式 采用同步的形式呼叫介面，如果呼叫的程序非常耗時間的話，客戶需要等待非常久的時間才會回應；這樣對客戶端體驗非常不好，
比如用戶注冊 呼叫資料庫新增插入會員資訊需要3s、呼叫優惠券介面需要3s、呼叫第三方短信介面需要3s 一共需要9s的時間才會回傳資訊，這樣用戶的體驗是非常不好；
MQ 的作用
通常我們采用MQ來進行以下操作
- 流量削峰
- 應用解耦
- 異步呼叫
流量削峰
如果訂單系統最多能處理一萬次訂單，這個處理能力應付正常時段的下單時綽綽有余，正常時段我們下單一秒后就能回傳結果，
但是在高峰期，如果有兩萬次下單作業系統是處理不了的，只能限制訂單超過一萬后不允許用戶下單，
使用訊息佇列做緩沖，我們可以取消這個限制，把一秒內下的訂單分散成一段時間來處理，這時有些用戶可能在下單十幾秒后才能收到下單成功的操作，但是比不能下單的體驗要好
應用解耦
以電商應用為例，應用中有訂單系統、庫存系統、物流系統、支付系統，用戶創建訂單后，如果耦合呼叫庫存系統、物流系統、支付系統，任何一個子系統出了故障，都會造成下單操作例外，
當轉變成基于訊息佇列的方式后，系統間呼叫的問題會減少很多，
- 物流系統因為發生故障，需要幾分鐘來修復，
- 在這幾分鐘的時間里，物流系統要處理的內容被快取在訊息佇列中，用戶的下單操作可以正常完成，
- 當物流系統恢復后，繼續處理訂單資訊即可，中單用戶感受不到物流系統的故障，提升系統的可用性
異步處理
有些服務間呼叫是異步的，例如 A 呼叫 B，B 需要花費很長時間執行，但是 A 需要知道 B 什么時候可以執行完，
以前一般有兩種方式：
- A 過一段時間去呼叫 B 的查詢 api 查詢，
- A 提供一個 callback api，B 執行完之后呼叫 api 通知 A 服務，
這兩種方式都不是很優雅，使用訊息總線，可以很方便解決這個問題，
- A 呼叫 B 服務后，只需要監聽 B 處理完成的訊息
- 當 B 處理完成后，會發送一條訊息給 MQ，MQ 會將此訊息轉發給 A 服務，
這樣 A 服務既不用回圈呼叫 B 的查詢 api，也不用提供 callback api，同樣B 服務也不用做這些操作，A 服務還能及時的得到異步處理成功的訊息，
常見的 MQ 對比分析
1.Kafka
Kafka 主要特點是基于Pull 的模式來處理訊息消費，追求高吞吐量，一開始的目的就是用于日志收集和傳輸，適合產生大量資料的互聯網服務的資料收集業務，
大型公司建議可以選用，如果有日志采集功能，肯定是首選 kafka 了，
2.RocketMQ
天生為金融互聯網領域而生，對于可靠性要求很高的場景，尤其是電商里面的訂單扣款，以及業務削峰，在大量交易涌入時，后端可能無法及時處理的情況，RoketMQ 在穩定性上可能更值得信賴，這些業務場景在阿里雙 11 已經經歷了多次考驗，如果你的業務有上述并發場景，建議可以選擇 RocketMQ，
3.RabbitMQ
結合 erlang 語言本身的并發優勢，性能好時效性微秒級，社區活躍度也比較高，管理界面用起來十分方便，如果你的資料量沒有那么大，中小型公司優先選擇功能比較完備的 RabbitMQ，
美文佳句
蘇軾曾經說過：“古之立大事者，不惟有超世之才，亦必有堅忍不拔之志，”我們或許無法有出類拔萃的才能，但我們都可以有堅韌不拔的意志，已經努力了一年，也許現在的你有些累了，但每個人的人生都需要砥礪前行，無論何時，都不要輕言放棄，請相信，你的堅持，不會被辜負，
如果時光可以倒流，很多人想做的，只是過好當時的那一刻，
你好，我是yltrcc，日常分享技術點滴，歡迎關注我：ylcoder
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/419029.html
標籤：其他
上一篇：MongoDB 快速入門
下一篇：RabbitMQ 相關概念