張灣網(wǎng)站制作公司哪家好，找成都創(chuàng)新互聯(lián)！從網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應(yīng)式網(wǎng)站建設(shè)等網(wǎng)站項(xiàng)目制作，到程序開發(fā)，運(yùn)營維護(hù)。成都創(chuàng)新互聯(lián)自2013年起到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選成都創(chuàng)新互聯(lián)。
cdn.xitu.io/2019/6/28/16b9d4b720e549cf?imageView2/0/w/1280/h/960/format/webp/ignore-error/1">
消息隊(duì)列（Message Queue）是一種進(jìn)程間通信或同一進(jìn)程的不同線程間的通信方式。進(jìn)程或者線程之間通過 消息進(jìn)行通信，消息發(fā)送后可以立即返回，由消息系統(tǒng)來確保信息的可靠傳遞，消息發(fā)布者（生產(chǎn)者）只管把消息發(fā)布到消息隊(duì)里中而不用管誰來消費(fèi)，消息使用者（消費(fèi)者）只管從消息隊(duì)列中獲取消息以進(jìn)一步處理而不用管理誰發(fā)布的消息，這樣發(fā)布者和使用者都不用知道對方的存在。
消息（Message）是指在應(yīng)用之間傳送的數(shù)據(jù)。消息可以非常簡單，比如只包含文本字符串，也可以很復(fù)雜，如嵌入對象。
通過提供 消息傳遞和 消息排隊(duì)模型，它可以在 分布式環(huán)境下提供 應(yīng)用解耦、彈性伸縮、冗余存儲、流量削峰、異步通信、數(shù)據(jù)同步等等功能，其作為 分布式系統(tǒng)架構(gòu)中的一個重要組件，有著舉足輕重的地位。消息隊(duì)列主要特點(diǎn)有：
異步性：將耗時的同步操作，通過以發(fā)送消息的方式，進(jìn)行了異步化處理。減少了同步等待的時間。
松耦合：消息隊(duì)列減少了服務(wù)之間的耦合性，不同的服務(wù)可以通過消息隊(duì)列進(jìn)行通信，而不用關(guān)心彼此的實(shí)現(xiàn)細(xì)節(jié)，只要定義好消息的格式就行
分布式：通過對消費(fèi)者的橫向擴(kuò)展，降低了消息隊(duì)列阻塞的風(fēng)險(xiǎn)，以及單個消費(fèi)者產(chǎn)生單點(diǎn)故障的可能性。
可靠性：消息隊(duì)列一般會把接收的消息存儲到本地硬盤上（當(dāng)消息被處理完之后，存儲信息根據(jù)不同的消息隊(duì)列實(shí)現(xiàn)，有可能將其刪除），這樣即使應(yīng)用掛掉或者消息隊(duì)列本身掛掉，消息也能夠重新加載。
同步處理是指從請求的發(fā)起一直到最終的處理完成期間，請求的調(diào)用方一直在同步阻塞等待調(diào)用的處理完成。
異步處理處理是指在請求發(fā)起的處理過程中，客戶端的代碼已經(jīng)返回了，它可以繼續(xù)進(jìn)行自己的后續(xù)操作，而不需要等待調(diào)用處理完成。
對一些比較耗時且不需要即時（同步）返回操作結(jié)果的操作，可以把處理過程通過消息隊(duì)列進(jìn)行異步處理。這樣做可以推遲耗時操作的處理，使耗時操作異步化，而不必阻塞客戶端程序，客戶端的程序在得到處理結(jié)果之前可以繼續(xù)執(zhí)行，從而提高客戶端程序的處理性能。
異步處理的主要目的是 減少請求響應(yīng)時間，實(shí)現(xiàn)非核心流程異步化，提高系統(tǒng)響應(yīng)性能。
使用消息隊(duì)列，可以有多個生產(chǎn)者發(fā)布消息，多個消費(fèi)者消費(fèi)消息，共同完成整個的業(yè)務(wù)處理邏輯，生產(chǎn)者只關(guān)心是否正確將消息寫入消息隊(duì)列，消費(fèi)者只關(guān)心從消息隊(duì)列中獲取消息，然后進(jìn)行處理邏輯，生產(chǎn)者和消費(fèi)者之間不需要直接的交互調(diào)用，沒有代碼的依賴耦合。
耦合度越低程序代碼越容易維護(hù)，也容易進(jìn)行擴(kuò)展。
一般在秒殺活動中廣泛使用。
在秒殺活動中，一般由于瞬時訪問量過大，服務(wù)器瞬間接收了大量的請求，流量暴增，這種情況下很有可能導(dǎo)致相關(guān)系統(tǒng)無法處理請求甚至崩潰。為了解決這個問題，一般會在應(yīng)用的前端加入消息隊(duì)列。
請求先寫入消息隊(duì)列，而不是由業(yè)務(wù)系統(tǒng)直接處理，做了一次緩沖，極大的減少了業(yè)務(wù)處理系統(tǒng)的壓力。
隊(duì)列的長度可以做限制，一般秒殺活動都是有數(shù)量限制的，后寫入隊(duì)列的用戶無法秒殺到商品，這樣的請求可以直接被拋棄，可以直接返回活動已結(jié)束或商品已售完。
使用消息隊(duì)列，即便是訪問流量持續(xù)的增長，系統(tǒng)依然可以持續(xù)的接收請求。雖然生產(chǎn)者生成的消息比消費(fèi)者消費(fèi)的速度快，但是通過消息隊(duì)列進(jìn)行了緩沖，在短時間內(nèi)，生產(chǎn)者和消費(fèi)者之間處理能力不會互相影響，同樣也可以保證系統(tǒng)的穩(wěn)定性。
消息隊(duì)列一般都內(nèi)置了高效的通信機(jī)制，因此可以用于單純的消息通訊，比如實(shí)現(xiàn)點(diǎn)對點(diǎn)消息隊(duì)列或者聊天室。
如果沒有消息隊(duì)列，每當(dāng)一個新的業(yè)務(wù)方介入，那都需要聯(lián)調(diào)一次接口。有了消息隊(duì)列，只需要關(guān)系消息是否送達(dá)了隊(duì)列，至于誰希望訂閱，是下游的事情，無疑極大地減少了開發(fā)和聯(lián)調(diào)的工作量。
將消息隊(duì)列用在日志處理中，解決了大量日志傳輸?shù)膯栴}（如Kafka）。
點(diǎn)對點(diǎn)模式用于 消息生產(chǎn)者和 消息消費(fèi)者之間 點(diǎn)到點(diǎn)的通信。消息生產(chǎn)者將消息發(fā)送到由某個名字標(biāo)識的特定隊(duì)列（Queue）。在消息傳遞給消費(fèi)者之前它被 存儲在這個隊(duì)列中。隊(duì)列消息可以放在 內(nèi)存中也可以 持久化，以保證在消息服務(wù)出現(xiàn)故障時仍然能夠傳遞消息。
點(diǎn)對點(diǎn)模式特點(diǎn)：
每個消息只有一個消費(fèi)者（Consumer），即一旦消息被消費(fèi)，消息就不再在消息隊(duì)列中。
生產(chǎn)者和消費(fèi)者之間沒有依賴性，生產(chǎn)者發(fā)送消息之后，不管有沒有消費(fèi)者在運(yùn)行，都不會影響到生產(chǎn)者下次發(fā)送消息。
消費(fèi)者在成功接收消息之后需向隊(duì)列應(yīng)答成功，以便消息隊(duì)列刪除當(dāng)前接收的消息。
發(fā)布者/訂閱者模型支持向一個特定的 消息主題生產(chǎn)消息。 0 或多個 訂閱者可能對接收來自 特定消息主題的消息感興趣。
在這種模型下，發(fā)布者和訂閱者彼此不知道對方。多個消費(fèi)者可以獲得消息，在 發(fā)布者和 訂閱者之間存在 時間依賴性。發(fā)布者需要建立一個 訂閱（subscription），以便能夠消費(fèi)者訂閱。訂閱者必須保持 持續(xù)的活動狀態(tài)并 接收消息。
發(fā)布/點(diǎn)閱模式特點(diǎn)：
每個消息可以有多個訂閱者。
發(fā)布者和訂閱者之間有時間上的依賴性，針對某個主題（Topic）的訂閱者，它必須創(chuàng)建一個訂閱之后，才能消費(fèi)發(fā)布者的消息。
為了消費(fèi)消息，訂閱者需要提前訂閱該角色主題，并保持在線運(yùn)行。
目前在生產(chǎn)環(huán)境，使用較多的消息隊(duì)列有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ等。
歡迎工作一到五年的Java工程師朋友們加入Java技術(shù)交流群：659270626
群內(nèi)提供免費(fèi)的Java架構(gòu)學(xué)習(xí)資料（里面有高可用、高并發(fā)、高性能及分布式、Jvm性能調(diào)優(yōu)、Spring源碼，MyBatis，Netty,redis,Kafka,MySQL,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點(diǎn)的架構(gòu)資料）合理利用自己每一分每一秒的時間來學(xué)習(xí)提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！
重慶分公司
重慶分公司
