LMAX 架構

整體結構

圖 1：LMAX 的三區塊架構

在頂層，架構有三個部分

• 商業邏輯處理器[5]
• 輸入中斷器
• 輸出中斷器

顧名思義，商業邏輯處理器處理應用程式中的所有商業邏輯。如上所述，它以單執行緒 Java 程式執行此操作，該程式會對方法呼叫做出反應並產生輸出事件。因此，它是一個簡單的 Java 程式，除了 JVM 本身之外，不需要任何平台架構來執行其他程式，這讓它可以在測試環境中輕鬆執行。

儘管 Business Logic Processor 可以執行在一個簡單的環境中進行測試，但要讓它在生產環境中執行，則需要更複雜的編排。輸入訊息需要從網路閘道器中取出並取消封送、複製和記錄。輸出訊息需要封送以利網路傳輸。這些任務由輸入和輸出中斷器處理。與 Business Logic Processor 不同的是，這些是並行元件，因為它們涉及到同時緩慢且獨立的 IO 作業。它們是專門為 LMAX 設計和建置的，但它們（就像整體架構一樣）適用於其他地方。

商業邏輯處理器

輸入和輸出中斷器

儘管商業邏輯發生在單一執行緒中，但在呼叫商業物件方法之前，仍有許多任務需要完成。處理的原始輸入以訊息形式從網路上傳送過來，此訊息需要轉換成商業邏輯處理器易於使用的形式。事件溯源依賴於保留所有輸入事件的持久性日誌，因此每個輸入訊息都需要記錄到持久性儲存體中。最後，架構依賴於商業邏輯處理器叢集，因此我們必須在這個叢集中複製輸入訊息。同樣地，在輸出端，輸出事件需要轉換成可透過網路傳輸的格式。

圖 2：輸入中斷器執行的活動（使用 UML 活動圖符號）

複製器和日誌記錄器涉及 IO，因此相對較慢。畢竟，商業邏輯處理器的核心概念是避免執行任何 IO。此外，這三個任務相對獨立，所有任務都需要在商業邏輯處理器處理訊息之前完成，但可以按任何順序完成。因此，與商業邏輯處理器（其中每個交易都會改變後續交易的市場）不同，並行運算非常合適。

為了處理這種並行運算，LMAX 團隊開發了一個特殊的並行運算元件，他們稱之為中斷器[11]。

粗略地說，您可以將中斷器視為佇列的多播圖形，其中生產者在其中放置物件，並透過個別的下游佇列傳送給所有消費者以進行平行使用。當您查看內部時，您會看到這個佇列網路實際上是一個單一資料結構 - 環形緩衝區。每個生產者和消費者都有順序計數器，用於指出緩衝區中它目前正在處理的插槽。每個生產者/消費者會寫入自己的順序計數器，但可以讀取其他順序計數器。這樣，生產者可以讀取消費者的計數器，以確保它要寫入的插槽可用，而無需對計數器進行任何鎖定。同樣地，消費者可以透過觀察計數器，確保它只在其他消費者處理完訊息後才處理訊息。

圖 3：輸入中斷器協調一個生產者和四個消費者

輸出中斷器類似，但它們只有兩個用於轉換和輸出的順序消費者。[12]輸出事件組織成數個主題，以便可以將訊息傳送給對它們感興趣的接收者。每個主題都有自己的中斷器。

我所描述的中斷器以一個生產者和多個消費者的方式使用，但這並非中斷器設計的限制。中斷器也可以與多個生產者一起使用，在這種情況下，它仍然不需要鎖定。[13]

中斷器設計的優點之一是，如果消費者遇到問題並落後，它可以讓消費者更容易快速追趕上進度。如果非封送器在處理第 15 個插槽時遇到問題，並在接收器位於第 31 個插槽時返回，它可以從第 16-30 個插槽中一次批次讀取資料以追趕進度。從中斷器批次讀取資料可以讓落後的消費者更容易快速追趕上進度，從而降低整體延遲。

