分散式佇列程式設計：模型、實戰

介紹

作為一種基礎的抽象資料結構，佇列被廣泛應用在各類程式設計中。大資料時代對跨程式、跨機器的通訊提出了更高的要求，和以往相比，分散式佇列程式設計的運用幾乎已無處不在。但是，這種常見的基礎性的事物往往容易被忽視，使用者往往會忽視兩點：

• 使用分散式佇列的時候，沒有意識到它是佇列。
• 有具體需求的時候，忘記了分散式佇列的存在。

文章首先從最基礎的需求出發，詳細剖析分散式佇列程式設計模型的需求來源、定義、結構以及其變化多樣性。通過這一部分的講解，作者期望能在兩方面幫助讀者：一方面，提供一個系統性的思考方法，使讀者能夠將具體需求關聯到分散式佇列程式設計模型，具備進行分散式佇列架構的能力；另一方面，通過全方位的講解，讓讀者能夠快速識別工作中碰到的各種分散式佇列程式設計模型。

文章的第二部分實戰篇。根據作者在新美大實際工作經驗，給出了佇列式程式設計在分散式環境下的一些具體應用。這些例子的基礎模型並非首次出現在網際網路的文件中，但是所有的例子都是按照挑戰、構思、架構三個步驟進行講解的。這種講解方式能給讀者一個“從需求出發去構架分散式佇列程式設計”的旅程。

分散式佇列程式設計模型

模型篇從基礎的需求出發，去思考何時以及如何使用分散式佇列程式設計模型。建模環節非常重要，因為大部分中高階工程師面臨的都是具體的需求，接到需求後的第一個步驟就是建模。通過本篇的講解，希望讀者能夠建立起從需求到分散式佇列程式設計模型之間的橋樑。

何時選擇分散式佇列

通訊是人們最基本的需求，同樣也是計算機最基本的需求。對於工程師而言，在程式設計和技術選型的時候，更容易進入大腦的概念是RPC、RESTful、Ajax、Kafka。在這些具體的概念後面，最本質的東西是“通訊”。所以，大部分建模和架構都需要從“通訊”這個基本概念開始。當確定系統之間有通訊需求的時候，工程師們需要做很多的決策和平衡，這直接影響工程師們是否會選擇分散式佇列程式設計模型作為架構。從這個角度出發，影響建模的因素有四個：When、Who、Where、How。

When：同步VS非同步

通訊的一個基本問題是：發出去的訊息什麼時候需要被接收到？這個問題引出了兩個基礎概念：“同步通訊”和“非同步通訊”。根據理論抽象模型，同步通訊和非同步通訊最本質的差別來自於時鐘機制的有無。同步通訊的雙方需要一個校準的時鐘，非同步通訊的雙方不需要時鐘。現實的情況是，沒有完全校準的時鐘，所以沒有絕對的同步通訊。同樣，絕對非同步通訊意味著無法控制一個發出去的訊息被接收到的時間點，無期限的等待一個訊息顯然毫無實際意義。所以，實際程式設計中所有的通訊既不是“同步通訊”也不是“非同步通訊”；或者說，既是“同步通訊”也是“非同步通訊”。特別是對於應用層的通訊，其底層架構可能既包含“同步機制”也包含“非同步機制”。判斷“同步”和“非同步”訊息的標準問題太深，而不適合繼續展開。作者這裡給一些啟發式的建議：

• 發出去的訊息是否需要確認，如果不需要確認，更像是非同步通訊，這種通訊有時候也稱為單向通訊（One-Way Communication）。
• 如果需要確認，可以根據需要確認的時間長短進行判斷。時間長的更像是非同步通訊，時間短的更像是同步通訊。當然時間長短的概念是純粹的主觀概念，不是客觀標準。
• 發出去的訊息是否阻塞下一個指令的執行，如果阻塞，更像是同步，否則，更像是非同步。

無論如何，工程師們不能生活在混沌之中，不做決定往往是最壞的決定。當分析一個通訊需求或者進行通訊構架的時候，工程師們被迫作出“同步”還是“非同步”的決定。當決策的結論是“非同步通訊”的時候，分散式佇列程式設計模型就是一個備選項。

Who：傳送者接收者解耦

在進行通訊需求分析的時候，需要回答的另外一個基本問題是：訊息的傳送方是否關心誰來接收訊息，或者反過來，訊息接收方是否關心誰來傳送訊息。如果工程師的結論是：訊息的傳送方和接收方不關心對方是誰、以及在哪裡，分散式佇列程式設計模型就是一個備選項。因為在這種場景下，分散式佇列架構所帶來的解耦能給系統架構帶來這些好處：

