7.Operation-transfer系統中的調度和衝突處理
本章討論operation-transfer系統中的操作調度算法，以及爲達成一致的衝突操作解決。調度緊密地依賴可靠的組通信，向所有站點傳播順序定義良好的網絡消息。實際上，TSAE(Time-Stamped Anti-Entropy protocol)作爲一個組通信服務出現，儘管它很容易被理解爲一個樂觀複製服務。本書中呈現的語法更新調度，基本上對應全局廣播和因果廣播。語義更新調度對應與應用相關的因果廣播，進而解決併發更新。（這句話翻譯不是很確定，附上原文：Syntactic update ordering presented in this paper roughly corresponds to total and causal broadcast, and semantic ordering corresponds to causal broadcast with an application-specific policy to resolve concurrent updates.）然而，實現該策略的機制會非常不一樣，因爲樂觀複製系統的工作方式是異步的，epidemic。
從一個相同的初始狀態開始，結合相同的操作集合，當每一個節點計算出一個能獲得一致最終狀態的調度時，operation-transfer系統將取得一致。更準確地描述，我們需要下面屬性：
1）對於所有節點，調度存在一個相同的前綴，我們稱爲共同前綴。（調度前綴相等，指他們包含相同的操作，同時他們可以從一個相同的初始狀態開始，生成相同的狀態。）
2）每一個操作最終會包含進入共同前綴，要麼被執行，要麼不被執行。
3）一旦進入共同前綴，操作不再被移除、也不再改變狀態。
爲了進行衝突解決，前面的定義允許調度將一個或多個操作無效化，比如，不執行它們。因此，如果兩個操作衝突，一個或者另外一個將被無效化。一個更通俗的定義，允許衝突操作集被轉化爲不衝突的操作集。
這裏有多種方法來產生一個相等的調度。一個充分條件是，調度的結果是完全一致的（假設，悲觀操作）。語法調度策略，採用靜態規則在全局進行更新調度，產生一個完全相同的調度結果。一個完全相同的調度結果，並不是保證調度相等的必要條件。（相等不等於完全相同。相等指的是不同節點調度後的更新，產生的結果是一樣的；完全相同，指不同節點調度後的操作完全一樣，包括順序）語義調度需要深入操作語義，局部調度更新來消除衝突，產生相等的調度。操作轉化，在7.3節中描述，修改操作本身，不需要重新排序從而讓調度結果相等。7.4節討論更新衝突解決策略。7.5節討論更新提交（或者說，穩定化），該機制是讓副本統一的調度結果被持久的應用到節點上，不用擔心被撤銷。
7.1 語法操作調度
操作調度的最低要求是調度結果兼容happens-before偏序關係（附件A.1）。語法調度策略通過靜態調度規則實現最低要求。
很多系統爲每一個操作記錄一個標量時鐘（比如，物理時鐘、邏輯時鐘；見Appendix A.2），使用它們來對操作排序，比如在Bayou，TSAE中。
（思考：注意State-transfer系統中，是爲對象記錄時鐘，而不是爲修改操作記錄時間戳。）既然一個標量時鐘無法檢測衝突，這些系統必須採用一個獨立的機制來檢測衝突語義。
你或許認爲可以採用Version Vectors來對操作更新進行排序和衝突檢測，但它們卻在Operation-transfer系統中並不常用。因爲Multi-log通常已經記錄了操作的語義關係，而Version Vectors提供很少的額外價值。
7.2 語義操作調度
一個不同的操作調度方法，是視調度爲一個優化問題，爲了消除衝突，實現一致。因此語義調度比語法調度要複雜許多，但可以消除衝突和重新排序不確定的操作。
7.2.1挖掘交換特性
最簡單的語義調度是挖掘操作間的交換特性。兩個操作known to commute a priori可以被以任意順序調度，而不會影響最終結果。這樣的特性在數據庫系統很早就被使用，查詢優化器通常會重新調度可交換的操作來產生更有效的序列。Wuu and Bernstein[1984]挖掘數據的交換特性，從而維護一個多Master，可複製的日誌數據結構。在該數據結構中，插入和刪除操作是可交換的，冪等的，這樣調度就不是一個問題了。In GemStone,一個對象可以通知數據庫系統它所含操作的交換特性。數據庫檢測可能的語法衝突，並忽略有數據類型申明的可以交換的衝突操作。
7.2.2典範操作排序
典範次序排序，根據應用語義對操作順序給出正式形式化的描述。它被Ramsey and Csirmaz最先提出，他們對文件系統的樂觀複製和協調進行了形式化描述。這裏，日誌和調度採用了一個形式化的代數關係進行描述，能準確地定義操作間的交換特性。舉例來說，如果一個操作刪除一個目錄，另一個操作（在其它日誌中）刪除該目錄的子目錄，那麼子目錄必須比它的父親先刪除。當這裏沒有自然結構順序，典範順序將是隨意的。（說明：自然結構順序，比如說目錄的父子關係）來自不同日誌的兩個操作（語義上）衝突，要麼是他們不能互換，要麼就是他們的結合破壞了文件系統結構。這很可能發生，比如，如果用戶修改了一個文件，另一個用戶刪除了該文件的父目錄。
調度Multi-log使得共享文件系統的各個副本，儘量的一致“as close as possible”。調度器忽略了重複更新。它不激活衝突操作，它們依賴於先前未激活的操作，並將衝突保存下來，由人工解決。
Ramsey和Csirmaz提出的操作很少，很簡單：創建、刪除、修改。雖然如此，他們整理51條規則。將他們的技術應用到一個更復雜的環境下是一個開放性問題。
7.2.3 IceCube中的語義調度
IceCube是一個與應用無關的複製工具，在基於操作的語義約束上計算最優的調度序列。IceCube支持兩種類型的約束：
1）靜態約束限制的是兩個操作間的關係，不需要訪問被更新對象的狀態。在靜態約束限制中，日誌約束說明在一個日誌中操作間的關係；即，它表示用戶的意圖。比如，一個日誌約束可能加強兩個操作間的執行順序（前後約束），或者它會聲明一個原子的更新單元（包裹約束），或者它可能會申明一些可選操作，供調度器選擇（可選約束）。
一個對象約束，關係到對共享對象的修改操作。定義了四種對象約束：覆蓋（兩個操作更新了同一個對象），互換，互斥，最佳順序（一個比其他順序更好的執行順序）。
2）動態約束，是一個斷言，調度在執行時必須去進行判斷該斷言是否爲真。它可被稱爲Bayou-style“依賴檢查”，或經典的前置和後置條件。
舉例說明，考慮一個旅行計劃應用，採用IceCube運行在非連接網絡環境下。用戶可能會預訂一個航班，爲門票付費，以及計劃在旅途中開一個會。在同一個session中，用戶可能會設置一個不相關會議。當用戶重新連接時，衝突可能會出現，原因可能有航班已滿，不足夠的資金，或者一個衝突的會議時間。
用戶可以將三個相關的操作打包到一起，來表達他的意圖，即當它們中任何一個失敗時就取消所有的操作。這不相關的會議就不被打包到一起。如果另一航班具有相同的作用，則可以作爲一個可選操作。共享日曆實現它的語義，通過將不相融的會議交給用戶手動排除。根據銀行賬戶的語義，向賬戶中存入，和從賬戶支出兩個操作，最好的順序是先存入再支出。最後，銀行設定一個動態的約束，用於支付門票的賬戶不能產生負值。
IceCube調度器，循環地選擇和嘗試滿足靜態約束的調度。如果一個動態約束不被滿足，IceCube將跳過當前調度的執行，處理其他。使用靜態啓發方法，給予最可能成功的操作較高的優先級，根據靜態約束規則以及最近動態約束判斷失敗的經驗來選擇最可能成功的操作。IceCube可以在1秒中調度上千操作。
7.3 操作轉換
操作轉換（OT）目標在於當調度結果不一致時保證最後結果的一致，操作是不能交換的，也不能被重新調度或者回滾。採用操作轉換的典型應用是合作式文本編輯器，每一個操作包含字符改變發生的位置。假設，用戶編輯共享字符串“abc”。用戶1執行insert(“X”,1)產生“Xabc”，然後發送更新給站點2。用戶2執行delete(1)產生“bc”，發送更新給站點1。站點2的執行結果是“Xbc”，與預期的一致。但站點1的結果是“abc”與預期的不一致。OT修改操作的參數，保持它最初的意圖，盡力讓所有節點效果一致，而不是考慮接收的順序。這個例子中，OT發現insert和delete操作併發，它在站點1將delete操作修改爲delete(2)。
OT十分複雜，高度依賴應用語義。轉化一對沖突操作是與直覺緊密聯繫的，當有三個或者更多線程併發，轉化的處理會更加複雜。有理由對這個文件進行形式化處理，採用cormack提出的微積分方法。比如，Palmer和Cormack證明了共享spreadsheet操作轉換的正確性，支持所有常見的操作包括：更新cell值，添加或刪除行或列，以及改變公式。
7.4 解決衝突操作
自然地，衝突解決是高度依賴應用的，很難進行概括。對於operation-transfer系統這一點特別的真實，因爲operatio-transfer系統通常都會描述操作的語義。這一節我們討論Bayou系統，並概括它將應用邏輯和可重用的衝突檢測和調度算法分離的意圖。
Bayou根據更新發生順序進行臨時的調度。它不進行語法衝突的檢測。Bayou系統中的操作包括三個組成部分：一個數據庫查詢稱爲依賴性檢測，一個數據庫更新，和一段代碼叫做合併過程。三個部分都由應用提供，運行在Bayou上。依賴條件判斷負責處理檢查語義衝突。通常，它檢測當前的副本狀態，對於用戶來說是否可以接受當前的更新請求。比如，如果從銀行賬戶劃出賬目，依賴條件會檢查該款項是否超過用戶定義的閾值，因爲賬戶的餘額可能在更新發起時變化。如果依賴條件判斷成功，Bayou將執行更新。如果判斷失敗，合併過程將執行。合併過程可以執行任意必要的操作。比如，如果用戶試圖設定一個約會，依賴條件發現沒有空餘的slot，合併過程可以選擇另一個slot。
在Bayou中編寫一個合併過程並不容易。加在基於狀態解決器上的所有嚴格限制會被應用。實踐表明，即使爲最簡單的應用編寫合併過程也是極其困難的。
7.5 提交操作
本小節討論更新提交協議，比如當副本對一個等價的調度前綴達成一致是，將允許他們提交。提交有三個方面的作用。首先，系統的調度策略可能會產生非確定的結果，這種情況下，站點需要對最終應用的選擇達成一致。其次，提交可以通知用戶一個特定的操作最終被應用到所有的節點。第三，提交可以滿足空間約束的限制，因爲提交後的操作可以被安全地從multi-logs中移除。
7.5.1 Ack Vectors
確認向量與時間戳向量結合使用，從而使站點了解到其它站點的進展。站點i保存確認向量AVi，一個N個元素的時間戳數據組。AVi[i]定義爲TVi[j]中最小的值，j屬於{1…M}。表示，站點i接收了的更新中，沒有哪一個操作的時間戳比AVi[i]更加新，無論更新來自哪個站點。確認向量，向TVs一樣在節點間進行交換，通過成對的最大值比較而被更改。因此，AVi[K]表示站點i保守的估計站點K所接收到的最後更新。這樣的定義下，所有時間戳早於 minAVi[j]的更新可以確定被所有站點已獲取，它們可以被安全的重新排序，提交，和從multi-logs中刪除。這個算法需要採用已同步的較寬鬆的物理時間，作爲時間戳使用。否則，一個時間戳很慢的站點將拖延所有其它站點的確認向量。
（說明：原文這一段真沒看懂）
這種算法比主提交協議要差（我們下面將介紹主提交協議）。首先，它只能被用於語法、基於時間戳的調用。它容易產生live-locking的情況。一個反應遲鈍的節點，會拖延所有站點的確認向量，當站點增多時這種情況會更糟。
7.5.2 Primary Commit Protocol
Bayou實現了一個主提交協議。在這個協議中，所有站點對一個對象，在主站點上的更新取得一致意見（Bayou的一個事務不能訪問多於一個對象）。主站點單方面的，從全局的角度對操作排序，並給予每一個它受到的更新，一個單調遞增的提交順序號CSN。這個主節點可以靈活選擇任意的調度策略；Bayou使用語法的，基於時間戳的排序。操作與CSNs的對應關係，將通過日常更新傳遞給其它站點。一個非主站點，接收到CSN後可以按他們的順序提交操作，並從multi-logs中刪除。
需要注意該協議與單master複製的區別。在主提交協議中，所有的節點都是masters。即使在主節點無法到達的情況下，其它節點仍可以發起，交換，和臨時地應用更新，因爲主節點僅完成CSN的分配。
7.5.3 Quorum Commit Protocal
該協議由Deno提出，是悲觀算法提交協議，但同樣被應用在樂觀環境中，因爲它能在並不是全部節點都可用的情況下執行。在複製的每一步中，採用狀態機方法，對於未解決的請求執行選舉算法來提交每次請求。它給每一個<site,update>對分配一個權重，對於每一次更新總的權重是1.0。每個更新在所有節點週期性循環。當節點收到一個更新時，如果更新與本地其他已完成的更新沒有衝突，該節點投票支持該更新。當節點觀察到對於一個更新的權重達到一個閾值時，節點在本地提交請求，同時它發送一個確認通知給所有其他節點。
通常情況下，提交協議每次順序地處理一個操作。當某個操作與已經提交的操作衝突時，它會被忽略直到他們能相互兼容。Denon允許在應用中聲明操作的可交換性。模擬實驗表明，該協議表現的與經典primary-copy策略十分相似。