最近師兄安排我讀一篇論文，自己粗略翻譯一下論文的主要部分，歡迎大家批評指正

Eris:使用網絡內並發控制實現無需協調的一致性的事務

摘要

• 分布式存儲系統旨在為 跨多片分區實現可擴展性並且通過復制實現容錯的結構 提供強一致性和隔離性保證。傳統上，達成上述目標需要原子提交和復制協議的昂貴組合，還會導致額外的協調開銷。我們的系統（Eris）使用了不同的方法。它將並發控制功能的一個核心部分（multi-sequencing）移植進了數據中心網絡本身。這個網絡負責協調地為事務排序，並且一個新的輕量級事務協議保證了原子性。
• 最後的結果是Eris既避免了復制也避免了事務協調開銷：我們展示了它可以在一個單位從客戶端到存儲系統的往返時間內處理一大類的分布式事務，正常情況下不需要明確的片間或副本間的協調。它以低於10%的開銷提供了原子性，一致性和容錯性，吞吐量（巨大提升），延遲比標準基準上的常規設計降低72%-80%。

1 Introduction

• 分布式存儲系統如今面臨事務語義和性能之間的擔憂。為了滿足大規模應用的需要，這些存儲系統必須為了可擴展性而劃分，為了可用性而復制。支持強一致性和嚴格的串行化會賦予系統 與單系統隔離地執行每個事務 同樣的語義——將編程人員從一致性和並發性的推導中解放出來。不幸的是，這樣做經常與有著高可擴展性和嚴格延遲限制的現代應用的性能要求不相容。交互式應用現在要求聯系每個節點上的幾百個或幾千個獨立存儲服務，潛在地造成了每個單獨的事務的延遲限制達到亞毫秒級。
• 一般常識告訴我們事務處理系統因為協調的代價而不能滿足這些性能需求。一個傳統的架構需要通過一個令人頭暈的協調協議數組足夠小心地設計每個事務，比如，用於復制的Paxos協議，為了保持原子性的兩階段提交協議和為了隔離性的兩階段鎖協議——每個都增加了自身的開銷。正如我們在第8部分展示的那樣，通過對大小的排序或其他操作，上述做法會增加延遲並減少吞吐量。
• 這篇論文借助Eris（一個新的高性能分布式事務處理系統）對一般常識發起挑戰。Eris面向數據中心環境下的高吞吐量和低延遲做優化。針對一類重要的事務，Eris可以零協調開銷執行，既沒有並發控制，原子提交的協調開銷，也沒有復制的協調開銷，針對完全一般的事務，Eris能做到開銷最小。它能夠執行各種各樣的工作負載，包括TPC-C,與非事務非復制系統相比，開銷減低10%。
• Eris架構以新方式劃分了事務隔離性，容錯性和原子協調的責任。Eris使用獨立事務（independent transactioin）將事務排序的核心問題分離出來，然後使用新的集成網絡協議優化處理。獨立事務表示一個跨多片的一次性代碼塊的一次原子執行。這種抽象是有用的——許多工作負載可以使用獨立事務獨立地表示——也是更多復雜操作的一塊積木。
• Eris的主要貢獻是一個新協議，這個協議可以無須明確協調地為獨立事務的執行和事務提交的共識建立線性化的順序。Eris使用自身的數據中心網絡作為並發控制機制來指定事務順序。我們定義並實現了一個新的網絡層的抽象（multi-sequencing），保證信息以一致的順序被傳送到每個片上的所有副本並探測丟失的信息。Eris使用能確保可靠傳輸應用層協議增強這個網絡層抽象。在正常的情況下，這個協議能夠在從客戶端到服務器的單往返時間內提交獨立事務，不需要請求服務器彼此間的通信。
• Eris是基於最近的 使用網絡層排序 來排序副本系統中的請求 的工作。在一個分區系統上排序事務基本上比在單副本組中排序操作更有挑戰，正如位於不同片的服務器看到不同的操作集合，但必須確保它們按照一致的順序執行跨片事務。Eris使用一個新概念multi-stamp，multi-stamp為排序事務提供足夠多的信息並且可以被一個網絡內定序器很容易地實現。
• 雖然獨立事務很有用，但是它們並不能捕捉到所有可能的操作。我們展示了獨立事務可以被用作積木來執行完全一般的事務。Eris使用“初事務”來收集讀取依賴關系，然後使用單一“結論性的”獨立事務提交它們。雖然這樣做增加了上鎖的開銷，但是借助基礎獨立事務原語的高性能，Eris繼續比常規的必須分別處理復制和協調的方法表現得好。
• 我們在實驗上評估Eris並驗證了Eris提供了很大的吞吐量，延遲較常規方法（兩階段提交，使用Paxos協議和鎖機制）降低72%-80%。因為Eris可以在單一往返時間內執行大多數事務而無需服務器間通信，在TPC-C基準測試中，Eris達到同樣的性能所需代價只有一個無事務無副本系統的3%。這驗證了強事務性，一致性和容錯性保證可以實現，沒有性能懲罰。

2 背景

