前言

“分散式佇列程式設計”是一個系列文，之前我們已經發布了《分散式佇列程式設計模型、實戰》，主要剖析了分散式佇列程式設計模型的需求來源、定義、結構以及其變 化多樣性；根據作者在新美大實際工作經驗，給出了佇列式程式設計在分散式環境下的一些具體應用。本文將重點闡述工程師運用分散式佇列程式設計構架的時候，在生產 者、分散式佇列以及消費者這三個環節的注意點以及優化建議。

確定採用分散式佇列程式設計模型之後，主體架構就算完成了，但工程師的工作還遠遠未結束。天下事必做於細，細節是一個不錯的架構向一個優秀的系統進階的 關鍵因素。優化篇選取了作者以及其同事在運用分散式佇列程式設計模型架構時所碰到的典型問題和解決方案。這裡些問題出現的頻率較高，如果你經驗不夠，很可能會 “踩坑”。希望通過這些講解，幫助讀者降低分散式佇列程式設計模型的使用門檻。本文將對分散式佇列程式設計模型的三種角色：生產者（Producer），分散式隊 列（Queue），消費者（Consumer）分別進行優化討論。

生產者優化

在分散式佇列程式設計中，生產者往往並非真正的生產源頭，只是整個資料流中的一個節點，這種生產者的操作是處理－轉發（Process-Forward）模式。

這種模式給工程師們帶來的第一個問題是吞吐量問題。這種模式下執行的生產者，一邊接收上游的資料，一邊將處理完的資料傳送給下游。本質上，它是一個 非常經典的數學問題，其抽象模型是一些沒有蓋子的水箱，每個水箱接收來自上一個水箱的水，進行處理之後，再將水傳送到下一個水箱。工程師需要預測水源的流 量、每個環節水箱的處理能力、水龍頭的排水速度，最終目的是避免水溢位水箱，或者儘可能地減小溢位事件的概率。實際上流式程式設計框架以及其開發者花了大量的 精力去處理和優化這個問題。下文的快取優化和批量寫入優化都是針對該問題的解決方案。

第二個需要考慮的問題是持久化。由於各種原因，系統總是會當機。如果資訊比較敏感，例如計費資訊、火車票訂單資訊等，工程師們需要考慮系統當機所帶來的損失，找到讓損失最小化的解決方案。持久化優化重點解決這一類問題。

快取優化

處於“處理－轉發”模式下執行的生產者往往被設計成請求驅動型的服務，即每個請求都會觸發一個處理執行緒，執行緒處理完後將結果寫入分散式佇列。如果由於某種原因佇列服務不可用，或者效能惡化，隨著新請求的到來，生產者的處理執行緒就會產生堆積。這可能會導致如下兩個問題：

• 系統可用性降低。由於每個執行緒都需要一定的記憶體開銷，執行緒過多會使系統記憶體耗盡，甚至可能產生雪崩效應導致最終完全不可用。
• 資訊丟失。為了避免系統崩潰，工程師可能會給請求驅動型服務設定一個處理執行緒池，設定最大處理執行緒數量。這是一種典型的降級策略，目的是為了系統 崩潰。但是，後續的請求會因為沒有處理執行緒而被迫阻塞，最終可能產生資訊丟失。例如：對於廣告計費採集，如果採集系統因為執行緒耗盡而不接收客戶端的計費行 為，這些計費行為就會丟失。

緩解這類問題的思路來自於CAP理論，即通過降低一致性來提高可用性。生產者接收執行緒在收到請求之後第一時間不去處理，直接將請求快取在記憶體中（犧 牲一致性），而在後臺啟動多個處理執行緒從快取中讀取請求、進行處理並寫入分散式佇列。與執行緒所佔用的記憶體開銷相比，大部分的請求所佔記憶體幾乎可以忽略。通 過在接收請求和處理請求之間增加一層記憶體快取，可以大大提高系統的處理吞吐量和可擴充套件性。這個方案本質上是一個記憶體生產者消費者模型。

批量寫入優化

如果生產者的請求過大，寫分散式佇列可能成為效能瓶頸，有如下幾個因素：