• 無論是傳送方還是接收方，只需要跟訊息中介軟體通訊，介面統一。統一意味著降低開發成本。
• 在不影響效能的前提下，同一套訊息中介軟體部署，可以被不同業務共享。共享意味著降低運維成本。
• 傳送方或者接收方單方面的部署拓撲的變化不影響對應的另一方。解藕意味著靈活和可擴充套件。

Where：訊息暫存機制

在進行通訊傳送方設計的時候，令工程師們苦惱的問題是：如果訊息無法被迅速處理掉而產生堆積怎麼辦、能否被直接拋棄？如果根據需求分析，確認存在訊息積存，並且訊息不應該被拋棄，就應該考慮分散式佇列程式設計模型構架，因為佇列可以暫存訊息。

How：如何傳遞

對通訊需求進行架構，一系列的基礎挑戰會迎面而來，這包括：

• 可用性，如何保障通訊的高可用。
• 可靠性，如何保證訊息被可靠地傳遞。
• 持久化，如何保證訊息不會丟失。
• 吞吐量和響應時間。
• 跨平臺相容性。
  除非工程師對造輪子有足夠的興趣，並且有充足的時間，採用一個滿足各項指標的分散式佇列程式設計模型就是一個簡單的選擇。

分散式佇列程式設計定義

很難給出分散式佇列程式設計模型的精確定義，由於本文偏重於應用，作者並不打算完全參照某個標準的模型。總體而言：分散式佇列程式設計模型包含三類角色：傳送者（Sender）、分散式佇列（Queue）、接收者（Receiver）。傳送者和接收者分別指的是生產訊息和接收訊息的應用程式或服務。

需要重點明確的概念是分散式佇列，它是提供以下功能的應用程式或服務：1. 接收“傳送者”產生的訊息實體；2. 傳輸、暫存該實體；3. 為“接收者”提供讀取該訊息實體的功能。特定的場景下，它當然可以是Kafka、RabbitMQ等訊息中介軟體。但它的展現形式並不限於此，例如：

• 佇列可以是一張資料庫的表，傳送者將訊息寫入表，接收者從資料表裡讀訊息。
• 如果一個程式把資料寫入Redis等記憶體Cache裡面，另一個程式從Cache裡面讀取，快取在這裡就是一種分散式佇列。
• 流式程式設計裡面的的資料流傳輸也是一種佇列。
• 典型的MVC（Model–view–controller）設計模式裡面，如果Model的變化需要導致View的變化，也可以通過佇列進行傳輸。這裡的分散式佇列可以是資料庫，也可以是某臺伺服器上的一塊記憶體。

抽象模型

最基礎的分散式佇列程式設計抽象模型是點對點模型，其他抽象構架模型居於改基本模型上各角色的數量和互動變化所導致的不同拓撲圖。具體而言，不同數量的傳送者、分散式佇列以及接收者組合形成了不同的分散式佇列程式設計模型。記住並理解典型的抽象模型結構對需求分析和建模而言至關重要，同時也會有助於學習和深入理解開源框架以及別人的程式碼。

點對點模型（Point-to-point）

基礎模型中，只有一個傳送者、一個接收者和一個分散式佇列。如下圖所示：

生產者消費者模型（Producer–consumer）

如果傳送者和接收者都可以有多個部署例項，甚至不同的型別；但是共用同一個佇列，這就變成了標準的生產者消費者模型。在該模型，三個角色一般稱之為生產者（Producer）、分散式佇列（Queue）、消費者（Consumer）。

釋出訂閱模型（PubSub）

如果只有一類傳送者，傳送者將產生的訊息實體按照不同的主題（Topic）分發到不同的邏輯佇列。每種主題佇列對應於一類接收者。這就變成了典型的釋出訂閱模型。在該模型，三個角色一般稱之為釋出者（Publisher），分散式佇列（Queue），訂閱者（Subscriber）。

MVC模型

如果傳送者和接收者存在於同一個實體中，但是共享一個分散式佇列。這就很像經典的MVC模型。

程式設計模型

為了讓讀者更好地理解分散式佇列程式設計模式概念，這裡將其與一些容易混淆的概念做一些對比 。

分散式佇列模型程式設計和非同步程式設計