• 我們研究為可擴展性而分區，為容錯性而復制的系統。數據在不同的分片之間進行分區，每個分片包含多個副本和所有分片數據的副本。用戶（如前端服務器）提交需要被處理的事務。我們在這裏限制自己在所有節點都在同一個數據中心的系統中。
• 一個存儲系統應當提供一些保證。每個事務應當被應用到它影響的所有片，或者一個都不影響（原子性）。執行應當與按順序執行每個事物效果相同（嚴格可序列化隔離）。即便每片中的一些節點失效，這些保證也適當保持（容錯性）。

2.1 現狀：廣泛協調

• 現存的系統一般使用分層方法實現這些目標，如表1所示。一個復制協議（如Paxos）在每個數據片內都提供了容錯。在片間，一個原子的提交協議（如兩階段提交）提供了原子性並與一個並發控制協議（如兩階段鎖或者樂觀並發控制）結合，雖然具體的協議不一樣，但許多系統使用這個結構。
• 一個後果是協調單一事務提交需要多輪協調。例如，圖2展示了在常規分層架構中提交一個事物所需的協議交換。兩階段提交協議的每個階段都需要異步執行一個復制協議來使得 事務協調決定 持久。此外，兩階段鎖要求在準備和提交操作之間保持鎖，阻塞產生沖突的事務。這個結合嚴重影響性能。

3 Eris的設計原則

• Eris使用了一種不同的方法做事務的協調，使得Eris能夠達到跟更高的性能。Eris基於下面三個原則：

3.1 原則一：排序與執行分離（Separating Ordering from Execution）

• 傳統的協調協議在執行事務的同時建立了它們的執行順序，比如（執行順序）作為執行期間獲得鎖的結果。Eris明確地從事務的執行過程中分離出構建事務順序的任務，使得Eris能夠使用一個優化的協議進行事務排序。
• 為了做到這一點，Eris協議基於一個特定的事務模型：獨立事務。獨立事務在多個片上應用同時的原子改變，但是禁止跨片數據依賴（我們在4.1中給出了更精確的定義）。獨立事務有關鍵的屬性，以全局序列順序在每個片上順序執行它們可以保證可串行性。也就是說，建立一個全局的序列順序允許事務執行無須進一步協調即可繼續執行

3.2 使用網絡內並發控制實現快速排序（Rapid Ordering with In-Network concurrency Control）

• 我們可以多快建立獨立事務的全局順序？現存的系統需要事務中每個參與的片彼此協調以確保事務以一致的順序在每個涉及到的片上處理。這要求在事務執行之前至少一輪通信，妨礙了系統性能。
• Eris通過使用自身的網絡排序請求來以最小的延遲建立事物的全局排序。最近的工作表明網絡層的處理元素可以被用來為去往副本組的每個信息指定一個序列號，使得探測信息丟失或傳送失序成為可能。Eris進一步使用了這個方法，使用網絡排序去往不同片的多個操作流。關鍵原語multi-sequencing原子地為一個信息的每個目的地設置一個序列號，建立了信息的全局順序，確保了任何接受者都可以檢測出丟失或重新排序的信息。Eris使用這個建立了一個事務處理協議，除非信息丟失，否則無須協調。

3.3 統一復制和事務協調（Unifying Replication and transaction Coordination）

• 傳統的分層設計為跨片事務的原子提交和單一片中操作復制使用不同的協議。雖然這種分離提供了模塊性，最近觀察到這導致了兩層間多余的協調。將跨片協調和分片內復制集成得到的統一的協議能夠達到更高的吞吐量和更低的延遲。
• 這個方法與Eris的網絡內並發控制結合的特別好。因為請求被網絡排序，一個片上每個單獨的副本可以以相同的順序獨立地處理請求。因此，在普遍情況下Eris可以在單輪往返時間內執行獨立事務，無需跨片或者片內協調。

4 Eris結構

• Eris以新方式為不同的保證劃分責任，使Eris能夠無需協調地執行許多事務。協議本身被分成了3層，如圖3所示：
  • 網絡內並發控制層使用新的網絡原語建立事務的一致的排序，既包括片內的也包括跨片的，但不保證信息傳送的可靠性。
  • 獨立事務層為排序的操作增加可靠性和原子性，確保每個事務在每個片內所有的非錯誤副本上最終執行（或者全部失敗）。對重要的一類事務來說，這種排序和可靠性的結合足夠保證線性化。
  • 一般事務層通過獨立事務建立完全一般的事務並依靠其它層提供的線性化執行來為完全一般的事務提供隔離性。

4.1 事務模型