• 佇列自身效能不高。
• 分散式佇列程式設計模型往往被應用在跨機房的系統裡面，跨機房的網路開銷往往容易成為系統瓶頸。
• 訊息確認機制往往會大大降低佇列的吞吐量以及響應時間。

如果在處理請求和寫佇列之間新增一層快取，訊息寫入程式批量將訊息寫入佇列，可以大大提高系統的吞吐量。原因如下：

• 批量寫佇列可以大大減少生產者和分散式佇列的互動次數和訊息傳輸量。特別是對於高吞吐小載荷的訊息實體，批量寫可以顯著降低網路傳輸量。
• 對於需要確認機制的訊息，確認機制往往會大大降低佇列的吞吐量以及響應時間，某些高敏感的訊息需要多個訊息中介軟體代理同時確認，這近一步惡化性 能。在生產者的應用層將多條訊息批量組合成一個訊息體，訊息中介軟體就只需要對批量訊息進行一次確認，這可能會數量級的提高訊息傳輸效能。

持久化優化

通過新增快取，消費者服務的吞吐量和可用性都得到了提升。但快取引入了一個新問題——記憶體資料丟失。對於敏感資料，工程師需要考慮如下兩個潛在問題：

• 如果記憶體中存在未處理完的請求，而某些原因導致生產者服務當機，記憶體資料就會丟失而可能無法恢復。
• 如果分散式佇列長時間不可用，隨著請求數量的不斷增加，最終系統記憶體可能會耗盡而崩潰，記憶體的訊息也可能丟失。

所以快取中的資料需要定期被持久化到磁碟等持久層裝置中，典型的持久化觸發策略主要有兩種：

• 定期觸發，即每隔一段時間進行一次持久化。
• 定量觸發，即每當快取中的請求數量達到一定閾值後進行持久化。
  是否需要持久化優化，以及持久化策略應該由請求資料的敏感度、請求量、持久化效能等因素共同決定。

中介軟體選型

分散式佇列不等同於各種開源的或者收費的訊息中介軟體，甚至在一些場景下完全不需要使用訊息中介軟體。但是，訊息中介軟體產生的目的就是解決訊息傳遞問題，這為分散式佇列程式設計架構提供了很多的便利。在實際工作中，工程師們應該將成熟的訊息中介軟體作為佇列的首要備選方案。
本小節對訊息中介軟體的功能、模型進行闡述，並給出一些訊息中介軟體選型、部署的具體建議。

中介軟體的功能

明白一個系統的每個具體功能是設計和架構一個系統的基礎。典型的訊息中介軟體主要包含如下幾個功能：

• 訊息接收
• 訊息分發
• 訊息儲存
• 訊息讀取

概念模型

抽象的訊息中介軟體模型包含如下幾個角色：

• 傳送者和接收者客戶端（Sender/Receiver Client），在具體實施過程中，它們一般以庫的形式嵌入到應用程式程式碼中。
• 代理伺服器（Broker Server），它們是與客戶端程式碼直接互動的服務端程式碼。
• 訊息交換機（Exchanger），接收到的訊息一般需要通過訊息交換機（Exchanger）分發到具體的訊息佇列中。
• 訊息佇列，一般是一塊記憶體資料結構或持久化資料。
  概念模型如下圖：
  
  為了提高分發效能，很多訊息中介軟體把訊息代理伺服器的拓撲圖傳送到傳送者和接收者客戶端（Sender/Receiver Client），如此一來，傳送源可以直接進行訊息分發。

選型標準

要完整的描述訊息中介軟體各個方面非常困難，大部分良好的訊息中介軟體都有完善的文件，這些文件的長度遠遠超過本文的總長度。但如下幾個標準是工程師們在進行訊息中介軟體選型時經常需要考慮和權衡的。

效能

效能主要有兩個方面需要考慮：吞吐量（Throughput）和響應時間（Latency）。
不同的訊息佇列中介軟體的吞吐量和響應時間相差甚遠，在選型時可以去網上檢視一些效能對比報告。
對於同一種中介軟體，不同的配置方式也會影響效能。主要有如下幾方面的配置：