分散式佇列程式設計模型的通訊機制一般是採用非同步機制，但是它並不等同於非同步程式設計。

首先，並非所有的非同步程式設計都需要引入佇列的概念，例如：大部分的作業系統非同步I/O操作都是通過硬體中斷（ Hardware Interrupts）來實現的。

其次，非同步程式設計並不一定需要跨程式，所以其應用場景並不一定是分散式環境。

最後，分散式佇列程式設計模型強調傳送者、接收者和分散式佇列這三個角色共同組成的架構。這三種角色與非同步程式設計沒有太多關聯。

分散式佇列模式程式設計和流式程式設計

隨著Spark Streaming，Apache Storm等流式框架的廣泛應用，流式程式設計成了當前非常流行的程式設計模式。但是本文所闡述的分散式佇列程式設計模型和流式程式設計並非同一概念。

首先，本文的佇列程式設計模式不依賴於任何框架，而流式程式設計是在具體的流式框架內的程式設計。

其次，分散式佇列程式設計模型是一個需求解決方案，關注如何根據實際需求進行分散式佇列程式設計建模。流式框架裡的資料流一般都通過佇列傳遞，不過，流式程式設計的關注點比較聚焦，它關注如何從流式框架裡獲取訊息流，進行map、reduce、 join等轉型（Transformation）操作、生成新的資料流，最終進行彙總、統計。

分散式佇列程式設計實戰篇

這裡所有的專案都是作者在新美大工作的真實案例。實戰篇的關注點是訓練建模思路，所以這些例子都按照挑戰、構思、架構三個步驟進行講解。受限於保密性要求，有些細節並未給出，但這些細節並不影響講解的完整性。另一方面，特別具體的需求容易讓人費解，為了使講解更加順暢，作者也會採用一些更通俗易懂的例子。通過本篇的講解，希望和讀者一起去實踐“如何從需求出發去構架分散式佇列程式設計模型”。

需要宣告的是，這裡的解決方案並不是所處場景的最優方案。但是，任何一個稍微複雜的問題，都沒有最優解決方案，更談不上唯一的解決方案。實際上，工程師每天所追尋的只是在滿足一定約束條件下的可行方案。當然不同的約束會導致不同的方案，約束的鬆弛度決定了工程師的可選方案的寬廣度。

資訊採集處理

資訊採集處理應用廣泛，例如：廣告計費、使用者行為收集等。作者碰到的具體專案是為廣告系統設計一套高可用的採集計費系統。

典型的廣告CPC、CPM計費原理是：收集使用者在客戶端或者網頁上的點選和瀏覽行為，按照點選和瀏覽進行計費。計費業務有如下典型特徵：

• 採集者和處理者解耦，採集發生在客戶端，而計費發生在服務端。
• 計費與錢息息相關。
• 重複計費意味著災難。
• 計費是動態實時行為，需要接受預算約束，如果消耗超過預算，則廣告投放需要停止。
• 使用者的瀏覽和點選量非常大。

挑戰

計費業務的典型特徵給我們帶來了如下挑戰：

• 高吞吐量－－廣告的瀏覽和點選量非常巨大，我們需要設計一個高吞吐量的採集架構。
• 高可用性－－計費資訊的丟失意味著直接的金錢損失。任何處理伺服器的崩潰不應該導致系統不可用。
• 高一致性要求－－計費是一個實時動態處理過程，但要受到預算的約束。收集到的瀏覽和點選行為如果不能快速處理，可能會導致預算花超，或者點選率預估不準確。所以採集到的資訊應該在最短的時間內傳輸到計費中心進行計費。
• 完整性約束－－這包括反作弊規則，單個使用者行為不能重複計費等。這要求計費是一個集中行為而非分散式行為。
• 持久化要求－－計費資訊需要持久化，避免因為機器崩潰而導致收集到的資料產生丟失。

構思

採集的高可用性意味著我們需要多臺伺服器同時採集，為了避免單IDC故障，採集伺服器需要部署在多IDC裡面。
實現一個高可用、高吞吐量、高一致性的資訊傳遞系統顯然是一個挑戰，為了控制專案開發成本，採用開源的訊息中介軟體進行訊息傳輸就成了必然選擇。

完整性約束要求集中進行計費，所以計費系統發生在核心IDC。

計費服務並不關心採集點在哪裡，採集服務也並不關心誰進行計費。

根據以上構思，我們認為採集計費符合典型的“生產者消費者模型”。

架構

