消息中间件概述
? 消息中間件概述
- 學習消息隊列的原因
- 消息中間件概述
- 消息隊列應用場景
- 消息中間件主要作用
- 應用解耦
- 異步處理
- 流量削峰(削峰填谷)
- QPS,PV,UV,PR概念
- AMQP和JMS
- 消息隊列產品
- RabbitMQ核心概念 架構原理
📃個人主頁:不斷前進的皮卡丘
🌞博客描述:夢想也許遙不可及，但重要的是追夢的過程，用博客記錄自己的成長，記錄自己一步一步向上攀登的印記
🔥個人專欄:消息中間件專欄
學習消息隊列的原因
📖在電子商務應用中，我們經常需要對龐大的數據進行監控，MQ的使用與日俱增，特別是RabbitMQ在分布式系統中存儲轉發消息，可以保證數據不丟失，也可以保證高可用性，即集群的時候部分機器宕機可以繼續執行。在大型電子商務類網址，比如京東、淘寶等網址有著深入的應用。
🔥隊列可以消除高并發訪問高峰，加快網站的響應速度。
👀在不適用消息隊列的情況，用戶的請求直接寫入數據庫，在高并發的情況會對數據庫造成巨大的壓力，同時也會導致系統響應延遲加劇。
消息中間件概述
- MQ(Message Queue),消息隊列(MQ)是一種應用程序對應用程序的通信方法
- 消息隊列是一種先進先出的數據結構
- 消息傳遞:指的是程序直接通過消息發送數據進行通信，而不是通過直接調用彼此來通信，直接調用通常是擁有遠程調用的技術
- 引入消息隊列的原因:
- 不同進程之間傳遞消息的時候，兩個進程之間耦合度過高，一個進程的改變就會引發另外一個進程的改變。為了讓它們不會互相干擾，我們需要在兩個進程之間抽離出一個模塊，兩個進程之間傳遞的消息通過消息隊列來傳遞。單獨修改某一個進程不會影響另外一個。
- 某個進程一下子接受的消息太多了，無法馬上處理好，就需要對接受的消息進行排隊，所以有了消息隊列
- 我們可以把一些不需要即時返回而且又耗費時間的操作提取出來，進行異步處理，可以節省服務器的請求響應時間，從而提高了系統的吞吐量。
消息隊列應用場景
消息中間件主要作用
- 異步處理
- 解耦服務
- 流量削峰
應用解耦
- 傳統的模式會出現耦合的情況
- 通過中間件模式，可以進行解耦的作用
異步處理
-
場景說明:用戶注冊以后，需要發送注冊郵件和注冊短信，傳統的方式有兩種:串行方式和并行的方式。
-
串行方式:
- 把注冊信息寫到數據庫中后，發送注冊郵件，再發送注冊短信，這三個認為全部完成以后才返回給客戶端。但是有個地方要注意，郵件和短信并不是必須的，它只是一個通知，這種方式會導致客戶端在等一些沒有必要等待的東西。
-
并行方式:
- 把注冊信息寫到數據庫中后，發送郵件的同時，發送短信，這三個認為任務完成后返回給客戶端，并行的方式可以提高處理的事件時間
- 雖然并行的方式可以提高效率，但是因為短信和郵件對于我們正常使用網站來說是沒有影響的，所以客戶端并不需要等到它發送完成以后才顯示注冊成功，應該是寫入數據庫中后就可以返回。
-
消息隊列:
- 引入消息隊列以后，把發送短信，郵件等不是必須的業務邏輯進行異步處理
- 引入消息隊列以后，用戶的響應時間就等于寫入數據庫的時間+寫入消息隊列的時間(可以忽略不計)
流量削峰(削峰填谷)
- 流量削峰一般在秒殺活動中應該廣泛，因為秒殺活動一般會因為流量過大，導致應用掛掉，為了解決這個問題，我們一般需要加入消息隊列
- 傳統模式:在下單的時候就會往數據庫中添加數據，但是如果并發量過高的話，就可能導致宕機。
- 如果說消息被MQ保存起來，然后系統可以按照自己的消費能力來消費，比如每秒1000個數據，這樣慢慢寫入到數據庫中，就不會導致數據庫卡死了
- 系統慢慢的按照數據庫能夠處理的并發量，從消息隊列中慢慢拉取消息。在生產中，這個短暫的高峰期積壓是允許的。
QPS,PV,UV,PR概念
- QPS
- QPS:每秒查詢率,是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準。
- 因特網經常用每秒查詢率來衡量域名系統服務器的機器的性能
- QPS=并發量/平均響應時間
- PV:Page View，網頁瀏覽量。網頁被讀者調用瀏覽的次數。網頁每次打開或刷新一次頁面，記錄一次。用戶對同一頁面的多次訪問，訪問量累計。
- UV （Unique Visitor，獨立訪客訪問數）
統計1天內訪問某站點的用戶數(以 cookie 為依據)，一臺電腦終端為一個訪客。 - PR：PageRank,網頁的級別技術，用來標識網頁的等級/重要性。級別從1到10.PR越高，說明這個網頁越受歡迎
AMQP和JMS
- MQ是消息通信的模型，實現MQ大致有兩種主流方式:AMQP、JMS
- AMQP是一種高級消息隊列協議(Advanced Message Queuing Protocol),更準確的說是一種鏈接協議。這是和JMS的 本質區別，AMQP不和API層進行限定，而是直接定義網絡交換的數據格式
- JMS即Java消息服務(JavaMessage Service)應用程序接口，是一個Java平臺關于面向消息中間件(MOM)的API，用在兩個應用程序之間，或者分布式系統中發送消息，進行異步通信。
- 二者的區別
- JMS是定義了統一的接口，來對消息進行操作統一；AMQP是通過規定協議來統一數據交互的格式
- JMS限定了必須使用Java語言；AMQP只是協議，不規定實現方式，是跨語言的
- JMS規定了兩種消息模式；二AMQP的消息模式更加豐富。
消息隊列產品
常用6種消息隊列介紹和對比
RabbitMQ核心概念 架構原理
- Broker ：接收和分發消息的應用， RabbitMQ Server 就是 Message Broker
- Virtual host： 出于多租戶和安全因素設計的，把 AMQP 的基本組件劃分到一個虛擬的分組中，類似 于網絡中的 namespace 概念。當多個不同的用戶使用同一個 RabbitMQ server 提供的服務時，可以劃分出 多個 vhost ，每個用戶在自己的 vhost 創建 exchange ／ queue 等
- Connection： publisher ／ consumer 和 broker 之間的 TCP 連接
- Channel ：如果每一次訪問 RabbitMQ 都建立一個 Connection ，在消息量大的時候建立 TCP連接 的開銷將是巨大的，效率也較低。 Channel 是在 connection 內部建立的邏輯連接，如果應用程序支持多線程，通常每個 thread 創建單獨的 channel 進行通訊， AMQP method 包含了 channel id 幫助客 戶端和 message broker 識別 channel ，所以 channel 之間是完全隔離的。 Channel 作為輕量級的 Connection 極大減少了操作系統建立 TCP 連接 的開銷
- Exchange： message 到達 broker 的第一站，根據分發規則，匹配查詢表中的 routing key ，分發消息到 queue 中去。常用的類型有： direct (point-to-point), topic (publish-subscribe) and fanout(multicast)
- Queue： 消息最終被送到這里等待 consumer 取走
- Binding ： exchange 和 queue 之間的虛擬連接， binding 中可以包含 routing key ， Binding 信息被保 存到 exchange 中的查詢表中，用于 message 的分發依據
總結
- 上一篇： html 超文本编辑器,超级文本编辑器—
- 下一篇： vim编辑器使用手册