• 是否需要確認機制，即寫入佇列後，或從佇列讀取後，是否需要進行確認。確認機制對響應時間的影響往往很大。
• 能否批處理，即訊息能否批量讀取或者寫入。批量操作可以大大減少應用程式與訊息中介軟體的互動次數和訊息傳遞量，大大提高吞吐量。
• 能否進行分割槽（Partition）。將某一主題訊息佇列進行分割槽，同一主題訊息可以有多臺機器並行處理。這不僅僅能影響訊息中介軟體的吞吐量，還決定著訊息中介軟體是否具備良好的可伸縮性（Scalability）。
• 是否需要進行持久化。將訊息進行持久化往往會同時影響吞吐量和響應時間。

可靠性

可靠性主要包含：可用性、持久化、確認機制等。
高可用性的訊息中介軟體應該具備如下特徵：

• 訊息中介軟體代理伺服器（Broker）具有主從備份。即當一臺代理服務當機之後，備用伺服器能接管相關的服務。
• 訊息中介軟體中快取的訊息是否有備份、並持久化。
  根據CAP理論，高可用、高一致性以及網路分裂不可兼得。根據作者的觀察，大部分的訊息中介軟體在面臨網路分裂的情況下下，都很難保證資料的一致性以及可用性。 很多訊息中介軟體都會提供一些可配置策略，讓使用者在可用性和一致性之間做權衡。

高可靠的訊息中介軟體應該確保從傳送者接收到的訊息不會丟失。中介軟體代理伺服器的當機並不是小概率事件，所以儲存在記憶體中的訊息很容易發生丟失。大部分的訊息中介軟體都依賴於訊息的持久化去降低訊息丟失損失，即將接收到的訊息寫入磁碟。即使提供持久化，仍有兩個問題需要考慮：

• 磁碟損壞問題。長時間來看，磁碟出問題的概率仍然存在。
• 效能問題。與操作記憶體相比，磁碟I/O的操作效能要慢幾個數量級。頻繁持久化不僅會增加響應時間，也會降低吞吐量。
  解決這兩個問題的一個 解決方案就是：多機確認，定期持久化。即訊息被快取在多臺機器的記憶體中，只有每臺機器都確認收到訊息，才跟傳送者確認（很多訊息中介軟體都會提供相應的配置 選項，讓使用者設定最少需要多少臺機器接收到訊息）。由於多臺獨立機器同時出故障的概率遵循乘法法則，指數級降低，這會大大提高訊息中介軟體的可靠性。

確認機制本質上是通訊的握手機制（Handshaking）。如果沒有該機制，訊息在傳輸過程中丟失將不會被發現。高敏感的訊息要求選取具備確認機制的訊息中介軟體。當然如果沒有接收到訊息中介軟體確認完成的指令，應用程式需要決定如何處理。典型的做法有兩個：

• 多次重試。
• 暫存到本地磁碟或其它持久化媒介。

客戶端介面所支援語言

採用現存訊息中介軟體就意味著避免重複造輪子。如果某個訊息中介軟體未能提供對應語言的客戶端介面，則意味著極大的成本和相容性問題。

投遞策略（Delivery policies）

投遞策略指的是一個訊息會被髮送幾次。主要包含三種策略：最多一次（At most Once ）、最少一次（At least Once）、僅有一次（Exactly Once）。
在 實際應用中，只考慮訊息中介軟體的投遞策略並不能保證業務的投遞策略，因為接收者在確認收到訊息和處理完訊息並持久化之間存在一個時間視窗。例如，即使訊息 中介軟體保證僅有一次（Exactly Once），如果接收者先確認訊息，在持久化之前當機，則該訊息並未被處理。從應用的角度，這就是最多一次（At most Once）。反之，接收者先處理訊息並完成持久化，但在確認之前當機，訊息就要被再次傳送，這就是最少一次（At least Once）。 如果訊息投遞策略非常重要，應用程式自身也需要仔細設計。

消費者優化

消費者是分散式佇列程式設計中真正的資料處理方，資料處理方最常見的挑戰包括：有序性、序列化（Serializability）、頻次控制、完整性和一致性等。

挑戰

有序性

