作者簡介：李智慧，前阿里巴巴技術(shù)專家。本文選自：拉勾教育專欄《架構(gòu)師的36項(xiàng)修煉》
就程序員而言，日后的職業(yè)發(fā)展可以走3個(gè)方向：專攻技術(shù)深度、轉(zhuǎn)團(tuán)隊(duì)管理、晉升架構(gòu)師。
成為一名優(yōu)秀的架構(gòu)師，是大多數(shù)技術(shù)人的追求。
但資深架構(gòu)師的出現(xiàn)幾率僅約為0.3%，如果想在3-5年后穩(wěn)坐金字塔尖，必須有扎實(shí)的代碼功底和項(xiàng)目積累，也要意識(shí)地培養(yǎng)技術(shù)廣度和架構(gòu)思維能力。多學(xué)習(xí)牛人經(jīng)驗(yàn)也可獲益良多。
我是李智慧，我從事架構(gòu)已有20多年。屏幕前的你，既然選擇了架構(gòu)，就要踏實(shí)學(xué)好每一塊知識(shí)。今天我們來講分布式消息隊(duì)列MQ。在本篇幅中，我會(huì)主要介紹同步架構(gòu)和異步架構(gòu)的區(qū)別。
本文選自：拉勾教育專欄《架構(gòu)師的36項(xiàng)修煉》見文末了解更多
01 同步調(diào)用
所謂的同步調(diào)用，就是說從請(qǐng)求的發(fā)起一直到最終的處理完成期間，請(qǐng)求的調(diào)用方一直在同步阻塞等待調(diào)用的處理完成。
我們看一下圖片中的例子，在這個(gè)例子中客戶端代碼ClientCode，需要執(zhí)行發(fā)送郵件sendEmail這樣一個(gè)操作，它會(huì)調(diào)用EmailService進(jìn)行發(fā)送。
而EmailService會(huì)調(diào)用SmtpEmailAdapter這樣一個(gè)類來進(jìn)行處理，而這個(gè)類會(huì)調(diào)用遠(yuǎn)程的一個(gè)服務(wù)，通過SMTP和TCP協(xié)議把請(qǐng)求發(fā)送給它。
而遠(yuǎn)程服務(wù)器收到消息以后會(huì)對(duì)消息進(jìn)行一系列的操作，然后將郵件發(fā)送出去，再進(jìn)行返回。
Adapter收到返回后，再返回給EmailService，EmailService收到返回后再把返回結(jié)果返回給Clientcode。
ClientCode在sendEmail發(fā)出請(qǐng)求后，就一直都阻塞在這里，等待最終調(diào)用結(jié)果的返回，是成功還是失敗。因?yàn)檫@個(gè)過程是阻塞等待的，所以這個(gè)過程也就是同步調(diào)用。
02 異步調(diào)用
與同步調(diào)用相反的是異步調(diào)用。異步調(diào)用過程，我們同樣看剛剛發(fā)送郵件的例子，用戶Clientcode調(diào)用EmailService以后，EmailService會(huì)把這個(gè)調(diào)用請(qǐng)求發(fā)送給消息隊(duì)列，然后就立即返回了。
Clientcode收到返回以后繼續(xù)向下處理，不會(huì)繼續(xù)阻塞等待。實(shí)際上消息發(fā)送到Queue后，還沒有被處理，我們看到后面的消息消費(fèi)，其實(shí)要比EmailService返回可能還要晚一點(diǎn)，EmailService返回以后消息才會(huì)被消費(fèi)處理。
有一個(gè)QueueConsumer消息隊(duì)列的消費(fèi)者，從消息隊(duì)列中取出這個(gè)消息，再把這個(gè)消息發(fā)送給SmtpAdapter，也就是調(diào)用SmtpAdapter。
處理邏輯跟同步調(diào)用一樣，SmtpAdapter通過SMTP的通訊協(xié)議，把消息發(fā)送給遠(yuǎn)程的一個(gè)服務(wù)器，進(jìn)行郵件發(fā)送，通過RemoteServer進(jìn)行處理，處理完了收到返回，再把返回結(jié)果通知消息隊(duì)列Queue。
我們看到，在這個(gè)過程中，客戶端的調(diào)用，也就是應(yīng)用程序的調(diào)用，和業(yè)務(wù)邏輯真正發(fā)送郵件的操作是不同步的。
在進(jìn)行郵件發(fā)送操作的處理過程中，客戶端的代碼已經(jīng)返回了，它可以繼續(xù)進(jìn)行自己的后續(xù)操作，而不需要等待郵件的發(fā)送，這就叫做異步調(diào)用。
本文選自：拉勾教育專欄《架構(gòu)師的36項(xiàng)修煉》見文末了解更多
使用異步調(diào)用架構(gòu)的主要手段，就是通過消息隊(duì)列構(gòu)建。這是它的架構(gòu)圖。
消息的生產(chǎn)者將消息發(fā)送到消息隊(duì)列以后，由消息的消費(fèi)者從消息隊(duì)列中獲取消息，然后進(jìn)行業(yè)務(wù)邏輯的處理，消息的生產(chǎn)者和消費(fèi)者是異步處理的，彼此不會(huì)等待阻塞，所以叫做異步架構(gòu)。
使用消息隊(duì)列構(gòu)建一個(gè)異步調(diào)用架構(gòu)，你需要了解3種角色，一種是消息的生產(chǎn)者，一種是消息隊(duì)列，還有一種是消息的消費(fèi)者。
01消息的生產(chǎn)者
消息的生產(chǎn)者是客戶端應(yīng)用程序代碼的一部分，用來初始化異步調(diào)用處理流程。
在基于消息隊(duì)列的處理中，生產(chǎn)者的職責(zé)非常少，它要做的就是創(chuàng)建一個(gè)合法的消息，并把這個(gè)消息發(fā)送到消息隊(duì)列中，由應(yīng)用開發(fā)者決定生產(chǎn)者的代碼在哪里執(zhí)行，什么時(shí)候發(fā)送消息。
02消息隊(duì)列
消息隊(duì)列異步架構(gòu)的另一個(gè)主要組成部分就是所謂的消息隊(duì)列。
消息隊(duì)列是消息發(fā)送的目的地和發(fā)給消費(fèi)者的一個(gè)緩沖。消息隊(duì)列實(shí)現(xiàn)的方法有好多種，可以用共享文件夾，也可以用關(guān)系數(shù)據(jù)庫或者NoSQL系統(tǒng)。
當(dāng)然最主要的還是使用專門的分布式消息隊(duì)列服務(wù)器來實(shí)現(xiàn)。
03消息的消費(fèi)者
業(yè)務(wù)架構(gòu)的第三個(gè)重要角色就是消息的消費(fèi)者。消息的消費(fèi)者從消息隊(duì)列中接受并處理消息，消息的消費(fèi)者也是由應(yīng)用開發(fā)者實(shí)現(xiàn)的，但是它是一個(gè)異步處理的組件。
消息的消費(fèi)者不需要知道生產(chǎn)者存在，它只依賴消息隊(duì)列中的消息。消息的消費(fèi)者通常部署在獨(dú)立的服務(wù)器上，和消息的生產(chǎn)者完全隔離，并且可以通過添加硬件的方式進(jìn)行伸縮。
知道以上3種主要角色之后，使用消息隊(duì)列構(gòu)建異步的調(diào)用架構(gòu)，你還需要知道兩種模型：點(diǎn)對(duì)點(diǎn)模型和發(fā)布訂閱模型。
本文選自：拉勾教育專欄《架構(gòu)師的36項(xiàng)修煉》見文末了解更多
點(diǎn)對(duì)點(diǎn)模型
首先來看點(diǎn)對(duì)點(diǎn)模型。消費(fèi)者和生產(chǎn)者只需要知道消息隊(duì)列的名字，生產(chǎn)者發(fā)送消息到消息隊(duì)列中，而消息隊(duì)列的另一端是多個(gè)消費(fèi)者競爭消費(fèi)消息。
每個(gè)到達(dá)消息隊(duì)列的消息只會(huì)被路由到一個(gè)消費(fèi)者中去，所以消費(fèi)者看到的是全部消息的一個(gè)子集。
我們看這張圖，消息的生產(chǎn)者有多個(gè)，消息的消費(fèi)者也有多個(gè)，多個(gè)生產(chǎn)者將消息發(fā)送到消息隊(duì)列中，而有多個(gè)消費(fèi)者去消息隊(duì)列中對(duì)消息進(jìn)行競爭性的消費(fèi)。
每條消息只會(huì)被一個(gè)消費(fèi)者消費(fèi)，每個(gè)消費(fèi)者只會(huì)消費(fèi)消息隊(duì)列中的一部分消息。
發(fā)布訂閱模型
在發(fā)布訂閱模型中，消息可能被發(fā)送到不止一個(gè)消費(fèi)者，生產(chǎn)者發(fā)送消息到一個(gè)主題，而不是隊(duì)列中。
消息被發(fā)布到主題后，就會(huì)被克隆給每一個(gè)訂閱它的消費(fèi)者，每個(gè)消費(fèi)者接收一份消息復(fù)制到自己的私有隊(duì)列。
消費(fèi)者可以獨(dú)立于其他消費(fèi)者使用自己訂閱的消息，消費(fèi)者之間不會(huì)競爭消息。
常用的分布式消息隊(duì)列都支持發(fā)布訂閱模型，也就是說消息的發(fā)布訂閱模型是分布式消息隊(duì)列的一個(gè)功能特性。
兩種模型結(jié)合對(duì)比來看，通常使用點(diǎn)對(duì)點(diǎn)模型的，是一些耗時(shí)較長的、邏輯相對(duì)獨(dú)立的業(yè)務(wù)，比如說我前面的講到的發(fā)送郵件這樣一個(gè)操作。
因?yàn)榘l(fā)送郵件比較耗時(shí)，而且應(yīng)用程序其實(shí)也并不太關(guān)心郵件發(fā)送是否成功，發(fā)送郵件的邏輯也相對(duì)比較獨(dú)立，所以它只需要把郵件消息丟到消息隊(duì)列中就可以返回了。
而消費(fèi)者也不需要關(guān)心是哪個(gè)生產(chǎn)者去發(fā)送的郵件，它只需要把郵件消息內(nèi)容取出來以后進(jìn)行消費(fèi)，通過遠(yuǎn)程服務(wù)器將郵件發(fā)送出去就可以了。而且每個(gè)郵件只需要被發(fā)送一次。所以消息只被一個(gè)消費(fèi)者消費(fèi)就可以了。
相對(duì)應(yīng)的另一種情況，比如新用戶注冊(cè)，一個(gè)新用戶注冊(cè)成功以后，需要給用戶發(fā)送一封激活郵件，發(fā)送一條歡迎短信，還需要將用戶注冊(cè)數(shù)據(jù)寫入數(shù)據(jù)庫，甚至需要將新用戶信息發(fā)送給關(guān)聯(lián)企業(yè)的系統(tǒng)，比如淘寶新用戶信息發(fā)送給支付寶。
這樣允許用戶可以一次注冊(cè)就能登錄使用多個(gè)關(guān)聯(lián)產(chǎn)品。那么對(duì)于新用戶注冊(cè)這樣一個(gè)消息，就需要使用按主題發(fā)布的方式，也就是發(fā)布訂閱模型這種方式。
一個(gè)新用戶注冊(cè)，會(huì)把注冊(cè)消息發(fā)送給一個(gè)主題，多種消費(fèi)者可以訂閱這個(gè)主題。比如發(fā)送郵件的消費(fèi)者、發(fā)送短信的消費(fèi)者、將注冊(cè)信息寫入數(shù)據(jù)庫的消費(fèi)者，跨系統(tǒng)同步消息的消費(fèi)者等。
今天就講到這里啦~感謝你的堅(jiān)持，下一課我會(huì)詳細(xì)講解分布式數(shù)據(jù)庫相關(guān)內(nèi)容，分享我的實(shí)踐經(jīng)驗(yàn)。加油，我們不見不散！
本文選自：拉勾教育專欄《架構(gòu)師的36項(xiàng)修煉》見文末了解更多
版權(quán)聲明：本文版權(quán)歸屬拉勾教育及該專欄作者，任何媒體、網(wǎng)站或個(gè)人未經(jīng)本網(wǎng)協(xié)議授權(quán)不得轉(zhuǎn)載、鏈接、轉(zhuǎn)貼或以其他方式復(fù)制發(fā)布/發(fā)表，違者必究。