• Eris中的事務有兩種類型。核心事務排序層處理獨立事務。這些可以被許多應用直接使用，這樣做提供了更高的性能。Eris也支持一般事務。
• 獨立事務是在一個參與者集合上原子執行的一次性操作（比如存儲過程）。也就是說，事務由一段在子數據片集運行的代碼組成。這些存儲過程不能與客戶端交互，在執行過程中不同的片也不能通信，每個片必須無須協調地獨立來到同一個提交點或終止點，比如，通過always commit的方式。這個獨立事務的定義來自於Granola，本質上與H-store的作者以“強兩階段”之名提出的定義相同。
• 像H-store架構一樣，在我們的Eris的實現中，底層數據存儲在每個參與者上按順序執行獨立事務，而沒有並發。這允許Eris避免了鎖的開銷和鎖存型同步的開銷，基於鎖存器的同步總體上站到傳統數據庫管理系統設計執行開銷的30%。這個架構限制事務執行在單線程中。多線程系統可以每個核操作一個邏輯分區，代價是潛在增長的分布式事務數量。
• 雖然獨立事務模型是限制性的，但是它可以捕捉許多非常常見的事務類別。任何只讀事務可以被表示為一個獨立事務。Eric的語義使它成為一個一致的快照讀取。任何一輪的always commit的讀/寫事務（比如無條件地遞增一組值）是一個獨立事務。最後跨片復制的數據（這對經常訪問的數據來說很常見）可以通過一個獨立事務一致地更新，先前的工作表明許多應用大部分或全部由獨立事務組成。比如，TPC-C，一個被設計用來表示事務處理工作負載的工業標準基準，可以整體使用獨立事務表示，盡管它很復雜。
• 一般事務提供了一個標準的交互事務模型。客戶端開始一個事務，然後在不同的片上執行一系列的讀寫操作，每個都依賴於之前操作的結果。最後客戶端決定提交還是終止事務。這些可以被用來實現任何事務處理工作量。

5 網絡內並發控制

• 傳統的事務處理系統是網絡無關的，一切——從排序操作到確保傳送到正確的分區——都依賴於應用層協議。最近的工作已經驗證了對於副本系統，通過使用網絡層的先進的處理能力建立排序原語來加速協調是有可能的。然而，大規模事務處理帶來了重大的新挑戰。
• 使用一個專用的排序組件本身不是一個新的idea。排序器已經被用於加速達成共識和加速事務處理系統，並且已經通過RDMA NICs+網絡內處理組件的軟件方式實現。尤其是NOPaxos展現了有可能建立一個網絡層設備，為所有去往復制組的數據包指定全局一致的連續序列號。序列號允許接受者拒絕不按序到達的信息並檢測丟失的信息（作為序列號間的空白）。這些反過來使一個優化的的復制協議成為可能，只有當信息丟失或順序重排時，副本才需要協調。
• 我們可以對事務處理采取同樣的做法嗎？在這篇論文中，我們展示了現存的網絡層機制（包括NOPaxos的OUM）並不適用於這個目標。它們基於一個去往單一目的組的信息集合建立順序，然而無需協調的事務執行需要傳送到多個目的片的信息的一致的順序。Eris的貢獻是一個網絡內並行控制原語，它建立了這樣一個次序並且允許接收者檢測丟失的信息，以及在可編程交換架構中實現這一原語的策略。
• 實現這個排序的一部分是使事務參與者集合向網絡層明確。傳統上，客戶端通過分別向每個組發送組播信息（或者，分別向每個組的每個成員單播信息）實現向多個組發送事務。這使得在網絡層不可能保證一個有意義的順序：如果不知道哪些信息對應著同樣的邏輯操作，就不能保證不同的事務參與者間有一個一致的順序。為了解決這個語義空白，我們引入了兩個新概念：
  • 組播（groupcast）：一個擴展的組播原語，將消息傳遞給客戶端指定的多播組。
  • 多重排序組播（groupcast）：一個專門的組播，保證信息以全局一致的順序傳送給所有的組播接收者。這個原語不保證傳輸可靠性，但是它保證接收者可以檢測丟失的信息。
• 這個設計的一個重要目標是最小化網絡所需的邏輯。這簡化了實現並增加了系統總體的可靠性。端到端的保證在應用中強化。我們定義的原語，復雜到支持Eris事務處理算法並因此動態地提升系統性能，也簡單到可以在各種各樣的網絡設備上容易並有效地實現。

5.1 為什麽要多重排序（multi-sequencing）

• 我們的工作把OUM模型擴展到了事務處理的多組環境。這要求為多個副本組使用相同的保證原子地排序信息。為了解釋這樣一個排序機制的需求和實現過程中的挑戰，我們研究兩個稻草人方案：

  5.1.1 總體全局排序：

• 考慮使用單一排序器將OUM方法直接應用到整個存儲系統。所有的事務通過這個排序器制定一個序列號並發送，然後將事務們轉發給系統中所有片的所有副本。因為單一的全局序列號，這個設計能夠同時確保順序（所有的接受者都已相同的順序處理信息）和丟失檢測（接受者會被通知任何丟失的信息）。然而，它要求每個服務器接收設計系統中任何片的每一條信息，明顯妨礙系統的性能。

• 註意采納這種設計是不可能的，因此信息在保持順序和丟失檢測的情況下只被傳送到它涉及到的片中的副本。借助全局序列號，從一個接收者接收信息序列為n，n+2並不能區分出是需要接收n+1（即發送了但沒收到）還是n+1並沒有發送給它的片（即不需要接收）。

  5.1.2 多重獨立排序

• 或者考慮通過將每個片視為一個獨立的OUM組來應用OUM方法。發送到一個片的信息獨立於其他片進行排序，然後傳送到片的所有副本。不像總體全局排序，使用這種方法信息只傳送到需要運行它們的片。此外，一個片上的副本們可以在片內檢測丟失的信息。然而排序和檢測並不是跨不同的片保證的。如果事務T1和T2都發送給片A和片B，有可能A的排序器先處理T1，後處理T2，而B的排序器先處理T2，後處理T1。也有可能A的排序器處理過的事務在到達B之前丟失，反之亦然。這些異常可能導致違反系統正確性。

