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