在很多場景下，如何保證佇列資訊的有序處理是一個棘手的問題。如下圖，假定分散式佇列保證請求嚴格有序，請求ri2和ri1都是針對同一資料記錄的 不同狀態，ri2的狀態比ri1的狀態新。T1、T2、T3和T4代表各個操作發生的時間，並且 T1 < T2 < T3 < T4（”<“代表早於）。
採用多消費者架構，這兩條記錄被兩個消費者（Consumer1和Consumer2）處理後更新到資料庫裡面。Consumer1雖然先讀取ri1但是卻後寫入資料庫，這就導致，新的狀態被老的狀態覆蓋，所以多消費者不保證資料的有序性。

序列化

很多場景下，序列化是資料處理的一個基本需求，這是保證資料完整性、可恢復性、事務原子性等的基礎。為了在平行計算系統裡實現序列化，一系列的相關理論和實踐演算法被提出。對於分散式佇列程式設計架構，要在在多臺消費者實現序列化非常複雜，無異於重複造輪子。

頻次控制

有時候，消費者的消費頻次需要被控制，可能的原因包括：

• 費用問題。如果每次消費所引起的操作都需要收費，而同一個請求訊息在佇列中儲存多份，不進行頻次控制，就會導致無謂的浪費。
• 效能問題。每次消費可能會引起對其他服務的呼叫，被呼叫服務希望對呼叫量有所控制，對同一個請求訊息的多次訪問就需要有所控制。

完整性和一致性

完整性和一致性是所有多執行緒和多程式的程式碼都面臨的問題。在多執行緒或者多程式的系統中考慮完整性和一致性往往會大大地增加程式碼的複雜度和系統出錯的概率。

單例服務優化

幾乎所有序列化理論真正解決的問題只有一個：效能。 所以，在效能允許的前提下，對於消費者角色，建議採用單例項部署。通過單例項部署，有序性、序列化、完整性和一致性問題自動獲得瞭解決。另外，單例項部署的消費者擁有全部所需資訊，它可以在頻次控制上採取很多優化策略。

天下沒有免費的午餐。同樣，單例項部署並非沒有代價，它意味著系統可用性的降低，很多時候，這是無法接受的。解決可用性問題的最直接的思路就是冗餘 （Redundancy）。最常用的冗餘方案是Master-slave架構，不過大部分的Master-slave架構都是Active/active 模式，即主從伺服器都提供服務。例如，資料庫的Master-slave架構就是主從伺服器都提供讀服務，只有主伺服器提供寫服務。大部分基於負載均衡設 計的Master-slave叢集中，主伺服器和從伺服器同時提供相同的服務。這顯然不滿足單例服務優化需求。有序性和序列化需要 Active/passive架構，即在某一時刻只有主例項提供服務，其他的從服務等待主例項失效。這是典型的領導人選舉架構，即只有獲得領導權的例項才 能充當實際消費者，其他例項都在等待下一次選舉。採用領導人選舉的Active/passive架構可以大大緩解純粹的單例項部署所帶來的可用性問題。

令人遺憾的是，除非工程師們自己在消費者例項裡面實現Paxos等演算法，並在每次訊息處理之前都執行領導人選舉。否則，理論上講，沒有方法可以保障 在同一個時刻只有一個領導者。而對每個訊息都執行一次領導人選舉，顯然效能不可行。實際工作中，最容易出現的問題時機發生在領導人交接過程中，即前任領導 人例項變成輔助例項，新部署例項開始承擔領導人角色。為了平穩過渡，這兩者之間需要有一定的通訊機制，但是，無論是網路分割槽（Network partition）還是原領導人服務崩潰都會使這種通訊機制變的不可能。

對於完整性和一致性要求很高的系統，我們需要在選舉制度和交接制度這兩塊進行優化。

領導人選舉架構

典型的領導人選舉演算法有Paxos、ZAB（ ZooKeeper Atomic Broadcast protocol）。為了避免重複造輪子，建議採用ZooKeeper的分散式鎖來實現領導人選舉。典型的ZooKeeper實現演算法如下（摘自參考資料[4]）：

Let ELECTION be a path of choice of the application. To volunteer to be a leader:

1.Create znode z with path “ELECTION/guid-n_” with both SEQUENCE and EPHEMERAL flags;
2.Let C be the children of “ELECTION”, and i be the sequence number of z;
3.Watch for changes on “ELECTION/guid-n_j”, where j is the largest sequence number such that j < i and n_j is a znode in C;