我已在此描述事項，其中包含一個記錄器、一個複製器和一個非封送器，這的確是 LMAX 所執行的動作。但此設計允許多個這些元件執行。如果您執行兩個記錄器，一個記錄器會採用偶數插槽，另一個記錄器會採用奇數插槽。如果需要，這允許這些 IO 作業進一步並行。

環狀緩衝區很大：輸入緩衝區有 2000 萬個插槽，每個輸出緩衝區有 400 萬個插槽。順序計數器是 64 位元長整數，即使環狀插槽換行也會單調遞增。[14]緩衝區設定為 2 的冪次，因此編譯器可以執行有效率的模數運算，將順序計數器編號對應到插槽編號。與系統的其他部分一樣，中斷器會在過夜時彈跳。此彈跳主要是為了清除記憶體，以便在交易期間減少昂貴的垃圾回收事件發生的機會。（我也認為定期重新啟動是個好習慣，這樣您就可以演練如何在緊急情況下執行此動作。）

記錄器的任務是將所有事件儲存在耐用的形式中，以便在發生任何問題時可以重新播放。LMAX 不使用資料庫來執行此動作，只使用檔案系統。它們將事件串流到磁碟上。以現代術語來說，機械磁碟的隨機存取速度非常慢，但串流速度非常快，因此標語為「磁碟是新的磁帶」。[15]

我之前提到 LMAX 在叢集中執行其系統的多個副本，以支援快速故障轉移。複製器會讓這些節點保持同步。LMAX 中的所有通訊都使用 IP 多播，因此客戶端不需要知道哪個 IP 位址是領導節點。只有領導節點會直接聆聽輸入事件並執行複製器。複製器會將輸入事件廣播到追隨節點。如果領導節點當機，它的心跳就會消失，另一個節點會成為領導節點，開始處理輸入事件，並啟動其複製器。每個節點都有自己的輸入中斷器，因此有自己的記錄檔，並執行自己的非封送動作。

即使使用 IP 多播，仍需要複製，因為 IP 訊息可能會在不同的節點中以不同的順序到達。領導節點會為其餘處理提供確定性的順序。

解碼器會將事件資料從線路上轉換成 Java 物件，可用於呼叫商業邏輯處理器上的行為。因此，與其他消費者不同，它需要修改環狀緩衝區中的資料，以便儲存此已解碼的物件。此處的規則是，消費者被允許寫入環狀緩衝區，但每個可寫入欄位只能有一個並行的消費者被允許寫入。這保留了僅有一個寫入器的原則。 [16]

圖 4：擴充中斷器的 LMAX 架構

中斷器是一個通用元件，可以在 LMAX 系統外部使用。通常，金融公司對其系統保密，即使對與其業務無關的項目也保持沉默。LMAX 不僅公開其整體架構，還開放中斷器程式碼的原始碼，這讓我非常高興。這不僅允許其他組織使用中斷器，還允許對其並行屬性進行更多測試。

佇列及其缺乏機械同情心

LMAX 架構之所以引起人們的注意，是因為它是一種與大多數人思考的高效能系統截然不同的方法。到目前為止，我已經討論了它的運作方式，但尚未深入探討為什麼要以這種方式開發它。這個故事本身就很有趣，因為這個架構並非憑空出現。在團隊決定採用這個架構之前，花費了很長一段時間嘗試更傳統的替代方案，並了解它們的缺陷。

現今大多數商業系統的核心架構依賴於透過交易資料庫協調的多個主動式工作階段。LMAX 團隊熟悉這種方法，並且確信它不適用於 LMAX。此評估是基於 Betfair（成立 LMAX 的母公司）的經驗。Betfair 是個博彩網站，允許人們投注體育賽事。它處理大量流量，且有許多競爭，體育博彩往往會在特定賽事周圍爆發。為了讓它發揮作用，他們擁有周圍最熱門的資料庫安裝，並且必須採取許多不自然的方式才能讓它發揮作用。根據此經驗，他們知道要維持 Betfair 的效能有多麼困難，並且確信這種架構不適用於交易網站所需的極低延遲。因此，他們必須找到不同的方法。

