Abstract
本文討論與通用分佈式數據流處理應用程序的自動並行化相關的盈利問題。自動並行化涉及在應用程序的數據流圖中定位區域，這些區域可以在運行時複製以應用數據分區，以實現擴展。爲了使自動並行化在實踐中有效，需要回答盈利問題：有多少並行通道提供最佳吞吐量？此問題的答案根據運行時的工作負載動態和資源可用性而變化。在本文中，我們提出了一種彈性自動並行化解決方案，可以動態調整用於實現高吞吐量的通道數，而不會浪費資源。最重要的是，我們的解決方案可以通過運行時狀態遷移處理分區有狀態運算符，這對應用程序開發人員完全透明。我們在工業級數據流處理平臺上提供系統的實施和評估，以驗證我們的解決方案。
1. Introduction
隨着世界變得更加互聯和儀表化，來自各種軟件和硬件傳感器的大量數據以連續流的形式出現。可以在多個領域找到示例，例如金融市場，電信，製造業和醫療保健。在所有這些領域中，越來越需要收集，處理和分析這些數據流以提取見解以及檢測新出現的模式和異常值。最重要的是，這種分析通常需要近乎實時地進行。世界變得更加互聯和儀表化，來自各種軟件和硬件傳感器的大量數據以連續流的形式出現。可以在多個領域找到示例，例如金融市場，電信，製造業和醫療保健。在所有這些領域中，越來越需要收集，處理和分析這些數據流以提取見解以及檢測新出現的模式和異常值。最重要的是，這種分析通常需要近乎實時地進行。
流計算是一種計算範例，能夠以高效且可擴展的方式執行分析任務。 通過將傳入的數據流通過放置在一組分佈式主機上的Operator網絡，流計算提供了即時的處理模型。 由於數據不直接存儲在磁盤上，因此流計算避免了更傳統的數據管理存儲和處理模型所面臨的性能問題。 商業流處理系統的出現，如StreamBase [28]和InfoSphere Streams [16]，開源系統，如S4 [34]和Storm [27]，以及現有的學術系統，如STREAM [5]，Borealis [1]和System S [18]，是流計算範式未來增長和過去成功的證據。
在短時間內處理大量實時數據的頻繁需求是流處理應用的主要特徵[26]。 因此，支持高吞吐量處理是流式系統的關鍵要求[14]。 它需要利用多臺主機來實現可擴展性[4]。 隨着可用於處理的不斷增加的實時數據量，這一要求將變得更加突出。 由於雲計算和多核芯片設計的進步，分佈式和並行計算的可承受性得到提高，這使得這個問題變得易於處理。 這產生了對語言和系統級技術的需求，這些技術可以有效地定位和有效地利用流處理應用程序中的並行化機會。 後一方面是本文的重點。
流應用程序被構造爲有向無環圖，其中頂點是Operator，邊是數據流。 爲了擴展此類應用程序，流處理系統可以自由決定應用程序圖將如何映射到可用主機集。 自動並行化[24]是一種有效的技術，可用於以透明的方式縮放流處理應用程序。 它涉及檢測應用程序圖中可以在多個主機上覆制的parallel regions，這樣複製區域的每個實例（我們稱之爲通道）處理數據流的子集以便增加吞吐量。 這種並行形式稱爲數據並行性。 透明數據並行化涉及在沒有應用程序開發人員直接參與的情況下檢測parallel regions並應用運行時機制以確保安全性：並行化應用程序產生與順序應用程序相同的結果。
雖然安全性確保了正確性，但並不能確保提高性能。 提高性能的透明自動並行化必須具備一定的盈利機制。 在流數據parallel regions中，盈利能力涉及確定正確的並行度，這是要使用的並行通道的數量，而無需應用程序開發人員的明確參與。 彈性自動並行化通過使盈利性決策適應運行時動態（例如工作負載的變化和資源的可用性）而更進一步。 在本文中，我們提出了爲流處理應用提供有效彈性自動並行化的新技術。
實現彈性自動並行化有兩個重要的要求。
（R1）存在有狀態運算符時的彈性需要狀態遷移。 這帶來了兩個主要挑戰。 首先，爲了保持自動並行化的透明性，需要在存在但不干擾應用程序邏輯的情況下執行狀態遷移。 其次，我們需要儘量減少遷移狀態。 通過最小化遷移狀態，我們最小化可能干擾數據流的時間和空間開銷。 反過來，這將使更頻繁的適應。
（R2）存在運行時動態時的彈性需要控制算法。 這帶來了兩個主要挑戰。 首先，通用流處理應用程序包含大量用戶定義的Operator。 我們不能輕易地模擬這些Operator的反應。 應對這一挑戰需要利用運行時Metrics指標來指導控制系統，而不是依賴傳統的基於成本的優化。 其次，我們需要確保控制算法能夠提供SASO屬性[12]。 也就是說，它表現出穩定性（不會振盪使用的通道數），達到良好的精度（找到最大化吞吐量的通道數），具有較短的穩定時間（快速達到穩定的通道數），最後避免 過沖（不使用超過必要的頻道）。
我們通過開發基於Key-Value存儲的狀態API來解決透明遷移的挑戰，該API旨在支持分區有狀態Operator的實現。 分區有狀態Operator爲分區屬性[24]標識的每個子流存儲獨立狀態。 這些Operator在流處理應用程序中非常常見（由IP編號劃分的網絡跟蹤，由股票行情者劃分的財務流等）。 我們開發編譯時重寫技術，將高級用戶代碼轉換爲使用狀態API的等效版本，以便保護應用程序開發人員免受狀態遷移的細節。
我們通過開發增量遷移協議和基於一致Hash散列的相關拆分策略來解決低成本遷移的挑戰[19]，它們共同最小化了遷移狀態的數量。
我們通過依賴於在splitter處計算的兩個本地Metrics來解決運行時控制的挑戰：congestion index（在Splitter處的Blocking時間的度量）和吞吐量。 splitter是一個運行時組件，與Operator共同生成要拆分的流以進行並行處理。 我們開發了一種在Splitter上工作的本地控制算法，並使用這些Metrics度量來調整用於處理流的信道數。
我們通過在控制算法中引入幾種技術來解決提供SASO屬性的挑戰。 這些措施包括根據觀察到的Metrics指標的變化，根據使用的Channel通道數量來上下調整，以解決準確性和超調問題; 記住過去在不同操作點取得的表現以解決穩定性問題; 並快速縮放以解決建立時間問題。
本文做出以下主要貢獻：
- 據我們所知，它提供了第一個彈性自動並行化方案，可以處理有狀態運算符，適用於多個主機，並且專爲通用流處理應用程序而設計。
- 它提出了一種狀態管理API，編譯時重寫技術和運行時遷移協議，以最小的狀態移動執行透明狀態遷移。
- 它提出了一種控制算法，該算法使用本地信息和本地控制來實現SASO屬性，以便找到最佳工作點，以便以工作負載和資源自適應方式解決盈利問題。
- 它提供了對工業級流處理系統的實現和評估。
我們爲實現彈性而引入的技術和算法，例如控制算法，狀態管理技術和遷移協議，都具有普遍適用性，並且可以在任何流處理系統中實現。我們使用IBM InfoSphere Streams的原型版本，簡稱Streams及其編程語言SPL [13]來舉例說明狀態管理API。
總之，本文展示瞭如何以透明和彈性的方式解決分佈式有狀態流處理的盈利問題。本文的其餘部分組織如下。第2節提供了Streams和SPL [13]的背景知識，並概述了基於以前工作的自動並行化的安全性方面[24]。第3節概述了我們的彈性自動並行化解決方案。第4節描述了控制算法及其如何實現SASO屬性。第5節描述了基於鍵值的狀態API和編譯時重寫技術。第6節詳細闡述了遷移協議。第7節報告了實驗結果。第8節討論了相關工作，第9節總結了這篇文章。
2. BACKGROUND
本節簡要討論SPL語言和Streams中間件，然後介紹自動並行化的安全性方面
2.1 SPL AND STREAMS
SPL [13]是一種用於開發流處理應用程序的編程語言。 SPL應用程序由通過流連接相互連接的Operator實例組成。 Operator實例是應用程序數據流圖中的頂點。 Operator實例是Operator定義的實現。 例如，圖1中頂部圖的左側所示的運算符實例是TCPSource Operator的實例。 通常，Operator可以具有許多不同的實例，每個實例使用不同的流類型，參數或諸如窗口的其他配置。 Operator實例可以具有零個或多個輸入和輸出端口。 每個輸出端口生成一個唯一命名的流，它是一系列元組。 將輸出端口連接到運營商的輸入會建立流連接。 流連接是應用程序數據流圖中的邊緣。
Operator直接在SPL（通過自定義Operator）或通用編程語言中實現。 在這兩種情況下，運算符實現依賴於事件驅動的接口，它們對到達Operator輸入端口的元組作出反應。 元組處理通常涉及更新某些操作符本地狀態並生成在輸出端口上發送的結果元組。
Streams [16]是一個分佈式流處理引擎，可以使用一組分佈式主機執行SPL應用程序。 它執行各種運行時任務，例如數據傳輸，調度，容錯和安全性。
2.2 Auto-Parallelization
自動並行化是在應用程序的流程圖中自動發現數據parallel regions的過程，可以在運行時利用它。 除了發現這些parallel regions之外，編譯器還必須建立激活適當的運行時機制所需的某些屬性，以確保自動並行化的安全性。 例如，如果parallel regions是無狀態的，則要應用的運行時數據分割機制可以是循環的，而如果該區域是分區有狀態的，則必須使用基於Hash的方案來執行數據分割。
我們使用清單1中給出的SPL代碼示例說明了一個示例自動並行化過程。這裏，我們看到一個名爲OpMon的示例操作監視應用程序。 TCP Source運算符的實例用於接收包含有關不同應用程序的網絡使用情況的信息的流。 接下來是一個Aggregate運算符實例，它使用appId作爲分區鍵計算每個應用程序的每分鐘數據使用信息。 聚合結果通過Filter運算符獲取，以保留網絡使用率高於閾值的應用程序。 最後，將結果結果發送到TCP Sink運算符實例。
圖1顯示了OpMon應用程序（頂部）的數據流圖的可視化，以及它的自動並行化版本（在底部）。 在此示例中，並行區域由Aggregate和Filter運算符組成。 它是一個分區的有狀態parallel regions，因爲Aggregate運算符基於每個分區維護狀態。 Splitter駐留在parallel regions之前的Operator的輸出端口上，並負責將元組路由到並行通道。 一旦元組被路由到特定通道，那麼與它共享appId屬性值的所有未來元組必須被路由到同一個通道。 這是通過在appId屬性上應用hash函數在Splitter上實現的。
在此示例中，在parallel regions（TCP Sink）之後還有一個附加Operator。 此外，沒有跡象表明該Operator可以容忍亂序結果。 因此，這個特定的parallel regions（需要在其輸出處維持元組的順序。 這是在合併時實現的，合併位於並行區域之後的運算符的輸入端口上。 合併使用在Splitter處分配並通過並行區域傳送的序列號執行重新排序操作。
最後，這個並行區域包含一個Filter運算符，可以刪除一些元組。 這導致選擇性值最多爲1.因此，如果給定信道的元組碰巧以比其他信道更高的頻率丟棄，則合併可能長時間阻塞。 這是因爲在沒有元組到達的時候，合併無法區分需要很長時間才能到達的元組和永遠不會到達（丟棄）的元組。 爲了解決這個問題，這個特定的並行區域使用pules，pules是由Splitter週期性地發送並由合併器使用的特殊標記，以避免冗長的停頓。
有關自動並行化安全方面的完整詳細信息，請參見[24]。 總之，並行區域的以下屬性[33]在用於確保安全性的運行時機制中起着核心作用：
- Statefulness : 確定區域是否可以並行化，因爲只有無狀態和分區有狀態運算符適合數據並行。 它還確定了分離器使用的數據分區方案。
- Ordering: 下游運營商的要求確定並行區域是否需要在合併期間進行排序步驟。
- Selectivity: 並行區域的確定是否需要pulse以避免冗長的停頓。
在本文的其餘部分，我們將瞭解如何通過運行時自適應來解決自動並行化的盈利方面問題。
3. SOLUTION OVERVIEW
在本節中，我們將概述我們的解決方案，該解決方案基於運行時彈性。
我們的方法的關鍵思想是將盈利能力決策留給運行時，我們可以在其中推斷工作負載和資源可用性。 當應用程序開始執行時，並行通道的數量將設置爲1. 放置在Splitter上的控制算法會根據其維護的本地運行時指標Metrics，定期重新評估要使用的通道數。 控制算法可以決定增加或減少使用的信道數量，或者在任何決策點不採取任何行動。 當要使用的通道數改變時，如果並行區域是有狀態的，則可能需要執行狀態遷移協議。
重要的是要注意，我們沒有解決這項工作中的放置問題。 特別是，當我們的算法請求新的並行通道時，我們假設它將被放置在系統中的可用主機/核心上。
對於分區有狀態的並行區域，改變並行通道的數量需要部分重新定位狀態。 例如，如果並行通道的數量增加，則一些分區的分配需要從現有的並行通道移動到新的並行通道。 每當在Splitter處發生這種分配的改變時，與移動的分區相關聯的狀態也必須被重新定位。 特別地，新添加的並行信道需要從現有並行信道收集分配給它們的分區的狀態。 類似地，當移除現有通道時，與其處理的分區相關聯的狀態必須重新分配到現有並行通道。
作爲系統不變量，每個分區在任何給定時間點僅由單個並行通道擁有。 我們使用一致性hash執行分區到並行通道的分配，以最小化遷移期間移動的狀態量。
爲了透明地執行運行時遷移，流處理中間件必須推斷Operator維護的狀態。 在通常使用用戶定義的Operator的通用流式傳輸系統中，這需要特殊的機器。 爲了解決這個問題，我們的解決方案包括一個本地Key-Vaule存儲形式的狀態管理API。 SPL編譯器重寫Custom Operator中存在的代碼，以便將狀態轉換爲使用此API，從而使運行時能夠推斷此狀態並執行透明遷移。
4. CONTROL ALGORITHM
定期運行控制算法以更新並行信道的數量。 它依賴於以下兩個本地計算的指標：
Congestion：表示Splitter在連接上發送元組時是否觀察到不適當的延遲。 它在兩個方面是一個有用的指標：1）阻塞的存在表明我們需要更多的信道來處理當前的負載，同樣缺乏阻塞表明我們可能使用的信道多於必要的信道。 2）阻塞值的時間變化可以指示工作負載可用性的變化。 我們通過對阻塞指數應用閾值來計算阻塞作爲布爾值，阻塞指數是由於背壓而阻塞Splitter處的元組傳輸的時間分量的Metcis。
爲了計算阻塞指數，我們使用非阻塞I / O來傳輸元組。 如果發送呼叫通知我們會發生阻塞，則我們阻塞直到可用空間並測量所涉及的阻塞量。 總的來說，阻塞指數衡量阻塞所花費的時間。 我們在所有Channel上平均這個值。 擁塞指數是範圍[0,1]中的值。 我們將在4.3節中進一步討論阻塞指數閾值。
Throughput: 是在上一個適應期間每秒處理的元組數。 吞吐量在兩個方面是有用的：1）當我們根據通道數量移動到新的操作點時，它告訴我們情況是否有所改善。畢竟，目標是優化吞吐量。 2）吞吐量的時間變化可以指示工作量的變化。 控制算法基於以下兩個基本原則運行：
（P1）Expand：如果出現擁堵，則上升（增加通道數），除非您以前曾在那裏並且沒有觀察到提高的吞吐量。
（P2）Contract：如果沒有擁堵，則下降（減少通道數量），除非您曾經去過那裏並觀察到擁堵。
這裏，（P1）提供了SASO的準確性：我們獲得了良好的準確性，因爲通道數量增加直到擁塞被消除。 （P2）提供SASO中的過度配置屬性：我們避免使用超過必要的更多信道，因爲除非下面出現擁塞，否則信道數量會減少。 （P1）和（P2）中的“除非”條款在SASO中提供穩定性屬性：我們不會在操作點之間振盪，因爲過去發生的事情會被記住而不會重複。 但是，當工作量波動時，這兩個原則是不夠的。 當工作負載可用性發生變化時，我們需要忘記過去發生的部分事情。 因此，我們引入了以下調整以適應工作負載變化：
（P3）擁塞適應：如果在擁塞中觀察到工作量增加（減少）的變化，則忘記過去關於上升（下降）通道的觀察。
（P4）吞吐量適應：如果觀察到指示工作量增加（減少）的吞吐量的變化，則忘記過去關於上升（下降）信道的觀察。
這裏，（P3）和（P4）使控制算法能夠適應工作負載變化。 注意，控制算法具有以下關鍵特徵：它將在多個信道上建立，使得沒有擁塞，但是任何較少數量的信道將導致擁塞。 當處於這種穩定狀態時，如果工作量增加，它將開始觀察擁塞並上升（由於（P1））。 當工作量減少時，它將觀察到吞吐量減少並且忘記下面的一個信道導致擁塞（由於（P4））並且下降（由於（P2））的事實。
此版本的控制算法還有兩個小問題。 第一個是關於擁堵的性質。 該算法被設計爲解釋擁塞的存在，作爲需要更多信道來處理負載的指示。 在擁塞不是由於並行區域的成本而是由於並行區域下游的流量成本的情況下，增加通道數量不會導致任何改進，而是會導致過沖。 我們稱這種擁塞遠程擁塞，並使用以下附加原則避免潛在的陷阱：
（P5）遠程擁塞：如果在增加信道數量後擁塞繼續，但吞吐量沒有顯着增加，則下降。
這裏，（P5）避免了由於持續存在擁塞而導致信道數量連續增加的情況，但吞吐量沒有提高。 沒有（P5），這可能發生在遠程擁塞的情況下。 值得注意的是，大多數流應用程序在通過並行化刪除其原始瓶頸時最終會達到可伸縮性限制。 這是因爲瓶頸移動到應用程序的不可並行化部分，在大多數情況下，該部分是Source，Sink或某些有狀態操作符。 在並行區域下游的Operator成爲瓶頸的所有情況下，將發生遠程擁塞。
第二個問題是，在可用資源（諸如主機和核心的執行上下文）和並行區域的成本都很高的情況下，最佳信道數也可以是高的。 因此，控制算法可能需要很長時間才能達到該數量。 這是由於算法的一次一個通道性質，並可能對SASO中的穩定時間屬性產生負面影響。 我們通過引入一個稱爲快速縮放的算法選項來解決這個問題。 總結如下：
（P6）快速擴展：不是一次操作一個通道，而是一次操作一個級別，並在級別和通道數之間定義超線性映射。這裏，（P6）通過仍然一步一步地改變操作點來保持算法的主要操作模式。 但是它不是直接使用通道數，而是使用一個級別，通過一個函數將其映射到通道數。 特別是，我們使用以下函數：
爲了從0開始增加級別值，這導致以下一系列通道數：{1,2,3,4,6,8,11,16,23,32，...}。 根據最大通道數和建立時間要求，可以使用遵循更陡峭或更陡峭曲線的其他功能。
圖2給出了控制算法的高級描述，說明了原理P1到P6。
4.1 Algorithm Implementation
控制算法保留三個狀態變量。 第一個是當前的適應期，用P表示。第二個表示當前級別，用L表示。第三個是保存每個級別的以下信息的數組：算法所處的最後一個適應期 這個級別，用P i表示; 是否在最後一次算法處於此水平時觀察到擁塞，用C i表示; 上次算法處於此級別時觀察到的吞吐量，用T ai表示; 以及在最後一次算法在該水平上保持連續週期的第一個週期期間觀察到的吞吐量，由T i表示。 我們使用L *來表示最大級別數。
控制算法具有稱爲變化靈敏度的全局參數，表示爲 α，其確定重要變化意味着什麼。 它取一個[0,1]範圍內的值。 值爲1表示算法對吞吐量的微小變化非常敏感。 例如，如果靈敏度很高，則吞吐量的微小改善就足夠了。 吞吐量的所有變化都針對線性縮放系統中單個通道的理想吞吐量進行標準化。
算法1中的init（）程序提供狀態變量的初始化邏輯。該算法的核心在算法2提供的getNumberOfChannels（）例程中給出，該例程將當前吞吐量（由T表示）和當前擁塞狀態（由C表示）作爲參數。作爲第一步，應用原理（P3）和（P4）以查看負載是否有變化。如果負載增加（減少），則重置保持有關上述（下面）級別的信息。第二步更新保留的有關當前級別，上次吞吐量，上次擁塞狀態和第一次吞吐量的信息（除非算法最後一次處於此級別）。第三步調整當前級別。首先，應用原則（P5）來查看是否存在遠程擁塞。如果是這樣，我們會回到上一個級別。否則，應用原則（P1）：我們檢查是否存在擁塞，如果是，則上升一級除非算法之前存在但吞吐量更差。最後，應用原則（P2），即如果沒有擁塞，我們向下一級，除非算法之前已經存在並觀察到擁塞。一旦調整了當前電平，則應用原理（P6）以返回對應於當前電平的通道計數。
4.2 Detecting Workload Changes
算法3中給出了用於檢測工作負載變化的邏輯.checkLoadChangeViaCongestion（）例程使用擁塞狀態來檢測負載變化。如果當前級別和最後級別相同，但擁塞狀態已經改變，則將其視爲負載變化的指示（如果當前存在擁塞則負載增加，否則負載減少）。如果當前級別低於最後一級，但擁塞已消失，則將其視爲負載減少。最後，如果當前級別高於最後一級，但是已經出現擁塞，則將其視爲負載增加。 checkLoadChangeViaThroughput（）例程使用吞吐量來檢測負載變化。如果當前級別和最後級別相同，但吞吐量存在顯着變化，則將其視爲負載變化的指示（如果當前吞吐量值較高則負載增加，否則負載減少）。變化靈敏度用於檢測相對於線性縮放系統中的理想變化的顯着變化。如果當前級別低於最後一級，但吞吐量增加，則將其視爲負載增加。最後，如果當前級別高於最後一級，但吞吐量已降低，則將其視爲負載減少。
4.3 Discussion of Parameters
控制算法具有三個可配置參數。其中，擁塞指數閾值是唯一需要仔細調整的閾值。我們在實驗評估部分中根據經驗研究其設置，並顯示在[0.01,0.3]範圍內的任何閾值提供了穩健的設置。
快速縮放是一項可以打開以減少建立時間的功能。它調整了快速適應和微調並行通道數量的能力之間的權衡。
更改靈敏度可調整系統對工作負載變化的敏感度。在遷移成本較低的系統中，變化靈敏度參數的較小值（較高的靈敏度）是合適的。對於遷移成本高昂的系統，最好在採取適應步驟之前等待觀察到的吞吐量發生重大變化。例如，如果通道處理的吞吐量下降了10％，那麼通過降低一級來對此做出反應對於具有高開銷遷移的系統來說可能過於激進。
即使用戶沒有調整快速縮放或改變選擇性，我們的算法也能滿足所有SASO屬性。但是，通過提供這些參數，我們使高級用戶可以根據需要調整SASO屬性之間的相對權衡。
5. STATE MANAGEMENT
參與並行區域的運營商要麼是無狀態的，要麼是分區有狀態的，如第2.2節所述。 分區有狀態運算符基於分區屬性在每個分區的基礎上維護獨立狀態。 這些操作員需要特殊的機器來支持透明的彈性平行化。 特別是，運行時系統需要遷移（跨主機）與分區子集關聯的狀態。 這要求運行時瞭解由分區有狀態運算符管理的狀態。
爲了解決這個問題，我們開發了一個狀態管理API和一個相關的狀態管理服務。 此外，我們提供語言級機制，使新開發的運營商能夠利用託管狀態。 有關託管狀態API的詳細信息及其在SPL應用程序中的透明使用，請參閱附錄A.
6. STATE MIRGRATION
響應於控制算法在Splitter處做出的決定，對並行區域執行遷移協議。當控制算法更新通道數時，它還更新它用於在並行通道之間分配分區的數據分區功能並啓動遷移協議。僅在分區有狀態並行區域的情況下才需要遷移。
通過從Splitter向所有並行通道發送遷移脈衝來啓動遷移協議。當並行通道中的操作員接收到遷移脈衝時，它首先將脈衝向下遊轉發，然後開始執行每個操作員的遷移協議。這使得在並行區域包含多於一個分區有狀態運算符的情況下，可以並行地在多個運算符的副本之間執行狀態遷移。
我們首先描述運算符的遷移協議，然後討論使用不同數據分區函數對系統性能的影響。
7. CONCLUSIONS
我們提出了一種自動並行化方案，可以爲流處理應用程序提供彈性。它可以根據工作負載的可用性調整在運行時使用的並行通道數。最重要的是，通過依賴分區狀態的遷移，它能夠處理流處理應用程序中常見的分區有狀態運算符。我們提出了一種控制算法，該算法能夠實現良好的吞吐量，具有較短的建立時間，並避免振盪和過沖。我們描述了狀態管理API和遷移協議，它們共同實現了對應用程序開發人員透明的彈性並行化。此外，彈性不會干擾安全性，並且在相同的輸入下，相同的輸出以相同的順序產生，而不管是否存在遷移。實驗結果說明了我們的解決方案在尋找平行區域的理想工作點並在工作負載動態存在的情況下調整這一點的有效性。