消息隊列的學習

消息隊列應用場景

以下介紹消息隊列在實際應用中常用的使用場景。異步處理，應用解耦，流量削鋒和消息通訊四個場景

2.1 異步處理

場景說明：用戶註冊後，需要發註冊郵件和註冊短信。傳統的做法有兩種 1.串行的方式；2.並行方式

（1）串行方式：將註冊信息寫入數據庫成功後，發送註冊郵件，再發送註冊短信。以上三個任務全部完成後，返回給客戶端

 

 

 

（2）並行方式：將註冊信息寫入數據庫成功後，發送註冊郵件的同時，發送註冊短信。以上三個任務完成後，返回給客戶端。與串行的差別是，並行的方式可以提高處理的時間

 

 

 

引入消息隊列，將不是必須的業務邏輯，異步處理。改造後的架構如下：

 

 

 

按照以上約定，用戶的響應時間相當於是註冊信息寫入數據庫的時間，也就是50毫秒。註冊郵件，發送短信寫入消息隊列後，直接返回，因此寫入消息隊列的速度 很快，基本可以忽略，因此用戶的響應時間可能是50毫秒。因此架構改變後，系統的吞吐量提高到每秒20 QPS。比串行提高了3倍，比並行提高了兩倍

 

2.2 應用解耦

場景說明：用戶下單後，訂單系統需要通知庫存系統。傳統的做法是，訂單系統調用庫存系統的接口。如下圖

 

 

 

傳統模式的缺點：

• 假如庫存系統無法訪問，則訂單減庫存將失敗，從而導致訂單失敗
• 訂單系統與庫存系統耦合

如何解決以上問題呢？引入應用消息隊列後的方案，如下圖：

 

 

 

• 訂單系統：用戶下單後，訂單系統完成持久化處理，將消息寫入消息隊列，返回用戶訂單下單成功
• 庫存系統：訂閱下單的消息，採用拉/推的方式，獲取下單信息，庫存系統根據下單信息，進行庫存操作
• 假如：在下單時庫存系統不能正常使用。也不影響正常下單，因爲下單後，訂單系統寫入消息隊列就不再關心其他的後續操作了。實現訂單系統與庫存系統的應用解耦

 

2.3 流量削鋒

流量削鋒也是消息隊列中的常用場景，一般在秒殺或團搶活動中使用廣泛

應用場景：秒殺活動，一般會因爲流量過大，導致流量暴增，應用掛掉。爲解決這個問題，一般需要在應用前端加入消息隊列。

• 可以控制活動的人數
• 可以緩解短時間內高流量壓垮應用

 

 

 

• 用戶的請求，服務器接收後，首先寫入消息隊列。假如消息隊列長度超過最大數量，則直接拋棄用戶請求或跳轉到錯誤頁面
• 秒殺業務根據消息隊列中的請求信息，再做後續處理

2.4 日誌處理

通過同步的方式記錄日誌勢必會影響系統的響應速度。比如Kafka架構簡化如下

 

 

 

• 日誌採集客戶端，負責日誌數據採集，定時寫受寫入Kafka隊列
• Kafka消息隊列，負責日誌數據的接收，存儲和轉發
• 日誌處理應用：訂閱並消費kafka隊列中的日誌數據

以下是新浪kafka日誌處理應用案例

 

 

 

(1)Kafka：接收用戶日誌的消息隊列

(2)Logstash：做日誌解析，統一成JSON輸出給Elasticsearch

(3)Elasticsearch：實時日誌分析服務的核心技術，一個schemaless，實時的數據存儲服務，通過index組織數據，兼具強大的搜索和統計功能

(4)Kibana：基於Elasticsearch的數據可視化組件，超強的數據可視化能力是衆多公司選擇ELK stack的重要原因

2.5 消息通訊

消息通訊是指，消息隊列一般都內置了高效的通信機制，因此也可以用在純的消息通訊。比如實現點對點消息隊列，或者聊天室等

點對點通訊：

 

 

 

客戶端A和客戶端B使用同一隊列，進行消息通訊。

聊天室通訊：

 

 

 

客戶端A，客戶端B，客戶端N訂閱同一主題，進行消息發佈和接收。實現類似聊天室效果。

centos rabbitmq的使用：

yum install erlang

yum install rabbitmq-server -y

pip install pika python客戶端

日誌目錄 /var/log/rabbitmq/

配置目錄 /etc/rabbitmq/rabbitmq.config

四種交換機：

直連交換機：消息的路由鍵，對應一個消息隊列（綁定交換機的時候，設置好鍵)

主題交換機：將消息路由到多個消息隊列，比如路由鍵log.cache.publish這種組合（可以*單個通配，#任意通配）

扇形交換機：消息路由到所有隊列，不理會路由鍵（一個操作有多個連代操作）

頭交換機：和直連差不多，但是性能不好，很少用

publish.py

#coding=utf-8
import sys
import pika

parameters = pika.URLParameters("amqp://guest:guest@localhost:5672/%2F")
connection = pika.BlockingConnection(parameters)
channel = connection.channel()
channel.exchange_declare(exchange='web_develop', exchange_type='direct', passive=False, durable=True, auto_delete=False)

msg = sys.argv[1] if len(sys.argv) != 1 else 'hah'
props = pika.BasicProperties(content_type='text/plain', delivery_mode=2)  #文本格式，消息持久化

#接收消息的確認
channel.confirm_delivery()
if channel.basic_publish('web_develop', 'xxx_routing_key', msg,properties=props):   #發送某個路由鍵，某個消息
    print('Message publish was confirmed!')
else:
    print('Message could not be confirmed!')

connection.close()

cosume.py 

#coding=utf-8
import pika
def on_message(channel, method_frame, header_frame, body):
    channel.basic_ack(delivery_tag=method_frame.delivery_tag)
    print(body)

parameters = pika.URLParameters("amqp://guest:guest@localhost:5672/%2F")
connection = pika.BlockingConnection(parameters)
channel = connection.channel()
channel.exchange_declare(exchange='web_develop', exchange_type='direct', passive=False, durable=True, auto_delete=False)

channel.queue_declare(queue='standard', auto_delete=True)
channel.queue_bind(queue='standard', exchange='web_develop', routing_key='xxx_routing_key')

channel.basic_consume('standard', on_message_callback=on_message) #隊列訂閱消息

try:
    channel.start_consuming()
except KeyboardInterrupt:
    channel.stop_consuming()
connection.close()

先啓動消費，在啓動發佈。

支持虛擬主機，來配置用戶名密碼和權限

rabbitmqctl add_user sf 123456

rabbitmqctl add_vhost web_develop

rabbitmqctl set_permissions -p web_develop sf  ".*" ".*" ".*"  #分別是配置，寫，讀的權限

插件系統，比如圖形化的管理界面rabbitmq_management