他們最初的做法是遵循現今許多人所說的話 - 要獲得高性能，您需要使用明確的並行性。對於這個場景，這表示允許多個執行緒平行處理訂單。然而，並行性通常會遇到的問題是，這些執行緒必須彼此通訊。處理訂單會改變市場狀況，而這些狀況需要傳達。

他們在早期探討的做法是 Actor 模型及其表親 SEDA。Actor 模型仰賴於獨立、主動的物件，這些物件擁有自己的執行緒，並透過佇列彼此通訊。許多人發現這種並行性模型比嘗試執行基於鎖定原語的事情容易處理得多。

該團隊使用 Actor 模型建立了一個原型交易所，並對其執行效能測試。他們發現處理器花費更多時間在管理佇列，而非執行應用程式的實際邏輯。佇列存取是一個瓶頸。

當效能被推升到這種程度時，考量現代硬體的建構方式便開始變得重要。Martin Thompson 喜歡使用的詞彙是「機械同理心」。這個詞彙源自於賽車駕駛，反映出駕駛對車輛具有天生的感覺，因此他們能夠感受到如何發揮車輛的最佳效能。許多程式設計師（我承認我屬於這個陣營）對於程式設計如何與硬體互動並沒有太多機械同理心。更糟的是，許多程式設計師認為自己擁有機械同理心，但這建立在硬體運作方式的觀念上，而這些觀念現在已經過時好幾年了。

影響延遲的現代 CPU 主要因素之一，是 CPU 如何與記憶體互動。現今進入主記憶體對於 CPU 來說是一個非常緩慢的操作。CPU 具有多個層級的快取，每個層級都顯著地更快。因此，要提升速度，您需要將程式碼和資料放入那些快取中。

在某個層面上，演員模型在此有所幫助。你可以將演員視為其自己的物件，用於群組程式碼和資料，這是一個用於快取的自然單元。但演員需要溝通，而他們透過佇列進行溝通，而 LMAX 團隊觀察到，干擾快取的是佇列。

說明如下：為了將一些資料放入佇列，你需要寫入該佇列。同樣地，為了從佇列中取出資料，你需要寫入佇列以執行移除。這是寫入競爭，多個客戶端可能需要寫入相同的資料結構。為了處理寫入競爭，佇列通常使用鎖定。但如果使用鎖定，可能會導致發生至核心程式的內容切換。當這發生時，所涉及的處理器可能會失去其快取中的資料。

他們得出的結論是，為了獲得最佳快取行為，你需要一個設計，其中只有一個核心寫入任何記憶體位置[17]。多個讀取器沒問題，處理器通常在其快取之間使用特殊的高速連結。但佇列不符合單一寫入原則。

此分析讓 LMAX 團隊得出幾個結論。首先，它導致了中斷器的設計，它堅定地遵循單一寫入限制。其次，它導致了探索單執行緒業務邏輯方法的想法，提問如果單一執行緒免於並行管理，它的速度可以有多快。

在單一執行緒上工作的精髓，是確保你有一個執行緒在一個核心上執行，快取會升溫，並且盡可能多的記憶體存取會進入快取，而不是主記憶體。這表示程式碼和資料的工作集需要盡可能持續地存取。此外，將小型物件與程式碼和資料放在一起，允許它們作為一個單元在快取之間交換，簡化快取管理並再次改善效能。

LMAX 架構路徑的必要部分是效能測試的使用。基於建立和效能測試原型，考量並放棄基於行為者的方法。同樣地，改善各種元件效能的許多步驟都是由效能測試啟用的。機械同理心非常有價值，它有助於形成關於你可以做出哪些改進的假設，並引導你向前邁進，而不是後退，但最終，測試會給你令人信服的證據。

然而，這種風格的效能測試並不是一個理解良好的主題。LMAX 團隊經常強調，提出有意義的效能測試通常比開發生產程式碼更困難。機械同理心對於開發正確的測試很重要。除非你考慮 CPU 的快取行為，否則測試低階並行元件是沒有意義的。

