本篇內(nèi)容主要講解“web消息隊(duì)列有哪些”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“web消息隊(duì)列有哪些”吧!

創(chuàng)新互聯(lián)的團(tuán)隊(duì)成員不追求數(shù)量、追求質(zhì)量。我們經(jīng)驗(yàn)豐富并且專業(yè)，我們之間合作時(shí)就好像一個(gè)人，協(xié)同一致毫無(wú)保留。創(chuàng)新互聯(lián)珍視想法，同時(shí)也看重過(guò)程轉(zhuǎn)化帶來(lái)的沖擊力和影響力，在我們眼中，任何細(xì)節(jié)都不容小覷。一直致力于為企業(yè)提供從域名與空間、網(wǎng)站策劃、網(wǎng)站設(shè)計(jì)、商城系統(tǒng)網(wǎng)站開(kāi)發(fā)、網(wǎng)站推廣、網(wǎng)站優(yōu)化到為企業(yè)提供個(gè)性化軟件開(kāi)發(fā)等基于互聯(lián)網(wǎng)的全面整合營(yíng)銷服務(wù)。

消息隊(duì)列

消息隊(duì)列中間件是分布式系統(tǒng)中重要的組件，主要解決應(yīng)用耦合，異步消息，流量削鋒等問(wèn)題 實(shí)現(xiàn)高性能，高可用，可伸縮和最終一致性架構(gòu) 使用較多的消息隊(duì)列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ等。

應(yīng)用場(chǎng)景

消息隊(duì)列在實(shí)際應(yīng)用中常用的使用場(chǎng)景。異步處理，應(yīng)用解耦，流量削鋒和消息通訊四個(gè)場(chǎng)景。

• 異步處理

場(chǎng)景說(shuō)明：用戶注冊(cè)后，需要發(fā)注冊(cè)郵件和注冊(cè)短信。

傳統(tǒng)的做法有兩種 1.串行的方式；2.并行方式

1. 串行方式：將注冊(cè)信息寫入數(shù)據(jù)庫(kù)成功后，發(fā)送注冊(cè)郵件，再發(fā)送注冊(cè)短信。以上三個(gè)任務(wù)全部完成后，返回給客戶端。

2. 并行方式：將注冊(cè)信息寫入數(shù)據(jù)庫(kù)成功后，發(fā)送注冊(cè)郵件的同時(shí)，發(fā)送注冊(cè)短信。以上三個(gè)任務(wù)完成后，返回給客戶端。與串行的差別是，并行的方式可以提高處理的時(shí)間。

假設(shè)三個(gè)業(yè)務(wù)節(jié)點(diǎn)每個(gè)使用50毫秒鐘，不考慮網(wǎng)絡(luò)等其他開(kāi)銷，則串行方式的時(shí)間是150毫秒，并行的時(shí)間可能是100毫秒。

因?yàn)镃PU在單位時(shí)間內(nèi)處理的請(qǐng)求數(shù)是一定的，假設(shè)CPU1秒內(nèi)吞吐量是100次。則串行方式1秒內(nèi)CPU可處理的請(qǐng)求量是7次（1000/150）。并行方式處理的請(qǐng)求量是10次（1000/100）。

引入消息隊(duì)列后，將不是必須的業(yè)務(wù)邏輯，異步處理。

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

• 應(yīng)用解耦

用戶下單后，訂單系統(tǒng)需要通知庫(kù)存系統(tǒng)。傳統(tǒng)的做法是，訂單系統(tǒng)調(diào)用庫(kù)存系統(tǒng)的接口。

避免接口的方式，加入消息隊(duì)列。

訂單系統(tǒng)：用戶下單后，訂單系統(tǒng)完成持久化處理，將消息寫入消息隊(duì)列，返回用戶訂單下單成功。

庫(kù)存系統(tǒng)：訂閱下單的消息，采用拉/推的方式，獲取下單信息，庫(kù)存系統(tǒng)根據(jù)下單信息，進(jìn)行庫(kù)存操作。

假如：在下單時(shí)庫(kù)存系統(tǒng)不能正常使用。也不影響正常下單，因?yàn)橄聠魏?，訂單系統(tǒng)寫入消息隊(duì)列就不再關(guān)心其他的后續(xù)操作了。實(shí)現(xiàn)訂單系統(tǒng)與庫(kù)存系統(tǒng)的應(yīng)用解耦。

• 流量削鋒

流量削鋒也是消息隊(duì)列中的常用場(chǎng)景，一般在秒殺或團(tuán)搶活動(dòng)中使用廣泛。

秒殺活動(dòng)，一般會(huì)因?yàn)榱髁窟^(guò)大，導(dǎo)致流量暴增，應(yīng)用掛掉。為解決這個(gè)問(wèn)題，一般需要在應(yīng)用前端加入消息隊(duì)列。

1. 可以控制活動(dòng)的人數(shù)

2. 可以緩解短時(shí)間內(nèi)高流量壓垮應(yīng)用