• 為了確保一個正確的一致的排序需要的是一種方法，能夠確保傳送到多個多播組的信息跨所有參與組原子地被排序。我們下面的設計以兩個部分達到了這個目標。Groupcast為應用程序提供了直接發送信息到多個多播組的方式，而且多重排序（multi-sequencing）確保了跨所有目的組的原子排序。這是用一個名為“multi-stamp”的新技術實現。

5.2 Groupcast（新定義的組播）和多重排序組播（groupcast）

• 我們先定義組播（groupcast）和多重排序組播（groupcast）原語的屬性。
• Groupcast：傳統的組播把信息發送到一組預定義好的參與者，比如，IGMP組。分區副本事務處理系統中的通信不適合這種通信模式。事務必須傳送到多個副本組，每個 事務涉及到的 片一個。涉及到哪些組取決於事務細節。
• 取而代之，我們提出了groupcast原語，一個信息被發送到多個多播組。目的集合是特定的。在我們的設計中，這一點通過發送信息給一個專門的IP地址實現。使用SDN（software defined network,軟件定義網絡）規則，對匹配此目的IP地址的數據包專門處理。位於IP和UDP報頭之間的附加報頭制定了一個目的組的列表，數據包被發送到每個組的每個成員。
• 多重排序組播（groupcast）:多重排序（multi-sequencing）使用額外的排序保證擴展了組播（groupcast）原語，換句話說，它提供了下列屬性：
  • 不可靠性：並不能保證任何信息會被傳送到它的接收者。
  • 部分排序：所有多重排序組播（groupcast）的信息的集合是部分排序的，根據“任何有相同目的組的兩個信息是可比較的”的限制。此外，如果m1<m2，而且接收器傳送m1和m2，那麽它將先傳送m1，再傳送m2。
  • 丟失檢測：設R(m)表示信息m的接收者集合，對任何信息m，要麽(1)每個R(m)中的接收者傳送m或者m的丟失警告(DROP-NOTIFICATION)，要麽(2)R(m)中的接收者都不發送m或者m的丟失警告(DROP-NOTIFICATION)。
• 多序列因此可以在有著不同接收者集合的信息間建立一個排序關系。這是和OUM的一個重要的區別，OUM只支持單一多播組內的排序。多重排序（Multi-sequencing）要求任意兩個有共同接收者的信息間存在排序關系，比如R(m1)和R(m2)交集不為空。

5.3 多重排序(multi-sequencing)設計

• 多重排序組播（groupcast）是使用一個中心化的網絡層排序器實現的。隨時為系統指定一個排序器，當它失效的時候可以被替換掉。依賴於實現(5.4部分)，排序器可以是一個終端主機，一個中間機或者一個足夠強大的交換機。所有的多重排序組播（groupcast）數據包通過這個排序器路由排序器會修改它們來反映它們在全局序列中的位置。接收者然後確保它們只是按照序列號順序處理信息。
• 多重排序組播（groupcast）的挑戰在於排序器應該如何修改數據包。正如上面描述的那樣，附加單一序列號創建了一個全局隊列，使之滿足排序的需求，但不能滿足丟失檢測的需求。為了兩種需求都得到滿足，我們引入了一個新概念,多印記（multi-stamp）。
• 在多印記中，為每個目的組包含全套計數器有兩個目的。首先，每個接收者都可以確保排序和丟失檢測屬性。它會檢查其組的合適的序列號。如果這個值小於最後一次傳送的數據包的值，這表明這是一個亂序的包並丟棄。如果序列號比下一個期望的包的序列號大，這表明這是一個潛在丟棄的數據包，於是應用（如Eris）被通知。第二步，接收者可以根據報的序列號請求一個丟失的數據包，甚至可以從其他組請求丟失的數據包。
• 容錯和“代”：多重排序要求排序器保持狀態：每個目的組的最新序列號。當然，排序器可能失效。我們不是駛入保持排序器的狀態持久化，這需要排序器的同步復制和復雜的協議，而是讓排序器只保持軟狀態，並將排序器失效暴露給應用程序。
• 為了解決排序器失效，我們為系統引入一個全局的“代數（epoch number）”，這個數由排序器保存並且和多印記(multi-stamp)一起加入到組播（groupcast）報頭。排序器故障轉移的責任在SDN控制器，當它懷疑排序器已失效時（比如超時之後），它會選擇一個新的排序器，增加epoch number，並且在新的排序器中安裝epoch number。註意，按字典上的epoch number為主，multi-stamp為輔的順序滿足部分排序多重排序要求（多重排序中部分事務間是可以排序的，但不是全序關系(total ordering)，故稱之為部分排序（partial ordering））。
• 當接收者收到的一個多重排序組播（groupcast）信息有著比它之前收到的更高的epoch number，它會傳送一個NEW-EPOCH通知給應用程序(如Eris)。這通知應用程序一些數據包可能丟失了，應用程序負責就 哪些上一代的包 在處理來自下一代的信息之前 成功地被傳送 達成一致。正如在OUM中，SDN必須給連續的排序器養個安裝嚴格遞增的epoch number。為了容錯，我們使用標準方法復制控制器，這是一種常見的做法。或者，只要時鐘能足夠好地同步已在這種情況下保持單調，一個新的排序器可以根據最新的物理時鐘值設置它的epoch number。

