Two-Phase Locking(兩階段鎖定，2PL)
2PL與2PC是完全不同(兩階段提交)的概念。

• 事務A讀取了一個物件，事務B想寫入該物件，必須等A提交或中止才能繼續。(確保B不能在A底下意外的改變物件)
• 事務A寫入了一個物件，事務B想讀取該物件，必須等A提交或中止才能繼續。

2PL與快照隔離的關鍵區別：2PL寫入會阻塞其他的寫入與讀，反之亦然；快照隔離讀不阻塞寫，寫不阻塞讀。
讀、寫的阻塞是通過為資料庫中每個物件新增鎖實現。鎖有共享模式(shared mode)、獨佔模式(exclusive mode)。使用如下：

• 若事務要讀取物件，須先以共享模式獲取鎖。允許多個事務同時持有共享鎖，但如另一事務已在物件持有獨佔鎖，則這些事務必須等待
• 若事務要寫入物件，須先獲取物件的獨佔鎖，如果物件已有任何鎖，該事務必須等待
• 如事務先獲取再寫入物件，則它可能將共享鎖升級為獨佔鎖。
• 事務獲得鎖後，必須持有鎖直到事務結束(提交或中止)。此即為"兩階段"名字的來源：第一階段(事務執行時)獲取鎖;第二階段(事務結束時)釋放鎖。

兩階段鎖定的巨大缺點是效能問題。因為一個事務需要等待另一個事務。

Predicate locks(謂詞鎖)
會議室例子中的幻讀(phantoms)問題，即一個事務改變另一個事務的搜尋結果：一個事務在某個時間視窗搜尋了一個房間的現有預定，則另一個事務不能同時插入或更新同一時間視窗同一房間的另一個預定。
通過謂詞鎖實現上述要求：

Serializable Snapshot Isolation(序列化快照隔離，SSI)
似乎序列化的隔離級別和高效能從根本上是矛盾的，SSI演算法提供一種解決方案：提供完整的可序列化隔離級別，但與快照隔離相比只有很小的效能損失。SSI於2008年首次提出。

---

第八章 分散式系統的麻煩
分散式系統中，儘管系統的其他部分工作正常，但系統的某些部分可能會以某種不可預知的方式被破壞。這被稱為部分失效(partial failure)。難點在於部分失效是不確定性的。這種不確定性，使得分散式系統難以工作！
網際網路和資料中心(通常是乙太網)中的大多數內部網路都是非同步分組網路(asynchronous packet networks)。在這種網路中，一個節點向另一個節點發送的訊息(一個數據包)，不能保證到達時間，或者是否到達。如果傳送請求並期待響應，則很多事情會出錯：

1. 請求已丟失(可能有人拔掉了網線)
2. 請求在排隊，稍後交付(網路或收件人超載)
3. 遠端節點已失效(崩潰或關機)
4. 遠端節點暫時停止響應(可能遇到長時間的垃圾回收暫停)
5. 遠端節點已處理請求，但網路上的響應已丟失(可能是網路交換機配置錯誤)
6. 遠端節點已處理請求，但是響應被延遲(可能是網路或自己的機器過載)

如果網路故障的錯誤處理沒有被軟體定義與測試，則會發生各種意想不到的錯誤。
網路擁塞和排隊

• 如多個不同的節點同時嘗試將資料包傳送到同一目的地，則網路交換機必須將它們排隊逐個送入目標網路鏈路。
• 資料包到達目標機器，如果所有CPU繁忙，則請求被作業系統排隊
• TCP執行流量控制(flow control)，其中節點限制自己的傳送速率以避免網路鏈路或接收節點過載。這意味著在資料甚至進入網路之前，傳送者處需要進行額外的排隊。

不可靠的時鐘
分散式系統中，時間是一件棘手的事情，因為通訊不是即時的：訊息通過網路從一臺機器傳送到另一臺需要時間。
而且，網路上的每臺機器都有自己的時鐘，這是一個實際的硬體裝置：通常是石英晶體振盪器。可以在一定程度同步時鐘：最常用的機制是網路時間協議(NTP)。伺服器則從更精準的時間源(如GPS接收機)獲取時間。
單調鍾與時鐘
時鐘：根據某個日曆返回當前日期和時間，如Java中的System.currentTimeMillis()返回epoch(1970年1月1日 午夜 UTC，格里高利曆)以來的秒數(或毫秒)。
單調鍾：用於測試持續時間(時間間隔)。如Java中的System.nanoTime()。
你可以在某個時間點檢查單調鐘的值，做一些事情，且稍後再次檢查它。這兩個值之間的差異告訴你兩次檢查之間經過了多長時間。但單調鐘的絕對值是毫無意義的：它可能是計算機 啟動以來的納秒數，或類似的任意值。特別是比較來自兩臺不同計算機的單調鐘的值是沒有 意義的，因為它們並不是一回事。
有序事件的時間戳
如果依賴時鐘，在多節點上對事件進行排序，誰先到達？誰後到達？

儘管如此，節點2接收到這兩個事件時，會錯誤的認為x = 1是最近的值，而丟棄x = 2。效果上，client B的增量操作會消失。
在多領導者複製與無領導者複製資料庫中，廣泛使用這種解決策略(last write win,LWW,最後寫入為準)。
暫停程序
Is it crazy to assume that a thread might be paused for so long?Unfortunately not.There are various reasons why this could happen:

• 許多程式語言(如Java虛擬機器)都有垃圾收集器(GC)，偶爾需要停止所有執行中的程序(stop-the-world)
• 虛擬化環境中，可以掛起(suspend)虛擬機器(暫停執行所有程序並將記憶體內容儲存到磁碟)並恢復(恢復記憶體內容並繼續執行)
• 在終端使用者裝置(如膝上型電腦)上，執行也可能被暫停並隨意恢復，如使用者關閉筆記本蓋子
• 作業系統切換到另一個執行緒時，當前執行的執行緒可在程式碼的任意處暫停
• 如應用程式執行同步磁碟訪問，則執行緒可能暫停

領導者與鎖定
通常情況下，一些東西在一個系統中只能有一個，例如：

• 資料庫分割槽的領導者只能有一個節點(避免腦裂，split brain)
• 特定資源的鎖或物件只允許一個事務/客戶端持有，以防同時寫入和損壞
• 一個特定的使用者名稱只能被一個使用者所註冊

分散式系統中實現這一點需要注意：即使一個節點認為它是the choosen one(分割槽負責人、鎖持有者)，但這不一定意味著有法定人數的節點同意！一個節點可能一年是領導者，但是如果其他節點在此期間宣佈它死亡(如網路中斷或GC暫停)，則它可能已被降級，另一個領導者已被當選。

相關推薦