採集計費系統架構圖如下：

• 使用者點選瀏覽收集服務（Click/View Collector）作為生產者部署在多個機房裡，以提高收集服務可用性。
• 每個機房裡採集到的資料通過訊息佇列中介軟體傳送到核心機房IDC_Master。
• Billing服務作為消費者部署在核心機房集中計費。
  

採用此架構，我們可以在如下方面做進一步優化：

• 提高可擴充套件性，如果一個Billing部署例項在效能上無法滿足要求，可以對採集的資料進行主題分割槽（Topic Partition）計費，即採用釋出訂閱模式以提高可擴充套件性（Scalability）。
• 全域性排重和反作弊。採用集中計費架構解決了點選瀏覽排重的問題，另一方面，這也給反作弊提供了全域性資訊。
• 提高計費系統的可用性。採用下文單例服務優化策略，在保障計費系統集中性的同時，提高計費系統可用性。

分散式快取更新（Distributed Cache Replacement）

快取是一個非常寬泛的概念，幾乎存在於系統各個層級。典型的快取訪問流程如下：

• 接收到請求後，先讀取快取，如果命中則返回結果。
• 如果快取不命中，讀取DB或其它持久層服務，更新快取並返回結果。
  對於已經存入快取的資料，其更新時機和更新頻率是一個經典問題，即快取更新機制（Cache Replacement Algorithms ）。典型的快取更新機制包括：近期最少使用演算法（LRU）、最不經常使用演算法（LFU）。這兩種快取更新機制的典型實現是：啟動一個後臺程式，定期清理最近沒有使用的，或者在一段時間內最少使用的資料。由於存在快取驅逐機制，當一個請求在沒有命中快取時，業務層需要從持久層中獲取資訊並更新快取，提高一致性。

挑戰

分散式快取給快取更新機制帶來了新的問題：

• 資料一致性低。分散式快取中鍵值數量巨大，從而導致LRU或者LFU演算法更新週期很長。在分散式快取中，拿LRU演算法舉例，其典型做法是為每個Key值設定一個生存時間（TTL），生存時間到期後將該鍵值從快取中驅逐除去。考慮到分散式快取中龐大的鍵值數量，生存時間往往會設定的比較長，這就導致快取和持久層資料不一致時間很長。如果生存時間設定過短，大量請求無法命中快取被迫讀取持久層，系統響應時間會急劇惡化。
• 新資料不可用。在很多場景下，由於分散式快取和持久層的訪問效能相差太大，在快取不命中的情況下，一些應用層服務不會嘗試讀取持久層，而直接返回空結果。漫長的快取更新週期意味著新資料的可用性就被犧牲了。從統計的角度來講，新鍵值需要等待半個更新週期才會可用。

構思

根據上面的分析，分散式快取需要解決的問題是：在保證讀取效能的前提下，儘可能地提高老資料的一致性和新資料的可用性。如果仍然假定最近被訪問的鍵值最有可能被再次訪問（這是LRU或者LFU成立的前提），鍵值每次被訪問後觸發一次非同步更新就是提高可用性和一致性最早的時機。無論是高效能要求還是業務解耦都要求快取讀取和快取更新分開，所以我們應該構建一個單獨的集中的快取更新服務。集中進行快取更新的另外一個好處來自於頻率控制。由於在一段時間內，很多型別訪問鍵值的數量滿足高斯分佈，短時間內重複對同一個鍵值進行更新Cache並不會帶來明顯的好處，甚至造成快取效能的下降。通過控制同一鍵值的更新頻率可以大大緩解該問題，同時有利於提高整體資料的一致性，參見“排重優化”。

綜上所述，業務訪問方需要把請求鍵值快速傳輸給快取更新方，它們之間不關心對方的業務。要快速、高效能地實現大量請求鍵值訊息的傳輸，高效能分散式訊息中介軟體就是一個可選項。這三方一起組成了一個典型的分散式佇列程式設計模型。

架構

如下圖，所有的業務請求方作為生產者，在返回業務程式碼處理之前將請求鍵值寫入高效能佇列。Cache Updater作為消費者從佇列中讀取請求鍵值，將持久層中資料更新到快取中。

採用此架構，我們可以在如下方面做進一步優化：

• 提高可擴充套件性，如果一個Cache Updater在效能上無法滿足要求，可以對鍵值進行主題分割槽（Topic Partition）進行並行快取更新，即採用釋出訂閱模式以提高可擴充套件性（Scalability）。
• 更新頻率控制。快取更新都集中處理，對於釋出訂閱模式，同一類主題（Topic）的鍵值集中處理。Cache Updater可以控制對同一鍵值的在短期內的更新頻率（參見下文排重優化）。