一個特別的教訓是撰寫針對空元件的測試的重要性，以確保效能測試足夠快，才能真正衡量實際元件的執行情況。撰寫快速的測試程式碼並不比撰寫快速的生產程式碼容易，而且很容易因為測試不如它試圖衡量的元件快而得到錯誤的結果。

您應該使用這個架構嗎？

乍看之下，這個架構似乎只適用於非常小的利基市場。畢竟，導致它的驅動力是要能夠以非常低的延遲執行大量複雜的交易，大多數應用程式不需要以 600 萬 TPS 執行。

但這個應用程式讓我著迷的是，他們最終得到了一個設計，消除了困擾許多軟體專案的大部分程式設計複雜性。圍繞交易資料庫的傳統並行工作階段模型並非沒有麻煩。與資料庫的關係通常需要付出不小的努力。物件/關係對應工具可以幫助處理資料庫的大部分痛苦，但它並不能處理所有問題。大多數企業應用程式的效能調整都涉及對 SQL 的調整。

現在，你可以讓你的伺服器擁有比我們這些老傢伙更多的主記憶體，而我們只能獲得磁碟空間。越來越多的應用程式完全有能力將它們所有的工作集放入主記憶體中，從而消除了複雜性和遲緩的來源。事件來源提供了解決記憶體中系統耐用性問題的方法，在單一執行緒中執行所有內容可以解決並行問題。LMAX 的經驗表明，只要你需要的 TPS 少於幾百萬，你就會有足夠的效能空間。

這裡與日益增長的 CQRS 興趣有相當大的重疊。事件來源的內存處理器是 CQRS 系統命令端的自然選擇。（儘管 LMAX 團隊目前不使用 CQRS。）

那麼，什麼跡象表明你不應該走這條路？對於像這樣的鮮為人知的技術來說，這始終是一個棘手的問題，因為這個行業需要更多時間來探索其界限。然而，一個起點是思考鼓勵這種架構的特徵。

一個特徵是，這是一個連接的域，其中處理一個交易總是有可能改變後續交易的處理方式。對於彼此更獨立的交易，協調的需求較少，因此使用並行運行的單獨處理器變得更具吸引力。

LMAX 專注於找出事件如何改變世界的後果。許多網站更注重於獲取現有的信息存儲，並向他們能找到的盡可能多的眼球呈現該信息的各種組合 - 例如，想想任何媒體網站。在這裡，架構挑戰通常集中在正確獲取緩存。

LMAX 的另一個特點是，這是一個後端系統，因此考慮它對在交互模式中運作的事物的適用性是合理的。越來越多的 Web 應用程序幫助我們習慣於對請求做出反應的伺服器系統，這是一個與此架構非常契合的方面。這種架構比大多數此類系統更進一步的地方是其對異步通信的絕對使用，從而導致了我之前概述的編程模型的變化。

這些變更對大多數團隊來說需要一些時間適應。大多數人傾向於以同步方式思考程式設計，而且不習慣處理非同步性。然而，非同步通訊早已是回應性的必要工具。隨著 AJAX 和 node.js 在 javascript 世界中更廣泛使用非同步通訊，觀察這是否會鼓勵更多人研究這種風格會很有趣。LMAX 團隊發現，雖然需要一些時間才能適應非同步風格，但很快就變得自然且通常更容易。特別是，在此方法下，錯誤處理變得容易得多。

LMAX 團隊確實認為協調交易資料庫的日子已屈指可數。因為使用這種架構可以更輕鬆地撰寫軟體，而且執行速度更快，消除了傳統中央資料庫的大部分合理性。

對我來說，我發現這是一個非常令人興奮的故事。我的許多目標是專注於模擬複雜領域的軟體。像這樣的架構提供了良好的關注點分離，讓人們可以專注於領域驅動設計，並將大部分平台複雜性分開。網域物件與資料庫之間的緊密結合一直令人惱火，像這樣的做法提出了解決之道。