前言
在 TiDB 里面决侈，為了支持分布式事務(wù)史飞，我們通過 PD，這個全局的單點服務(wù)瓷翻，為事務(wù)分配全局唯一的時間聚凹，這個做法就是簡單高效，但獲取 timestamp 的時候會有網(wǎng)絡(luò)開銷齐帚。這點對一些人來說妒牙，就認為我們設(shè)計很挫，事務(wù)延遲會非常高对妄，從而再推斷出 TiDB 性能很差的結(jié)論湘今。
對于這些聲音，我們通常不予置評剪菱，不過這里倒是可以聊一聊為什么我們會考慮使用一個全局授時服務(wù)摩瞎，為什么不考慮其它的一些方案。
在分布式系統(tǒng)的時間這篇文章里面孝常，我已經(jīng)提到了在分布式系統(tǒng)里面通過時間來確定事件先后順序的重要性旗们，以及常用的幾種方案，這里在重新過一遍构灸。
TrueTime 或者 HLC
TrueTime 是 Google Spanner 里面提出來的一種方案上渴，它采用硬件的方式來解決了分布式時間的問題，但硬件畢竟有誤差喜颁，所以 Spanner 有一個 commit wait time稠氮，也就是必須在等待 2 ε 的時間后，才能保證讀取數(shù)據(jù)的正確性洛巢。
最開始 Spanner 的誤差是 7 ms 左右括袒，但現(xiàn)在隨著硬件的提升，誤差應(yīng)該更小了稿茉。但無論怎樣锹锰，還是有誤差的芥炭，即使 ε 優(yōu)化到 1 ms，事務(wù)因為 commit wait time 也會有 2 ms 的延遲恃慧。但 Spanner 最大的問題在于因為是硬件解決方案园蝠，不可能在其他地方大規(guī)模的推廣，通用性不足痢士。
為了解決這個問題彪薛，Kudu 和 CockroachDB 使用了 Hybrid Time 的方案，也就是混合了物理時鐘和邏輯時鐘怠蹂，具體的算法大家可以去參考實際的 Paper 以及相關(guān)的開源實現(xiàn)善延，這里不做過多解釋。
HLC 雖然沒有硬件依賴城侧，但HLC 仍然有一個 bound易遣，需要保證 |l.e - pt.e| 在這個 bound 范圍內(nèi)，如果超過了這個 bound嫌佑，HLC 就不能正常工作了豆茫。所以使用 HLC 仍然有一個 wait time 的問題，只是大家可以選擇到底是 commit 的時候 wait 還是 read 的時候 wait屋摇。另外揩魂，因為 HLC 依賴 NTP，但 NTP 有可能出現(xiàn)同步錯誤等問題炮温，所以通常 HLC 都會使用一個比較大的 bound time 來容忍 NTP 的異常火脉。譬如，一些 HLC 的實現(xiàn)使用了 250 ms 或者 500ms 的 bound柒啤，這個已經(jīng)非常大了忘分，也就是說，如果我們要完全做到線性一致性白修，延遲會非常的高。不過如果系統(tǒng)對強一致性不 care重斑，那么也完全可以將這個 bound 設(shè)置的非常小兵睛，或者壓根不處理。
但 HLC 畢竟適用于跨多個 IDC 或者全球化部署的場景窥浪，因為這個時候祖很，各個節(jié)點之前本身的網(wǎng)絡(luò)延遲已經(jīng)非常大了，有可能上百 ms 以上漾脂，這時候 HLC 的 bound 問題反倒會弱化不少假颇。因為當消息發(fā)到其它節(jié)點的時候，減去網(wǎng)絡(luò)延遲的時間骨稿，要 wait 的時間其實就沒多少了笨鸡。
Why TSO
TiDB 的事務(wù)模型是基于 Google Percolator 的姜钳，所以從一開始，我們就考慮使用的是類似 Percolator 的 Timestamp Oracle（TSO）機制形耗，由 PD 統(tǒng)一進行時間的分配哥桥，除了這么做簡單之外，還有就是性能的考量激涤。
也許有人會質(zhì)疑拟糕，你都多了一次網(wǎng)絡(luò)開銷了，怎么可能性能好倦踢？這個有一定的道理送滞，但要看情況。如果我們的集群在同一個 IDC辱挥，網(wǎng)絡(luò)的開銷是非常的小的犁嗅，通常一次網(wǎng)絡(luò)請求，都是在 0.1 ms 或者 0.2 ms 就返回般贼，這就是意味著愧哟，即使有網(wǎng)絡(luò)開銷，使用 TSO 的方式在一些情況下仍然比 Spanner 或者 HLC 的 lantecy 要低哼蛆。
如果是跨多 IDC 的場景蕊梧，雖然網(wǎng)絡(luò)問題避免不了，我們?nèi)匀豢梢杂幸恍┓椒▉砭徑馊椤Ｆ┤缈梢詫?TiDB 跟 PD Leader 放在一塊肥矢， 這樣獲取 timestamp 仍然很快，只是如果 client 跟 TiDB 沒在一個 IDC叠洗，這個延遲就可能比較高了甘改。但我覺得，一套系統(tǒng)如果跨多 IDC 部署了灭抑，用戶也應(yīng)該能理解網(wǎng)絡(luò)延遲高的情況十艾，畢竟現(xiàn)在我們還不能超光速傳輸數(shù)據(jù)。
其實現(xiàn)在對我們來說腾节，使用 TSO 最大的問題并不是在 TSO 本身忘嫉，而是坑爹的 Go 調(diào)度，時不時會抽風抖動一下案腺，導致獲取 TSO 變慢庆冕，這個現(xiàn)在我們也正在優(yōu)化。
小結(jié)
使用 TSO 也許并不是最優(yōu)劈榨，但對我們來說访递，現(xiàn)階段是最合適的一種方式，沒準以后我們可能會考慮其他的方式同辣，但至少不是現(xiàn)在拷姿。
而對于 HLC 來說惭载，它雖然能解決很多問題，但也并不是解決分布式時間問題的銀彈跌前，并不是所有的系統(tǒng)都適用的棕兼。
我個人覺得，即使 Google 沒把 TrueTime 的實現(xiàn)開源抵乓，但未來這個技術(shù)其實很容易搞定伴挚，現(xiàn)在一些大廠已經(jīng)在做了，所以沒準 TrueTime 在未來會變成一個通用的解決方案了灾炭。
當然茎芋，更可能我們推翻了現(xiàn)有的物理定律，能超光速傳輸數(shù)據(jù)啥的蜈出，不過那時候田弥，我覺得我們應(yīng)該考慮的是跨星球部署 TiDB 的問題了。
