iT邦幫忙

2021 iThome 鐵人賽

DAY 11
0
AI & Data

資料工程師修煉之路 Part II系列 第 11

Trouble with Distributed Systems (3-2) - Unreliable Clocks

接續 Day 10

時鐘同步和精度 (CLock Synchronization and Accuracy)

昨天講的 單調遞增時鐘 (Monotonic Clock) 不需要同步,而 日曆鐘 (Time-of-Day Clock) 就需要與 NTP 伺服器或外部時間資源做同步,但依舊很不幸的,你希望它應該是正確的時鐘並不是這麼可靠,以下是可能會發生的鬼故事:

  • 電腦內的石英鐘不是那麼準確,它會因為溫度而漂移 (drifts),Google 假設其伺服器的漂移為 200 ppm (百萬分之一 - parts per million),這就代表了重新同步的時鐘每 30 秒會發生 6 毫秒 (ms) 的漂移,或每一天有17 秒的漂移。
  • NTP 伺服器可能意外地被防火墻檔住。
  • NTP 同步的效果跟網路延遲成正相關,一個實驗展示了透過網路進行同步時會有 35 毫秒 (ms) 的最小誤差,在網路壅塞的場景可能會到 1 秒以上。
  • 閏秒會讓一分鐘只有 59 秒或 61 秒長,會讓一些設計不良,沒有考慮到閏秒的系統時序假設壞掉,事實上,閏秒曾讓許多大型系統死亡;最佳的解決方法就是讓 NTP 伺服器說謊,在一天中逐步地調整
  • 在虛擬機中,硬體時鐘也是虛擬的,因為 CPU 資源是與其他 VM 分享,暫時沒在執行的 VM 會暫停幾 10 毫秒,所以從應用系統的角度來看,時鐘就會發生瞬間往前進的情況。

雖然大多數人的公司都不太在意時間問題啦!但如果你的系統是跟投資相關,就會有法規要求你的時間精度,像 MiFID II (歐洲金融市場工具指令)就要求有高頻交易的金融機構,他們的時鐘不得與 UTC 時間有超過 100 微秒以上的誤差。

依靠同步化時鐘

強壯的軟體也是需要為了不準確的時鐘做準備!不準確的時鐘之影響是緩慢且巨大的,如果石英鐘有缺陷或 NTP 使用者端未設定好,應用系統大多數的工作依舊會正常運作,時鐘緩慢的漂移,慢慢的遠離真實時間,直到它發生了意想不到的故障。

因此,若你的應用系統會依靠同步化時鐘,必須要確保和檢測所有機器節點的時間偏移量,任一節點時間漂移過多要視為節點故障並從叢集中移除。

接下來就舉個依賴日曆鐘結果悲劇的例子吧!

順序性事件的時間戳記 (timestamp)

這裡有個 multi-lead (2020 Day 23) 分散式資料庫,資料庫會依靠事件的時間戳記 (timestamp) 做事情;若有 2 個用戶端同時往資料庫寫資料,如下圖 8-3, Client A 寫 x = 1 到 node 1, 它複製資料到 node 2 和 3,Client B 往 node 3 對 x 累加 1(我們知道 x 應為 2)。

每個寫入都依據了日曆鐘標註了發生時的 timestamp,在這個例子中,node 1 和 node 3 的時間偏移小於 3 毫秒 (ms),現在 node 1 x = 1 的 timestamp 為 42.004 秒,但 node 3 x 累加 1 的 timestamp 卻是 42.003 秒,node 2 同時接收到這 2 筆 replica,這就代表了若是使用 最後寫的是贏家 (last write wins) 策略,node 3 的寫入會被丟棄。

就算你使用了 NTP 同步日曆鐘,這種情況還是有可能會發生(如本篇文前半部份講的鬼故事),那這樣怎麼辦呢?我們可以使用一個累加的 counter 來取代日曆鐘解決事件的排序問題,也稱為 邏輯時鐘 (logical clocks),它只關心事件的相關順序,也就是 happns-before 關係。


先這樣啦 XDDDD


上一篇
Trouble with Distributed Systems (3-1) - Unreliable Clocks
下一篇
Trouble with Distributed Systems (4-1) - Truth and Lies
系列文
資料工程師修煉之路 Part II30

尚未有邦友留言

立即登入留言