用戶的請(qǐng)求，服務(wù)器接收后，首先寫入消息隊(duì)列。假如消息隊(duì)列長(zhǎng)度超過(guò)最大數(shù)量，則直接拋棄用戶請(qǐng)求或跳轉(zhuǎn)到錯(cuò)誤頁(yè)面。

秒殺業(yè)務(wù)根據(jù)消息隊(duì)列中的請(qǐng)求信息，再做后續(xù)處理。

• 消息通訊

日志處理是指將消息隊(duì)列用在日志處理中，比如Kafka的應(yīng)用，解決大量日志傳輸?shù)膯?wèn)題。

1. 日志采集客戶端，負(fù)責(zé)日志數(shù)據(jù)采集，定時(shí)寫受寫入Kafka隊(duì)列。

2. Kafka消息隊(duì)列，負(fù)責(zé)日志數(shù)據(jù)的接收，存儲(chǔ)和轉(zhuǎn)發(fā)。

3. 日志處理應(yīng)用：訂閱并消費(fèi)kafka隊(duì)列中的日志數(shù)據(jù)。

大數(shù)據(jù)量下隊(duì)列對(duì)比

有代表性的幾個(gè)MQ(rabbitMQ，kafka，ActiveMQ)進(jìn)行一下簡(jiǎn)單的對(duì)比。

具體的對(duì)比如下：

• TPS比較：

Kafka最高，RabbitMq 次之， ActiveMq 最差。

• 吞吐量對(duì)比：

kafka具有高的吞吐量，內(nèi)部采用消息的批量處理，zero-copy機(jī)制，數(shù)據(jù)的存儲(chǔ)和獲取是本地磁盤順序批量操作，具有O(1)的復(fù)雜度，消息處理的效率很高。 rabbitMQ在吞吐量方面稍遜于kafka，他們的出發(fā)點(diǎn)不一樣，rabbitMQ支持對(duì)消息的可靠的傳遞，支持事務(wù)，不支持批量的操作；基于存儲(chǔ)的可靠性的要求存儲(chǔ)可以采用內(nèi)存或者硬盤。

• 在架構(gòu)模型方面：

RabbitMQ遵循AMQP協(xié)議，RabbitMQ的broker由Exchange,Binding,queue組成，其中exchange和binding組成了消息的路由鍵；客戶端Producer通過(guò)連接channel和server進(jìn)行通信，Consumer從queue獲取消息進(jìn)行消費(fèi)（長(zhǎng)連接，queue有消息會(huì)推送到consumer端，consumer循環(huán)從輸入流讀取數(shù)據(jù)）。rabbitMQ以broker為中心；有消息的確認(rèn)機(jī)制。

kafka遵從一般的MQ結(jié)構(gòu)，producer，broker，consumer，以consumer為中心，消息的消費(fèi)信息保存的客戶端consumer上，consumer根據(jù)消費(fèi)的點(diǎn)，從broker上批量pull數(shù)據(jù)；無(wú)消息確認(rèn)機(jī)制。

• 在可用性方面，

rabbitMQ支持miror的queue，主queue失效，miror queue接管。 kafka的broker支持主備模式。

activeMq也支持主備模式。

• 在集群負(fù)載均衡方面，

kafka采用zookeeper對(duì)集群中的broker、consumer進(jìn)行管理，可以注冊(cè)topic到zookeeper上；通過(guò)zookeeper的協(xié)調(diào)機(jī)制，producer保存對(duì)應(yīng)topic的broker信息，可以隨機(jī)或者輪詢發(fā)送到broker上；并且producer可以基于語(yǔ)義指定分片，消息發(fā)送到broker的某分片上。

rabbitMQ的負(fù)載均衡需要單獨(dú)的loadbalancer進(jìn)行支持。

• 綜合對(duì)比

ActiveMQ: 歷史悠久的開(kāi)源項(xiàng)目，已經(jīng)在很多產(chǎn)品中得到應(yīng)用，實(shí)現(xiàn)了JMS1.1規(guī)范，可以和spring-jms輕松融合，實(shí)現(xiàn)了多種協(xié)議，不夠輕巧（源代碼比RocketMQ多），支持持久化到數(shù)據(jù)庫(kù)，對(duì)隊(duì)列數(shù)較多的情況支持不好。

RabbitMq： 它比kafka成熟，支持AMQP事務(wù)處理，在可靠性上，RabbitMq超過(guò)kafka，在性能方面超過(guò)ActiveMQ。

Kafka： Kafka設(shè)計(jì)的初衷就是處理日志的，不支持AMQP事務(wù)處理，可以看做是一個(gè)日志系統(tǒng)，針對(duì)性很強(qiáng)，所以它并沒(méi)有具備一個(gè)成熟MQ應(yīng)該具備的特性 Kafka的性能（吞吐量、tps）比RabbitMq要強(qiáng)，如果用來(lái)做大數(shù)據(jù)量的快速處理是比RabbitMq有優(yōu)勢(shì)的。

最后結(jié)一張綜合的對(duì)比：

到此，相信大家對(duì)“web消息隊(duì)列有哪些”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！