AK4codee
commented
2 years ago 不可靠的網路
如果你傳送請求並期待響應，則很多事情可能會出錯:
- 請求可能已經丟失（可能有人拔掉了網線）。
- 請求可能正在排隊，稍後將交付（也許網路或接收方過載）。
- 遠端節點可能已經失效（可能是崩潰或關機）。
- 遠端節點可能暫時停止了響應（可能會遇到長時間的垃圾回收暫停。
- 遠端節點可能已經處理了請求，但是網路上的響應已經丟失（可能是網路交換機配置錯誤）。
- 遠端節點可能已經處理了請求，但是響應已經被延遲，並且稍後將被傳遞（可能是網路或者你自己的機器過載）。
處理這個問題的通常方法是 超時（Timeout）：在一段時間之後放棄等待，並且認為響應不會到達。但是，當發生超時時，你仍然不知道遠端節點是否收到了請求。
檢測故障
何時需要自動檢測故障節點
- 負載平衡器需要停止向已死亡的節點轉發請求
- 在單主複製功能的分散式資料庫中，如果主庫失效，則需要將從庫之一升級為新主庫
不可靠的時鐘
日曆時鐘
- 日曆時鐘通常與 NTP 同步，這意味著來自一臺機器的時間戳（理想情況下）與另一臺機器上的時間戳相同。
- 根據某個日曆（也稱為 掛鐘時間，即 wall-clock time）返回當前日期和時間。
單調鍾
- 單調鍾適用於測量持續時間（時間間隔）
- 可以在某個時間點檢查單調鐘的值，做一些事情，且稍後再次檢查它。這兩個值之間的差異告訴你兩次檢查之間經過了多長時間。
有序事件的時間戳
邏輯時鐘（logic clock）是基於遞增計數器而不是振盪石英晶體，對於排序事件來說是更安全的選擇。邏輯時鐘不測量一天中的時間或經過的秒數，而僅測量事件的相對順序（無論一個事件發生在另一個事件之前還是之後）。
不可靠的知識與真相
領導者和鎖
- 資料庫分割槽的領導者只能有一個節點，以避免 腦裂
- 特定資源的鎖或物件只允許一個事務 / 客戶端持有，以防同時寫入和損壞。
- 一個特定的使用者名稱只能被一個使用者所註冊，因為使用者名稱必須唯一標識一個使用者。
jxiu0129
at7211
0x171-0
JimmyFUFU
samwu4166
taco0929
The Trouble with Distributed Systems
沒有什麼可以相信的，這世界沒救了，人生好難
Unreliable Networks
Unreliable Clocks
每臺機器都有自己的時間概念，可能比其他機器稍快或更慢
NTP (網路時間協議)，根據一組伺服器報告的時間來調整計算機時鐘
Clock Type
Synchronize Clock
System Pause
Distributed system 中的 node，必須假定其執行可能在任意時刻暫停相當長的時間，即使是在一個 function 的中間。在暫停期間，世界的其它部分在繼續運轉，甚至可能因為該 node 沒有響應，而宣告其死亡。最終被暫停的 node 可能會繼續執行，在再次檢查自己的 clock 之前，甚至可能不會意識到自己進入了睡眠。
Knowledge, Truth, and Lies
在 distributed system 中，我們可以陳述關於行為（系統模型）的假設，並以滿足這些假設的方式設計實際系統
許多 distributed algorithm 都依賴於法定人數，即在 nodes 之間進行投票：決策需要來自多個 nodes 的最小投票數，以減少對於某個特定 node 的依賴。這也包括關於宣告 node 死亡的決定。如果法定數量的 nodes 宣告另一個 node已經死亡，那麼即使該 node 仍感覺自己活著，它也必須被認為是死的，必須遵守法定決定並下臺。
Truth Defined by Most
Leader and Lock
即使一個 node 認為它是 "天選者（the choosen one）"，ex. lock 的持有者，但這並不一定意味著有法定人數的 nodes 同意！一個 node 可能以前是領導者，但是如果其他 nodes 在此期間宣佈它死亡（例如，由於網路中斷或 GC 暫停），則它可能已被降級，且另一個領導者可能已經當選
client 1 get lock -> client1 get into gc -> client 1 lock expired -> client 2 get lock -> client 2 write data -> client 1 wake up and write (will break the system)
Fencing
我們假設每次鎖定 server 授予 lock 或租約時，它還會返回一個 fencing token，這個數字在每次授予鎖定時都會增加（例如，由鎖定服務增加）。然後，我們可以要求 client 每次向 storage service 傳送 write request 時，都必須包含當前的 token。
client 1 get lock ( token 33 ) -> client1 get into gc -> client 1 lock expired -> client 2 get lock ( token 34 ) -> client 2 write data -> client 1 wake up and write but fail since 33 < 34
Byzantine Fault
如果存在 node 可能 “撒謊”（傳送任意錯誤或損壞的響應）的風險，則 distributed system 的問題變得更困難了，例如，如果節點可能聲稱其實際上沒有收到特定的訊息
Byzantine fault-tolerant (拜占庭容錯)，當一個系統在部分 nodes 發生故障、不遵守協議、甚至惡意攻擊、擾亂網路時仍然能繼續正確工作
System Model
Time
Node Failure