5.4 實現和可擴展性

• 我們的Eris網絡層實現包括網絡內排序器，一個SDN控制器和一個終端主機庫，以便與Eris事務協議等應用程序接口。SDN控制器使用POX實現，管理組播（groupcast）成員，並安裝通過排序器路由組播（groupcast）流量的規則。終端主機庫提供發送和接收多重排序組播（groupcast）信息的api。尤其是，它監控傳入的多標記（multi-stamp）信息上的合適的序列號，如果必要的話，發送DROP-NOTIFICATION警告或NEW-EPOCH通知給應用程序。
• 排序器本身可以以多種方式實現。我們已經構建了基於軟件的模型，運行在使用網絡處理器實現的常規的終端主機和中間機上，並評估了它們的性能，如表1所示。然而，性能最高的選項是在交換機中實現多重排序組播（groupcast）功能。這個可以由支持每個數據包處理的可編程網絡數據平面架構來實現。
• 內部交換設計（In-switch designs）：為了獲得最佳性能，我們設想多重排序和組播（groupcast）直接在網絡交換機內實現。可編程網絡硬件架構，如Reconfigurable Match Tables [13], Intel FlexPipe [52], Cavium XPliant [65], and Barefoot Tofino [6]提供必要的處理能力。
• 我們已經使用P4語言實現了多重排序組播（groupcast），支持這些未來體系結構上的編譯。完整的P4源代碼是可用的。雖然這類產品預計明年將會推出，但是評估這種方法所需的硬件還沒有商業可用。然而，我們可以分析我們的設計的資源使用情況來理解網絡內並發控制的可行性和潛在可擴展性。
• 考慮可重構匹配表（RMT），這個結構提供了一個匹配頭字段並執行操作的階段流水線。他也提供有狀態的內存，其中一個寄存器可以存儲每個分片計數器。如果必要的功能可以在數據包處理流水線中表達，這個設計允許以Tb的線速度處理。那麽，可擴展性的障礙就是單一
• 組播（groupcast）數據包可以被解決的分片數量。兩類資源約束管理此限制。第一個是在每個數據包上可以增加多少有狀態的計數器。RMT提議指定32個階段，每個階段有4-6個寄存器連接的的ALU,支持每個數據包有128-192個目的地。第二，包含用於匹配和操作的字段的包頭向量被限制為512B，假定32位片ID和計數器值，在說明IP和UDP包頭後，允許116個同時目的地。對於非常大的系統，事務可能涉及超過一百個分片，可能有必要對全局消息（去往所有分片）使用特殊處理。
• 中間機原型：鑒於有足夠能力的交換機還不可用，我們在Cavium Octeon II CN6880網絡處理器上實現了一個多印記（multi-stamp）排序器。這個設備包括32個MIPS64核心，提供了對4個10Gb/s的以太網接口的低延遲訪問。我們在評估中使用中間機實現（第8部分），雖然它既沒有使用大量優化的實現，也沒有使用特殊強大的硬件（CN6880發布於2010年），它可以處理美妙處理6.19M個多重排序數據包接近每個鏈接10Gb/s(7M個包每秒)的最大容量。
• 終端主機排序：一個替代的設計選項是在一個終端主機上實現排序功能。這為網絡基礎架構無法修改的環境提供了更方便的部署選項。代價是這樣提高了延遲（每個事務接近10微秒），而且系統的吞吐量可能被排序器能力限制。在24核Xeon E5-2680機器上，我們在Linux用戶空間的的多重排序器的直接實現可以每秒排序1.61M個請求，足以滿足小型部署的需求。低級的優化和新硬件比如RDMA NICs可能會提升這個能力。

6 處理獨立事務

• Eris的獨立事務處理層為獨立事務提供單拷貝線性化（或者稱之為嚴格線性化）語義。獨立事務擁有在每個分片上一次執行它們的屬性，保證了嚴格可序列化的行為，只要它們以一致的順序執行即可。網絡多重排序只是為事務建立這樣一個（一致的）順序。然而，他不保證可靠的傳輸。因此，為了正確性，Eris必須建立在應用層建立可靠傳輸的語義，確保副本們就提交哪些事務達成共識，而不是事務的順序。在正常情況下，Eris能夠只消耗客戶端到所有副本的單輪往返時間執行獨立事務。

6.1 概述

