摘自：《大型網站技術架構》 李智慧
1 訊息驅動架構     訊息驅動架構（Event Driven Architecture） ：通過在底耦合的模組之間傳輸事件訊息，以保持模組的鬆散耦合，並藉助事件訊息的通訊完成模組間合作，典型的EDA架構就是作業系統中常見的生產者消費者模式。     在大型網站中最常用的是分散式訊息佇列：               訊息佇列利用”釋出—訂閱者模式“工作，訊息傳送者釋出訊息，一個或者多個訊息接受者訂閱訊息。訊息傳送者是訊息源，在對訊息進行處理後將訊息傳送至分散式訊息佇列，訊息訊息接受者從分散式訊息佇列獲取該訊息後繼續進行處理。       鬆耦合：可以看到，訊息傳送者和訊息接收者之間沒有直接耦合，訊息傳送者將訊息傳送至分散式訊息佇列即結束對訊息的處理，而訊息接收者只需要從分散式訊息佇列獲取訊息後進行處理，不需要知道該訊息從何而來。 訊息接收者在對訊息進行過濾、處理、包裝後，構成一個新的訊息型別，將訊息繼續傳送出去，等待其他訊息接收者訂閱處理該訊息。因此基於事件驅動的業務架構可以是一系列的流程。 2 分散式訊息佇列     首先跟一般佇列一樣是一種先進先出的資料結構。分散式訊息佇列可以看做將這種資料結構部署到獨立的伺服器上，通過遠端訪問介面使用分散式訊息佇列，進行訊息儲存操作，進而實現分散式的非同步呼叫，基本原理如圖：

如上圖所示，我們可以明確三個步湊：

　　①訊息生產者應用程式通過遠端訪問介面將訊息推送給訊息佇列伺服器，訊息佇列伺服器將訊息寫入本地記憶體佇列後馬上返回成功響應給訊息生產者。

　　②訊息佇列伺服器根據訊息訂閱列表查詢訂閱該訊息的消費者應用程式，將訊息佇列中的訊息按照先進先出的原則將訊息通過遠端通訊介面傳送給消費者應用程式；

　　③消費者應用程式接收到推送過來的訊息之後進行相關的一系列處理，過程終止；

伸縮性：將新伺服器加入到分散式訊息佇列叢集中，通知生產者伺服器更改訊息佇列服務列表即可。 可用性：為了避免消費者程序處理緩慢，分散式訊息伺服器記憶體空間不足的問題，如果記憶體佇列已滿，會將訊息寫入磁碟，訊息推送模組在將記憶體佇列中的訊息處理完後，將磁碟內容載入到記憶體佇列繼續處理。     為了避免訊息佇列伺服器宕機造成訊息丟失，可以將訊息成功傳送到訊息佇列的訊息儲存在訊息生產者伺服器，等訊息真正被訊息消費者伺服器處理後才刪除訊息。     訊息佇列伺服器宕機，生產者選擇分散式訊息佇列伺服器中的其他機器。 3 ”釋出/訂閱“模式     “釋出/訂閱”模式包含兩種角色，分別是釋出者和訂閱者。訂閱者可以訂閱一個或若干個頻道（channel），而釋出者可以向指定的頻道傳送訊息，所有訂閱此頻道的訂閱者都會收到此訊息。       對任務 ”釋出/訂閱“模式很容易想到可以 使用訊息佇列實現的，Redis中就包含釋出訂閱模式的命令。