大型網站架構系列:分散式訊息佇列(一)
以下是訊息佇列以下的大綱,本文主要介紹訊息佇列概述,訊息佇列應用場景和訊息中介軟體示例(電商,日誌系統)。
本次分享大綱
- 訊息佇列概述
- 訊息佇列應用場景
- 訊息中介軟體示例
- JMS訊息服務(見第二篇:大型網站架構系列:分散式訊息佇列(二))
- 常用訊息佇列(見第二篇:大型網站架構系列:分散式訊息佇列(二))
- 參考(推薦)資料(見第二篇:大型網站架構系列:分散式訊息佇列(二))
- 本次分享總結(見第二篇:大型網站架構系列:分散式訊息佇列(二))
一、訊息佇列概述
訊息佇列中介軟體是分散式系統中重要的元件,主要解決應用耦合,非同步訊息,流量削鋒等問題。實現高效能,高可用,可伸縮和最終一致性架構。是大型分散式系統不可缺少的中介軟體。
目前在生產環境,使用較多的訊息佇列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ等。
二、訊息佇列應用場景
以下介紹訊息佇列在實際應用中常用的使用場景。非同步處理,應用解耦,流量削鋒和訊息通訊四個場景。
2.1非同步處理
場景說明:使用者註冊後,需要發註冊郵件和註冊簡訊。傳統的做法有兩種1.序列的方式;2.並行方式。
(1)序列方式:將註冊資訊寫入資料庫成功後,傳送註冊郵件,再傳送註冊簡訊。以上三個任務全部完成後,返回給客戶端。(架構KKQ:466097527,歡迎加入)
(2)並行方式:將註冊資訊寫入資料庫成功後,傳送註冊郵件的同時,傳送註冊簡訊。以上三個任務完成後,返回給客戶端。與序列的差別是,並行的方式可以提高處理的時間。
假設三個業務節點每個使用50毫秒鐘,不考慮網路等其他開銷,則序列方式的時間是150毫秒,並行的時間可能是100毫秒。
因為CPU在單位時間內處理的請求數是一定的,假設CPU1秒內吞吐量是100次。則序列方式1秒內CPU可處理的請求量是7次(1000/150)。並行方式處理的請求量是10次(1000/100)。
小結:如以上案例描述,傳統的方式系統的效能(併發量,吞吐量,響應時間)會有瓶頸。如何解決這個問題呢?
引入訊息佇列,將不是必須的業務邏輯,非同步處理。改造後的架構如下:
按照以上約定,使用者的響應時間相當於是註冊資訊寫入資料庫的時間,也就是50毫秒。註冊郵件,傳送簡訊寫入訊息佇列後,直接返回,因此寫入訊息佇列的速度很快,基本可以忽略,因此使用者的響應時間可能是50毫秒。因此架構改變後,系統的吞吐量提高到每秒20 QPS。比序列提高了3倍,比並行提高了兩倍。
2.2應用解耦
場景說明:使用者下單後,訂單系統需要通知庫存系統。傳統的做法是,訂單系統呼叫庫存系統的介面。如下圖:(架構KKQ:466097527,歡迎加入)
傳統模式的缺點:
1) 假如庫存系統無法訪問,則訂單減庫存將失敗,從而導致訂單失敗;
2) 訂單系統與庫存系統耦合;
如何解決以上問題呢?引入應用訊息佇列後的方案,如下圖:
- 訂單系統:使用者下單後,訂單系統完成持久化處理,將訊息寫入訊息佇列,返回使用者訂單下單成功。
- 庫存系統:訂閱下單的訊息,採用拉/推的方式,獲取下單資訊,庫存系統根據下單資訊,進行庫存操作。
- 假如:在下單時庫存系統不能正常使用。也不影響正常下單,因為下單後,訂單系統寫入訊息佇列就不再關心其他的後續操作了。實現訂單系統與庫存系統的應用解耦。
2.3流量削鋒
流量削鋒也是訊息佇列中的常用場景,一般在秒殺或團搶活動中使用廣泛。
應用場景:秒殺活動,一般會因為流量過大,導致流量暴增,應用掛掉。為解決這個問題,一般需要在應用前端加入訊息佇列。
- 可以控制活動的人數;
- 可以緩解短時間內高流量壓垮應用;
- 使用者的請求,伺服器接收後,首先寫入訊息佇列。假如訊息佇列長度超過最大數量,則直接拋棄使用者請求或跳轉到錯誤頁面;
- 秒殺業務根據訊息佇列中的請求資訊,再做後續處理。
2.4日誌處理
日誌處理是指將訊息佇列用在日誌處理中,比如Kafka的應用,解決大量日誌傳輸的問題。架構簡化如下:(架構KKQ:466097527,歡迎加入)
- 日誌採集客戶端,負責日誌資料採集,定時寫受寫入Kafka佇列;
- Kafka訊息佇列,負責日誌資料的接收,儲存和轉發;
- 日誌處理應用:訂閱並消費kafka佇列中的日誌資料;
以下是新浪kafka日誌處理應用案例:
轉自(http://cloud.51cto.com/art/201507/484338.htm)
(1)Kafka:接收使用者日誌的訊息佇列。
(2)Logstash:做日誌解析,統一成JSON輸出給Elasticsearch。
(3)Elasticsearch:實時日誌分析服務的核心技術,一個schemaless,實時的資料儲存服務,通過index組織資料,兼具強大的搜尋和統計功能。
(4)Kibana:基於Elasticsearch的資料視覺化元件,超強的資料視覺化能力是眾多公司選擇ELK stack的重要原因。
2.5訊息通訊
訊息通訊是指,訊息佇列一般都內建了高效的通訊機制,因此也可以用在純的訊息通訊。比如實現點對點訊息佇列,或者聊天室等。
點對點通訊:
客戶端A和客戶端B使用同一佇列,進行訊息通訊。
聊天室通訊:
客戶端A,客戶端B,客戶端N訂閱同一主題,進行訊息釋出和接收。實現類似聊天室效果。
以上實際是訊息佇列的兩種訊息模式,點對點或釋出訂閱模式。模型為示意圖,供參考。
三、訊息中介軟體示例
3.1電商系統
訊息佇列採用高可用,可持久化的訊息中介軟體。比如Active MQ,Rabbit MQ,Rocket Mq。(1)應用將主幹邏輯處理完成後,寫入訊息佇列。訊息傳送是否成功可以開啟訊息的確認模式。(訊息佇列返回訊息接收成功狀態後,應用再返回,這樣保障訊息的完整性)
(2)擴充套件流程(發簡訊,配送處理)訂閱佇列訊息。採用推或拉的方式獲取訊息並處理。
(3)訊息將應用解耦的同時,帶來了資料一致性問題,可以採用最終一致性方式解決。比如主資料寫入資料庫,擴充套件應用根據訊息佇列,並結合資料庫方式實現基於訊息佇列的後續處理。
3.2日誌收集系統
分為Zookeeper註冊中心,日誌收集客戶端,Kafka叢集和Storm叢集(OtherApp)四部分組成。
- Zookeeper註冊中心,提出負載均衡和地址查詢服務;
- 日誌收集客戶端,用於採集應用系統的日誌,並將資料推送到kafka佇列;
- Kafka叢集:接收,路由,儲存,轉發等訊息處理;
Storm叢集:與OtherApp處於同一級別,採用拉的方式消費佇列中的資料;
相關文章
- 大型網站架構系列:訊息佇列(二)網站架構佇列
- 分散式訊息佇列分散式佇列
- 訊息佇列系列一:訊息佇列應用佇列
- 大型分散式網站架構技術總結分散式網站架構
- 我也要談談大型網站架構之系列(4)——分散式中的非同步通訊網站架構分散式非同步
- 大型網站架構系列:電商網站架構案例(1)網站架構
- 大型網站架構系列:電商網站架構案例(2)網站架構
- 大型網站架構系列:電商網站架構案例(3)網站架構
- 大型網站技術架構(一)--大型網站架構演化網站架構
- 大型分散式網站架構實戰專案分析分散式網站架構
- 分散式訊息佇列知識圖譜分散式佇列
- 快速理解Kafka分散式訊息佇列框架Kafka分散式佇列框架
- 訊息佇列在大型分散式系統中的實戰要點分析!佇列分散式
- 基於訊息佇列 RocketMQ 的大型分散式應用上雲最佳實踐佇列MQ分散式
- 為什麼分散式一定要有訊息佇列?分散式佇列
- 架構文摘:訊息佇列設計精要架構佇列
- 分散式訊息佇列:如何保證訊息的順序性分散式佇列
- 分散式之訊息佇列複習精講分散式佇列
- 訊息佇列(一)佇列
- 大型分散式網站架構:快取在分散式系統中的應用分散式網站架構快取
- 分散式訊息佇列:如何保證訊息不被重複消費?(訊息佇列消費的冪等性)分散式佇列
- 大型網站技術架構(二)--大型網站架構演化網站架構
- 分散式任務 + 訊息佇列框架 go-queue分散式佇列框架Go
- 大型網站架構網站架構
- 分散式訊息佇列RocketMQ--事務訊息--解決分散式事務的最佳實踐分散式佇列MQ
- 高併發架構訊息佇列面試題解析架構佇列面試題
- 該如何進行架構設計一個MQ訊息佇列?架構MQ佇列
- 分散式服務(RPC)+分散式訊息佇列(MQ)面試題精選分散式RPC佇列MQ面試題
- RabbitMQ訊息佇列系列教程(一)認識RabbitMQMQ佇列
- 大型網站架構演化網站架構
- 架構設計之NodeJS操作訊息佇列RabbitMQ架構NodeJS佇列MQ
- 在企業級架構應用中學Netty構建分散式訊息佇列實現原理淺析架構Netty分散式佇列
- 大型網站架構技術一覽網站架構
- 老生常談——利用訊息佇列處理分散式事務佇列分散式
- Zookeeper和Curator-Framework實踐之:分散式訊息佇列Framework分散式佇列
- 訊息佇列佇列
- System V 訊息佇列(一)佇列
- 訊息佇列之Kafka——從架構技術重新理解Kafka佇列Kafka架構