• Eris使用基於仲裁的協議保證安全——即使當服務器和底層網絡行為不同步時——和可用性——即使當任何片中2f+1個副本中的f個副本因崩潰而失效時。Eris客戶端使用多重排序組播(groupcast)直接將獨立事務發送給涉及到的分片中的副本，並等待來自每一個分片的大多數仲裁的回復。在每個分片上有一個副本被作為“指定的學習者（Designated learner）”。事實上只有這個副本同步地執行事務，其他副本只是記錄事務並稍後執行。因此，Eris要求客戶端在考慮一個仲裁完成之前，等待一個來自DL的回復（因為它最先執行，所以理應回復比其他得快，由它來發送事務結果，其他副本發送確認信息）。使用DL有兩個目的。第一，它允許單向往返執行，不需要猜測和回滾：只有DL執行請求，除非它失敗了並且被替換了，否則它涉及該分片提交的每個事務（NOPaxos使用同樣的原則）。第二，每個分片上只有DL發送事務結果給客戶端，其他的副本只發送確認信息，避免客戶端不必要的網絡擁塞。
• Eris必須對復制失敗和網絡異常有足夠強的適應能力。在我們的多重排序抽象中這些異常由DROP-NOTIFICATION（當網絡中一個多重排序組播（groupcast）事務發生丟失或亂序時）和NEW-EPOCH（當一個排序器被替代時）組成。在Eris中，DL失效可以完全在片內由一個類似於標準領導者變更協議的協議[40,43,51]處理。然而，DROP-NOTIFICATION和NEW-EPOCH通知需要跨片協調。對於DROP-NOTIFICATION，丟失事務的所有參與的分片必須就是否拋棄信息達成同樣的決定。對於NEW-EPOCH通知，分片必須確保它們以一致的狀態過渡到新一代。
• 為了管理這兩種失敗情況的復雜性，我們引入了一個新元素到Eris架構：失敗協調器（FC）。FC是協調副本們從數據包丟失和排序器失效中一致地恢復的服務。FC必須使用標準方法復制以保持可用。但是復制和協調的開銷不是問題：Eris僅在罕見的失敗情況下調用FC並產生開銷，並不是在正常路徑上。
• 由副本維護的狀態總結在圖4中。狀態的兩個重要部分是view-num和epoch-num，追蹤當前DL和多重排序的epoch。具體而言，view-num值為v的DL是副本號v mod N，N是片上副本的數量。Eris副本和FC使用當前epoch-num標記所有信息，不接收前代的信息（除了跨代階段）。如果一個副本曾經從後一代接收信息，它必須在繼續之前使用FC過渡到新一代。
• Eris包含5個子協議：正常情況的協議，處理丟失信息的協議，在片內更改DL的協議，更改epoch的協議和定期同步副本狀態並允許所有副本安全地執行事務的協議。下面我們列出所有五個。為了簡潔，一些細節被忽略。完整的細節在一份相關的技術報告中。在這些協議中，發送但未被正確的回復確認的信息會被重發。尤其是，客戶端重復地重試事務直到它們收到正確回復為止。使用維護一張 來自每個客戶端的最近的事務組成的 表的 標準技術保證“最多一次”的語義。

6.2 正常情況

• 在正常情況下，客戶端通過多重排序層提交獨立事務，每個按順序接收信息的副本只是響應客戶端，DL執行事務並包括結果。因此事務僅在單輪往返處理。圖5解釋了這個過程。
  • 首先，客戶端使用多重排序組播（groupcast）將事務發送給所有涉及到的片的所有副本組。
  • 副本接收事務，把它記錄進日誌並使用
  • 客戶端等待來自每個分片的視圖一致的仲裁回復。
• 這裏，視圖一致的仲裁回復是來自分片中大多數副本的回復，每個回復（包括來自DL的回復）須在匹配txn-index,view-num,epoch-num三個字段。
• 註意，如果副本的perm-drops（永久丟棄）和temp-drops（臨時忽略）字段與事務標識符相匹配，副本將不會執行這個事務。如果事務標識符與與副本的perm-drops字段匹配，副本向日誌中事務的位置插入NP-OP並繼續，否則副本必須等待。正如下面討論的那樣，事務的標識符與perm-drops或temp-drops字段匹配表示FC認為事務確定或可能失敗。

6.3 信息丟失

• 當因網絡異常導致副本錯過發送給它所在的片的信息時，副本會從多重排序層收到DROP-NOTIFICATION，這裏，原子性要求要麽每個參與的分片都學習並執行丟失的事務(見6.2部分)，要麽都不執行這個事務。這個過程由FC協調，FC與系統中其他節點聯系以恢復錯過的事務。如果任何節點有缺失的事務的復制品，FC把它發送給其他副本。否則，FC使用一輪“同意”來確保所有的副本同意丟棄事務並繼續。
  • 當分片中的副本探測到它錯過了某個事務時，它發送
  • FC接收到FIND-TXN並（既定FC還沒有發現或丟棄這個發生缺失的事務）向所有分片的所有副本廣播
  • 當一個副本收到了TXN-REQUEST，如果它收到了一個匹配txn-id，它回復
  • FC等待來自每個分片的TEMP-DROPPED-TXN組成的仲裁或一個HAS-TXN，以先到者為準。像之前那樣，每個仲裁必須是視圖一致的並包括視圖的DL。如果FC先收到了HAS-TXN並且還沒有丟棄這個事務，它會保存這個事務並發送
  • 當副本接收到FC的回應時，如果接收到的是TXN-FOUND，它把事務添加到un-drops字段中，將事務添加到日誌並回應客戶端。如果它收到的是TXN-DROPPED,它將txn-id加入perm-drops字段中並且如有必要將NO-OP添加到日誌。無論哪種情況，副本都可以執行後續事務。