Upon receiving a notification of znode deletion:

1.Let C be the new set of children of ELECTION;
2.If z is the smallest node in C, then execute leader procedure;
3.Otherwise, watch for changes on “ELECTION/guid-n_j”, where j is the largest sequence number such that j < i and n_j is a znode in C;

領導人交接架構

領導人選舉的整個過程發生在ZooKeeper叢集中，各個消費者例項在這場選舉中只充當被告知者角色（Learner）。領導人選舉演算法，只能保 證最終只有一個Leader被選舉出來，並不保障被告知者對Leader的理解是完全一致的。本質上，上文的架構裡，選舉的結果是作為令牌（Token） 傳遞給消費者例項，消費者將自身的ID與令牌進行對比，如果相等，則開始執行消費操作。所以當發生領導人換屆的情況，不同的Learner獲知新 Leader的時間並不同。例如，前任Leader如果因為網路問題與ZooKeeper叢集斷開，前任Leader只能在超時後才能判斷自己是否不再承 擔Leader角色了，而新的Leader可能在這之前已經產生。另一方面，即使前任Leader和新Leader同時接收到新Leader選舉結果，某 些業務的完整性要求迫使前任Leader仍然完成當前未完成的工作。以上的講解非常抽象，生活中卻給了一些更加具體的例子。眾所周知，美國總統候選人在選 舉結束後並不直接擔任美國總統，從選舉到最終承擔總統角色需要一個過渡期。對於新當選Leader的候選人而言，過渡期間稱之為加冕階段 （Inauguration）。對於即將卸任的Leader，過渡期稱為交接階段（HandOver）。所以一個基於領導人選舉的消費者從加冕到卸任經歷 三個階段：Inauguration、Execution、HandOver。在加冕階段，新領導需要進行一些初始化操作。Execution階段是真正 的佇列訊息處理階段。在交接階段，前任領導需要進行一些清理操作。

類似的，為了解決領導人交接問題，所有的消費者從程式碼實現的角度都需要實現類似ILeaderCareer介面。這個介面包含三個方發 inaugurate()，handOver()和execute（）。某個部署例項（Learner）在得知自己承擔領導人角色後，需要呼叫 inaugurate()方法，進行加冕。主要的消費邏輯通過不停的執行execute（）實現，當確認自己不再承擔領導人之後，執行 handOver()進行交接。

如果承擔領導人角色的消費者，在執行execute（）階段得知自己將要下臺，根據訊息處理的原子性，該領導人可以決定是否提前終止操作。如果整個 訊息處理是一個原子性事務，直接終止該操作可以快速實現領導人換屆。否則，前任領導必須完成當前訊息處理後，才進入交接階段。這意味著新的領導人，在 inaugurate()階段需要進行一定時間的等待。

排重優化

頻次控制是一個經典問題。對於分散式佇列程式設計架構，相同請求重複出現在佇列的情況並不少見。如果相同請求在佇列中重複太多，排重優化就顯得很必要。 分散式快取更新是一個典型例子，所有請求都被髮送到佇列中用於快取更新。如果請求符合典型的高斯分佈，在一段時間內會出現大量重複的請求，而同時多執行緒更 新同一請求快取顯然沒有太大的意義。
排重優化是一個演算法，其本質是基於狀態機的程式設計，整個講解通過模型、構思和實施三個步驟完成。

模型

進行排重優化的前提是大量重複的請求。在模型這一小節，我們首先闡述重複度模型、以及不同重複度所導致的消費模型，最後基於這兩個模型去講解排重狀態機。

重複度模型

首先我們給出最小重複長度的概念。同一請求最小重複長度：同一請求在佇列中的重複出現的最小間距。例如，請求ri第一次出現在位置3，第二次出現在10，最小重複長度等於7。
是否需要進行排重優化取決於佇列中請求的重複度。由於不同請求之間並不存在重複的問題，不失一般性，這裡的模型只考了單個請求的重複度，重複度分為三個類：無重複、稀疏重複、高重複。
無重複：在整個請求過程，沒有任何一個請求出現一次以上。
稀疏重複：主要的請求最小重複長度大於消費佇列長度。
高重複：大量請求最小重複長度小於消費佇列長度。
對於不同的重複度，會有不同的消費模型。