後臺任務處理

典型的後臺任務處理應用包括工單處理、火車票預訂系統、機票選座等。我們所面對的問題是為運營人員建立工單。一次可以為多個運營人員建立多個工單。這個應用場景和火車票購買非常類似。工單相對來說更加抽象，所以，下文會結合火車票購買和運營人員工單分配這兩種場景同時講解。典型的工單建立要經歷兩個階段：資料篩選階段、工單建立階段。例如，在火車票預訂場景，資料篩選階段使用者選擇特定時間、特定型別的火車，而在工單建立階段，使用者下單購買火車票。

挑戰

工單建立往往會面臨如下挑戰：

• 資料一致性問題。以火車票預訂為例，使用者篩選火車票和最終購買之間往往有一定的時延，意味著兩個操作之間資料是不一致的。在篩選階段，工程師們需決定是否進行車票鎖定，如果不鎖定，則無法保證出票成功。反之，如果在篩選地時候鎖定車票，則會大大降低系統效率和出票吞吐量。
• 約束問題。工單建立需要滿足很多約束，主要包含兩種型別：動態約束，與操作者的操作行為有關，例如購買幾張火車票的決定往往發生在篩選最後階段。隱性約束，這種約束很難通過介面進行展示，例如一個使用者購買了5張火車票，這些票應該是在同一個車廂的臨近位置。
• 優化問題。工單建立往往是約束下的優化，這是典型的統籌優化問題，而統籌優化往往需要比較長的時間。
• 響應時間問題。對於多工工單，一個請求意味著多個任務產生。這些任務的建立往往需要遵循事務性原則，即All or Nothing。在資料層面，這意味著工單之間需要滿足序列化需求（Serializability）。大資料量的序列化往往意味著鎖衝突延遲甚至失敗。無論是延遲機制所導致的長時延，還是高建立失敗率，都會大大傷害使用者體驗。

構思

如果將使用者篩選的最終規則做為訊息儲存下來，併傳送給工單建立系統。此時，工單建立系統將具備建立工單所需的全域性資訊，具備在滿足各種約束的條件下進行統籌優化的能力。如果工單建立階段採用單例項部署，就可以避免資料鎖定問題，同時也意味著沒有鎖衝突，所以也不會有死鎖或任務延遲問題。
居於以上思路，在多工單處理系統的模型中，篩選階段的規則建立系統將充當生產者角色，工單建立系統將充當消費者角色，篩選規則將作為訊息在兩者之間進行傳遞。這就是典型的分散式佇列程式設計架構。根據工單建立量的不同，可以採用資料庫或開源的分散式訊息中介軟體作為分散式佇列。

架構

該架構流程如下圖：

• 使用者首選進行規則建立，這個過程主要是一些搜尋篩選操作；
• 使用者點選工單建立，TicketRule Generator將把所有的篩選性組裝成規則訊息併傳送到佇列裡面去；
• Ticket Generator作為一個消費者，實時從佇列中讀取工單建立請求，開始真正建立工單。
  
  採用該架構，我們在資料鎖定、運籌優化、原子性問題都能得到比較好成果：
• 資料鎖定推遲到工單建立階段，可以減少資料鎖定範圍，最大程度的降低工單建立對其他線上操作的影響範圍。
• 如果需要進行統籌優化，可以將Ticket Generator以單例模式進行部署（參見單例服務優化）。這樣，Ticket Generator可以讀取一段時間內的工單請求，進行全域性優化。例如，在我們的專案中，在某種條件下，運營人員需要滿足分級公平原則，即相同級別的運營人員的工單數量應該接近，不同級別的運營人員工單數量應該有所區分。如果不集中進行統籌優化，實現這種優化規則將會很困難。
• 保障了約束完整性。例如，在我們的場景裡面，每個運營人員每天能夠處理的工單是有數量限制的，如果採用並行處理的方式，這種完整性約束將會很難實施。

參考資料

[1] RabbitMQ, Highly Available Queues.
[2] IBM Knowledge Center, Introduction to message queuing.
[3] Wikipedia, Serializability.
[4] Hadoop, ZooKeeper Recipes and Solutions.
[5] Apache Kafka.
[6] Lamport L, Paxos Made Simple.