• 作為優化，在執行這個程序之前，接收到DROP-NOTIFICATION的副本首先與片內其他副本聯系，如果它們中有一個接收到了缺失的信息，它（接收到缺失信息的副本）可以（使用缺失的信息）回復它（接收到DROP-NOTIFICATION的副本），允許前者可以正常的處理事務。如果成功了，這允許副本在不涉及FC的情況下恢復丟失的信息。在我們的實驗中，這一優化十分重要，因為信息缺失影響到分片的所有副本的情況是很罕見的。

6.4 “指定的學習者”失效（Designated Learner Failture）

• 因為只有DL執行事務，並且取得進展的能力取決於每個具有DL的分片，Eris有一個view更改協議來替換DL（如果它失效了）。為了確保系統保持正確，新的DL必須學習之前的view提交的所有事務。它也必須學習之前的view中大多數分片發送的TEMP-DROPPED-TXN，而且從FC獲得結果之前不要處理這些事務。
• view的改變是使用一個類似於Viewstamped Replication[45,51]的協議實現的。由於空間限制，我們只提供一個簡潔的概述，細節在[42]。
• 任何懷疑DL已失效的副本停止處理請求並發送一個VIEW-CHANGE信息給下一個view的DL，信息中還包括它當前的狀態。新的view中的DL等待大多數發來了這一信息，然後使用他收到的最長的日誌和收到的temp-drops, perm-drops, un-drops的並集組裝新的view的狀態，將新日誌中任何與perm-drops字段中的txn-id匹配的事務重寫為NP-OP。如果新日誌中有任何事務與temp-drops字段中的txn-id匹配但在un-drops字段中沒有對應的txn-id，DL必須等待FC來做有關那些txn-id的決定，如果有必要會重試——詢問FC並發送必要的HAS-TXN。DL然後發送包含新狀態的START-VIEW信息給其他副本，副本們采納新的狀態並過渡到新的view。
• view的改變（或者換代）可能導致舊的view中的DL執行了最終被丟棄的事務，要求應用層回滾，Eris使用應用程序狀態轉換處理這種可能性。

6.4 換代

• Eris也需要處理多重排序層的換代，比如，排序器失效。至於丟棄的信息，FC處理管理這個過程。它確保所有分片中的所有副本以一致的狀態在新一代開始，即副本了解在前一代提交的事務，並且沒有副本知道事務中的其他參與者不知道的事務。
• 當一個副本從網絡層收到NEW-EPOCH通知時，它停止處理請求並發送EPOCH-CHANGE-REQ信息給FC，然後FC向每個副本請求副本的當前狀態（或足夠的元數據）以及不繼續處理任何屬於lower-numbered epoch的操作的承諾。FC等待每個分片中來自簡單多數的副本的這種承諾。然後FC 只使用那些FC開始以來的最近一代的那些回應 決定新一代中每個分片的初始狀態。每一分片都會收到它收到過的最大view-num和包含FC收到的所有該分片參與的事務（如果某個事務被FC先前丟棄了，就被替換為了NO-OP）的日誌。FC將那個狀態（也就是FC決定的初始狀態）作為START-EPOCH信息發送給所有副本，副本使用新的view-num和日誌，執行任何新的事務並清除它們的temp-drops,perm-drops和un-drops。到達一個一致的狀態後，副本們能夠處理來自新排序器的信息。FC保留並重新發送這些STRAT-EPOCH信息直到每個分片的大多數副本確認新的epoch，協議的完整細節見[42]。

6.6 同步

• 在獨立事務的正常處理（見6.2部分）中，只有每個分片的DL同步地執行獨立事務，其他副本僅記錄事務。為了避免那些副本的應用程序狀態變得太過時，Eris使用了和NOPaxos完全一樣的同步協議。每個分片的DL定期與其他副本同步日誌，並告知它們執行其中的獨立事務是安全的，完整細節見[42]。

6.7 正確性

• Eris保證在穩定期內線性化的執行獨立事務和活躍性。完整的證明和模型檢查的TLA+規範在[42]，這裏我們給出一個主要安全論證的概述。
• 定義：如果分片發送了一個給事務t的view一致的回復仲裁，事務t在日誌槽中的分片上提交。如果一個view一致的仲裁發送tau的TEMP-DROPPED-TXN，一個給txn-id為tau的“丟棄承諾”被提交。如果一個日誌中的事務在後續epoch和view中是同一分片中所有副本的日誌記錄的事務的前綴，我們稱這個日誌（包括事務和NO-OP）是穩定的。
• 我們先考慮單一分片的行為：
  • 不變量：如果一個事務在日誌槽中被提交，那麽在後來的view或epoch中它將在同樣的分片的任何副本的日誌的該槽中。類似，如果一針對一個txn-id的“丟棄承諾”被提交，那麽在同一分片中的開始後續的view的任何副本將在它們的temp-drops字段包含txn-id。
  • 這保證了在任何時間，分片的DL有所有先前提交過的事務和當前的“丟棄承諾”的記錄。這一協議通過攜帶大多數副本的狀態的並集開始一個新的view或epoch以確保不變量，任何先前提交的事務或“丟棄承諾”中，至少這些副本中的一個一定參與過。
  • 因為副本以序列順序添加事務到它們的日誌中，一旦DL的日誌中的一個事務被提交，它的日誌中任何早前的事務也必須以大多數存在，並且將因此存活於後來的view和epoch。此外，不存在於它的日誌中的低編號（low epoch or view）事務不能存活到後續的view和epoch：任何日誌中的NO-OP對應著“丟棄承諾”提交後FC丟棄的事務。未來的DL將在view更改期間發現這個“丟棄承諾”，而且FC將不會啟動該事務（被丟棄的事務）的下一個epoch。因此，DL的日誌是穩定的，意味著單個分片的行為和單個正確節點的行為無法區分。