無重複消費模型

在整個佇列處理過程中，所有的請求都不相同，如下圖：

稀疏重複消費模型

當同一請求最小重複長度大於消費者佇列長度，如下圖。假定有3個消費者，Consumer1將會處理r1，Consumer2將會處理 r2，Consumer3將會處理r3，如果每個請求處理的時間嚴格相等，Consumer1在處理完r1之後，接著處理r4，Consumer2將會處 理r2之後會處理r1。雖然r1被再次處理，但是任何時刻，只有這一個消費者在處理r1，不會出現多個消費者同時處理同一請求的場景。

高重複消費模型

如下圖，仍然假定有3個消費者，佇列中前面4個請求都是r1，它會同時被3個消費者執行緒處理：

顯然，對於無重複和稀疏重複的分散式佇列，排重優化並不會帶來額外的好處。排重優化所針對的物件是高重複消費模型，特別是對於並行處理消費者比較多的情況，重複處理同一請求，資源消耗極大。

排重狀態機

排重優化的主要物件是高重複的佇列，多個消費者執行緒或程式同時處理同一個冪等請求只會浪費計算資源並延遲其他待請求處理。所以，排重狀態機的一個目 標是處理唯一性，即：同一時刻，同一個請求只有一個消費者處理。如果消費者獲取一條請求訊息，但發現其他消費者正在處理該訊息，則當前消費者應該處於等待 狀態。如果對同一請求，有一個消費者在處理，一個消費者在等待，而同一請求再次被消費者讀取，再次等待則沒有意義。所以，狀態機的第二個目標是等待唯一 性，即：同一時刻，同一個請求最多隻有一個消費者處於等待狀態。總上述，狀態機的目標是：處理唯一性和等待唯一性。我們把正在處理的請求稱為頭部請求，正 在等待的請求稱為尾部請求。
由於狀態機的處理單元是請求，所以需要針對每一個請求建立一個排重狀態機。基於以上要求，我們設計的排重狀態機包含4個狀態Init，Process，Block，Decline。各個狀態之間轉化過程如下圖：

1. 狀態機建立時處於Init狀態。
2. 對Init狀態進行Enqueue操作，即接收一個請求，開始處理（稱為頭部請求），狀態機進入Process狀態。
3. 狀態機處於Process狀態，表明當前有消費者正在處理頭部請求。此時，如果進行Dequeue操作，即頭部請求處理完成，返回Init狀態。如果進行Enqueue操作，即另一個消費者準備處理同一個請求，狀態機進入Block狀態（該請求稱為尾部請求）。
4. 狀態機處於Block狀態，表明頭部請求正在處理，尾部請求處於阻塞狀態。此時，進行Dequeue操作，即頭部請求處理完成，返回 Process狀態，並且尾部請求變成頭部請求，原尾部請求消費者結束阻塞狀態，開始處理。進行Enqueue操作，表明一個新的消費者準備處理同一個請 求，狀態機進入Decline狀態。
5. 狀態機進入Decline狀態，根據等待唯一性目標，處理最新請求的消費者將被拋棄該訊息，狀態機自動轉換回Block狀態。

構思

狀態機描述的是針對單個請求操作所引起狀態變化，排重優化需要解決佇列中所有請求的排重問題，需要對所有請求的狀態機進行管理。這裡只考慮單虛擬機器 內部對所有請求狀態機的管理，對於跨虛擬機器的管理可以採用類似的方法。對於多狀態機管理主要包含三個方面：一致性問題、完整性問題和請求快取驅逐問題。

一致性問題

