Title: 消息隊(duì)列
Date: 2018-08-09 10:02:40
Category: 數(shù)據(jù)
keywords: kafka，消息隊(duì)列

在高并發(fā)系統(tǒng)或處理耗時任務(wù)時变隔，消息隊(duì)列便會被聯(lián)想到匣缘，現(xiàn)在介紹下消息隊(duì)列應(yīng)用場景和kafka和rabbitmq的對比

消息隊(duì)列

消息隊(duì)列中間件是分布式系統(tǒng)中重要的組件孵户，主要解決應(yīng)用解耦，異步消息检柬，流量削鋒等問題竖配，實(shí)現(xiàn)高性能进胯，高可用胁镐，可伸縮和最終一致性架構(gòu)。目前使用較多的消息隊(duì)列有ActiveMQ颇玷，RabbitMQ帖渠，ZeroMQ竭宰，Kafka，MetaMQ狞甚，RocketMQ

異步處理

場景說明：用戶注冊后入愧，需要發(fā)注冊郵件和注冊短信棺蛛。傳統(tǒng)的做法有兩種

• 串行的方式
• 并行方式

a巩步、串行方式：將注冊信息寫入數(shù)據(jù)庫成功后椅野，發(fā)送注冊郵件籍胯，再發(fā)送注冊短信杖狼。以上三個任務(wù)全部完成后蝶涩，返回給客戶端絮识。

2018-08-09-10-24-55

b次舌、并行方式：將注冊信息寫入數(shù)據(jù)庫成功后，發(fā)送注冊郵件的同時挪圾，發(fā)送注冊短信逐沙。以上三個任務(wù)完成后酱吝，返回給客戶端务热。與串行的差別是崎岂，并行的方式可以提高處理的時間

2018-08-09-10-25-07

假設(shè)三個業(yè)務(wù)節(jié)點(diǎn)每個使用50毫秒鐘冲甘，不考慮網(wǎng)絡(luò)等其他開銷江醇，則串行方式的時間是150毫秒陶夜，并行的時間可能是100毫秒裆站。
因?yàn)镃PU在單位時間內(nèi)處理的請求數(shù)是一定的条辟，假設(shè)CPU1秒內(nèi)吞吐量是100次黔夭。則串行方式1秒內(nèi)CPU可處理的請求量是7次（1000/150）。并行方式處理的請求量是10次（1000/100）

小結(jié)：如以上案例描述羽嫡，傳統(tǒng)的方式系統(tǒng)的性能（并發(fā)量本姥，吞吐量，響應(yīng)時間）會有瓶頸杭棵。如何解決這個問題呢婚惫？

引入消息隊(duì)列，將不是必須的業(yè)務(wù)邏輯颜屠，異步處理辰妙。改造后的架構(gòu)如下：

按照以上約定，用戶的響應(yīng)時間相當(dāng)于是注冊信息寫入數(shù)據(jù)庫的時間甫窟，也就是50毫秒。注冊郵件，發(fā)送短信寫入消息隊(duì)列后懒构，直接返回，因此寫入消息隊(duì)列的速度很快，基本可以忽略蚁阳，因此用戶的響應(yīng)時間可能是50毫秒。因此架構(gòu)改變后，系統(tǒng)的吞吐量提高到每秒20 QPS届榄。比串行提高了3倍靖苇，比并行提高了兩倍。

應(yīng)用解耦

場景說明：用戶下單后，訂單系統(tǒng)需要通知庫存系統(tǒng)。傳統(tǒng)的做法是旨怠，訂單系統(tǒng)調(diào)用庫存系統(tǒng)的接口。如下圖：

2018-08-09-10-33-08

傳統(tǒng)模式的缺點(diǎn)：假如庫存系統(tǒng)無法訪問课锌，則訂單減庫存將失敗，從而導(dǎo)致訂單失敗丑掺，訂單系統(tǒng)與庫存系統(tǒng)耦合

如何解決以上問題呢兼丰？引入應(yīng)用消息隊(duì)列后的方案黍翎，如下圖：

2018-08-09-10-34-06

訂單系統(tǒng)：用戶下單后，訂單系統(tǒng)完成持久化處理，將消息寫入消息隊(duì)列铛嘱，返回用戶訂單下單成功
庫存系統(tǒng)：訂閱下單的消息纹磺，采用拉/推的方式，獲取下單信息历极，庫存系統(tǒng)根據(jù)下單信息氏义，進(jìn)行庫存操作
假如：在下單時庫存系統(tǒng)不能正常使用。也不影響正常下單，因?yàn)橄聠魏笱纪埽唵蜗到y(tǒng)寫入消息隊(duì)列就不再關(guān)心其他的后續(xù)操作了睁宰。實(shí)現(xiàn)訂單系統(tǒng)與庫存系統(tǒng)的應(yīng)用解耦

流量削鋒

流量削鋒也是消息隊(duì)列中的常用場景硫兰，一般在秒殺或團(tuán)搶活動中使用廣泛劫映。
應(yīng)用場景：秒殺活動祖今，一般會因?yàn)榱髁窟^大，導(dǎo)致流量暴增，應(yīng)用掛掉。為解決這個問題，一般需要在應(yīng)用前端加入消息隊(duì)列。

a、可以控制活動的人數(shù)

b侣颂、可以緩解短時間內(nèi)高流量壓垮應(yīng)用

2018-08-09-10-37-29

用戶的請求，服務(wù)器接收后，首先寫入消息隊(duì)列婆翔。假如消息隊(duì)列長度超過最大數(shù)量，則直接拋棄用戶請求或跳轉(zhuǎn)到錯誤頁面依溯。
秒殺業(yè)務(wù)根據(jù)消息隊(duì)列中的請求信息拜隧，再做后續(xù)處理

日志處理

日志處理是指將消息隊(duì)列用在日志處理中雀费，比如Kafka的應(yīng)用逛尚，解決大量日志傳輸?shù)膯栴}滤钱。架構(gòu)簡化如下

2018-08-09-10-41-28

日志采集客戶端痊末，負(fù)責(zé)日志數(shù)據(jù)采集，定時寫受寫入Kafka隊(duì)列
Kafka消息隊(duì)列幔嫂，負(fù)責(zé)日志數(shù)據(jù)的接收切心，存儲和轉(zhuǎn)發(fā)
日志處理應(yīng)用：訂閱并消費(fèi)kafka隊(duì)列中的日志數(shù)據(jù)

kafka vs rabbitmq