• 然後，我們考慮多個分片的聚合行為。因為先前的不變性和事實上FC在一個來自每個片的“丟棄承諾”後只丟棄一個事務，下面的不變量保持（完整證明見[42]）：
  • 不變量：如果事務t被分片s提交，那麽對於其他所有參與的分片s‘：如果s‘已經提交了t‘>t,那麽s‘就已經提交了t。這裏，>是由多重排序層指定的部分順序。
  • 也就是說，事務以一種遵照多重排序產生的順序的方式原子地在分片間自動執行。既然多重排序保證了一個任何潛在沖突的事務都可比較的部分順序，那麽任何關於這個順序的執行豆漿沒有沖突環，因此可串行化。此外，該順序還考慮了連續排序器接收到的事務的實時順序，使Eris的事務執行可線性化。

7 建立一般事務

• 許多（並非全部）重要的操作可以表達為獨立事務。一個例外是依賴於存儲在另外一個分片上的數據的有條件的更新。比如，只有當資金充足時才能將資金從一個賬戶移動到另一個賬戶的銀行交易。在很多情況下，這些操作可以通過仔細的分區（甚至是狀態重復）得到避免。比如，通過將兩個賬戶放在同一個分片上。然而，為了支持所有工作負載我們擴展了Eris來支持可以有跨片依賴的一般事務。
• Eris通過將一般事務分解成多個獨立事務來運行一般事務。因此一般事務的執行運行於獨立事務的執行的上層。這簡化了設計：一般事務的實現事實上可以依賴於獨立事務處理層是正確的並提供線性化執行。也就是說，可以假設一個正確的單機可以順序地處理獨立事務。
• 在這些更一般的事務存在的情況下支持強隔離性需要額外的並發控制機制。Eris使用嚴格的兩階段鎖。分片為每個數據對象維護讀寫鎖，只有在存在未完成的一般事務時才用。在鎖定期間，任何影響相應數據對象的獨立事務或一般事務等待，直到鎖被釋放為止。

7.1 一般事務協議

• 我們首先考慮完整的讀/寫集先驗已知一般事務。這些事務以兩階段提交。在第一階段客戶端發送一個初步事務，執行讀操作並獲得所有的讀寫鎖。在第二階段，客戶端發送一個結論事務，要麽提交（commit）一般事務，要麽終止（abort）一般事務。提交（commit）安裝事務所做的修改。在兩種情況下，事務的鎖都被釋放。
• Eris也能夠執行讀寫集合一開始不知道的事務，即他們是依賴於狀態的。為此，Eris像Calvin一樣應用偵查查詢（reconnaissance queries）。也就是說，在發送一般事務的初步組件之前，客戶端發送 單信息的，非事務性的讀取 來決定完整的讀寫集。初步事務檢查偵查搜索返回的值是否有效。如果任何有所改變，一般事務將被終止。否則，結論事務可以以上述方式進行。

7.2 處理客戶端失敗

• Eris客戶端是他們自己的事務管理者。因為客戶端可能失敗，Eris必須能夠終止一個由失敗的客戶端開始的一般事務來允許系統維持進度。一般來講，解決這個問題是復雜協作終止協議的範疇。然而因為Eris建立在獨立事務的原子執行的基礎上，它允許一個簡單的解決辦法。當一個Eris的副本因客戶端長時間上鎖也不發送結論commit還是abort而懷疑客戶端已經失敗時，副本可以通過將abort指令通過獨立事務層排序並作為獨立事務發送來簡單地單方面終止一般事務。這確保了即使客戶端同時嘗試發送commit，所有參與的分片也能作出彼此相同的commit/abort決定。

7.3 討論

• Eris在核心的獨立事務原語上建立了一般事務層，模塊化簡化了設計，尤其是處理客戶端失敗的設計。這一分層設計非常實際，因為Eris能夠在單次往返中提交獨立事務。在之前的系統比如Granola中這樣的方法可能不實用，因為在之前的系統中獨立事務仍然設計顯著的協調開銷。因此，Granola為獨立事務和一般事務使用獨立的專門的協議，兩者間的轉換有著復雜的流程和巨大的開銷。
• 此外，Eris網絡內並發控制的使用阻止了死鎖，緩解了一大類並發引起的abort和復雜的死鎖檢測機制：在由線性化層執行的單個原子步驟意味著等待圖中不可能成環。結合獨立事務處理協議的吞吐量和延遲優勢，這允許Eris更好地應對高爭用。

Eris:使用網絡內並發控制實現無需協調的一致性的事務