一致性在這裡要求同一請求的不同消費者只會操作一個狀態機。由於每個請求都產生一個狀態機，系統將會包含大量的狀態機。為了兼顧效能和一致性，我們 採用ConcurrentHashMap儲存所有的狀態機。用ConcurrentHashMap而不是對整個狀態機佇列進行加鎖，可以提高並行處理能 力，使得系統可以同時操作不同狀態機。為了避免處理同一請求的多消費者執行緒同時對ConcurrentHashMap進行插入所導致狀態機不一致問題，我 們利用了ConcurrentHashMap的putIfAbsent（）方法。程式碼方案如下，key2Status用於儲存所有的狀態機。消費者在處理 請求之前，從狀態機佇列中讀取排重狀態機TrafficAutomate。如果沒有找到，則建立一個新的狀態機，並通過putIfAbsent（）方法插 入到狀態機佇列中。

完整性問題

完整性要求保障狀態機Init，Process，Block，Decline四種狀態正確、狀態之間的轉換也正確。由於狀態機的操作非常輕量級，兼顧完整性和降低程式碼複雜度，我們對狀態機的所有方法進行加鎖。

請求快取驅逐問題（Cache Eviction）

如果不同請求的數量太多，記憶體永久儲存所有請求的狀態機的記憶體開銷太大。所以，某些狀態機需要在恰當的時候被驅逐出記憶體。這裡有兩個思路：

• 當狀態機返回Init狀態時，清除出佇列。
• 啟動一個後臺執行緒，定時掃描狀態機佇列，採用LRU等標準快取清除機制。

標識問題

每個請求對應於一個狀態機，不同的狀態機採用不同的請求進行識別。
對於同一狀態機的不同消費者，在單虛擬機器方案中，我們採用執行緒id進行標識。

實施

排重優化的主要功能都是通過排重狀態機（TrafficAutomate）和狀態機佇列（QueueCoordinator）來實施的。排重狀態機描述的是針對單個請求的排重問題，狀態機佇列解決所有請求狀態機的排重問題。

狀態機實施（TrafficAutomate）

根據狀態機模型，其主要操作為enQueue和deQueue，其狀態由頭部請求和尾部請求的狀態共同決定，所以需要定義兩個變數為head和tail，用於表示頭部請求和尾部請求。為了確保多執行緒操作下狀態機的完整性（Integraty），所有的操作都將加上鎖。

enQueue操作

當一個消費者執行enQueue操作時：如果此時尾部請求不為空，根據等待唯一性要求，返回DECLINE，當前消費者應該拋棄該請求；如果頭部請 求為空，返回ACCPET，當前消費者應該立刻處理該訊息；否則，返回BLOCK，該消費者應該等待，並不停的檢視狀態機的狀態，一直到頭部請求處理完 成。enQueue程式碼如下：

deQueue操作

對於deQueue操作，首先將尾部請求賦值給頭部請求，並將尾部請求置為無效。deQueue程式碼如下：

狀態機佇列實施(QueueCoordinator)

介面定義

狀態機佇列集中管理所有請求的排重狀態機，所以其操作和單個狀態機一樣，即enQueue和deQueuqe介面。這兩個介面的實現需要識別特定請求的狀態機，所以它們的入參應該是請求。為了相容不同型別的請求訊息，我們採用了Java泛型程式設計。介面定義如下：

enQueue操作

enQueue操作過程如下：
首先，根據傳入的請求key值，獲取狀態機， 如果不存在則建立一個新的狀態機，並儲存在ConcurrentHashMap中。
接下來，獲取執行緒id作為該消費者的唯一標識，並對對應狀態機進行enQueue操作。
如果狀態機返回值為ACCEPT或者DECLINE，返回業務層處理程式碼，ACCEPT意味著業務層需要處理該訊息，DECLINE表示業務層可以拋棄當前訊息。如果狀態機返回值為Block，則該執行緒保持等待狀態。
異 常處理。在某些情況下，頭部請求執行緒可能由於異常，未能對狀態機進行deQueue操作（作為元件提供方，不能假定所有的規範被使用方實施）。為了避免處 於阻塞狀態的消費者無期限地等待，建議對狀態機設定安全超時時限。超過了一定時間後，狀態機強制清空頭部請求，返回到業務層，業務層開始處理該請求。
程式碼如下：

deQueue操作

deQueue操作首先從ConcurrentHashMap獲取改請求所對應的狀態機，接著獲取該執行緒的執行緒id，對狀態機進行deQueue操作。
enQueue程式碼如下：

原始碼

完整原始碼可以在QueueCoordinator獲取。