前言

在 TiDB 里面，為了支持分布式事務(wù)，我們通過 PD，這個(gè)全局的單點(diǎn)服務(wù)，為事務(wù)分配全局唯一的時(shí)間，這個(gè)做法就是簡(jiǎn)單高效，但獲取 timestamp 的時(shí)候會(huì)有網(wǎng)絡(luò)開銷。這點(diǎn)對(duì)一些人來說，就認(rèn)為我們?cè)O(shè)計(jì)很挫，事務(wù)延遲會(huì)非常高，從而再推斷出 TiDB 性能很差的結(jié)論。

對(duì)于這些聲音，我們通常不予置評(píng)，不過這里倒是可以聊一聊為什么我們會(huì)考慮使用一個(gè)全局授時(shí)服務(wù)，為什么不考慮其它的一些方案。

在分布式系統(tǒng)的時(shí)間這篇文章里面，我已經(jīng)提到了在分布式系統(tǒng)里面通過時(shí)間來確定事件先后順序的重要性，以及常用的幾種方案，這里在重新過一遍。

TrueTime 或者 HLC

TrueTime 是 Google Spanner 里面提出來的一種方案，它采用硬件的方式來解決了分布式時(shí)間的問題，但硬件畢竟有誤差，所以 Spanner 有一個(gè) commit wait time，也就是必須在等待 2 ε 的時(shí)間后，才能保證讀取數(shù)據(jù)的正確性。

最開始 Spanner 的誤差是 7 ms 左右，但現(xiàn)在隨著硬件的提升，誤差應(yīng)該更小了。但無論怎樣，還是有誤差的，即使 ε 優(yōu)化到 1 ms，事務(wù)因?yàn)?commit wait time 也會(huì)有 2 ms 的延遲。但 Spanner 最大的問題在于因?yàn)槭怯布鉀Q方案，不可能在其他地方大規(guī)模的推廣，通用性不足。

為了解決這個(gè)問題，Kudu 和 CockroachDB 使用了 Hybrid Time 的方案，也就是混合了物理時(shí)鐘和邏輯時(shí)鐘，具體的算法大家可以去參考實(shí)際的 Paper 以及相關(guān)的開源實(shí)現(xiàn)，這里不做過多解釋。

HLC 雖然沒有硬件依賴，但HLC 仍然有一個(gè) bound，需要保證 |l.e - pt.e| 在這個(gè) bound 范圍內(nèi)，如果超過了這個(gè) bound，HLC 就不能正常工作了。所以使用 HLC 仍然有一個(gè) wait time 的問題，只是大家可以選擇到底是 commit 的時(shí)候 wait 還是 read 的時(shí)候 wait。另外，因?yàn)?HLC 依賴 NTP，但 NTP 有可能出現(xiàn)同步錯(cuò)誤等問題，所以通常 HLC 都會(huì)使用一個(gè)比較大的 bound time 來容忍 NTP 的異常。譬如，一些 HLC 的實(shí)現(xiàn)使用了 250 ms 或者 500ms 的 bound，這個(gè)已經(jīng)非常大了，也就是說，如果我們要完全做到線性一致性，延遲會(huì)非常的高。不過如果系統(tǒng)對(duì)強(qiáng)一致性不 care，那么也完全可以將這個(gè) bound 設(shè)置的非常小，或者壓根不處理。

但 HLC 畢竟適用于跨多個(gè) IDC 或者全球化部署的場(chǎng)景，因?yàn)檫@個(gè)時(shí)候，各個(gè)節(jié)點(diǎn)之前本身的網(wǎng)絡(luò)延遲已經(jīng)非常大了，有可能上百 ms 以上，這時(shí)候 HLC 的 bound 問題反倒會(huì)弱化不少。因?yàn)楫?dāng)消息發(fā)到其它節(jié)點(diǎn)的時(shí)候，減去網(wǎng)絡(luò)延遲的時(shí)間，要 wait 的時(shí)間其實(shí)就沒多少了。

Why TSO

TiDB 的事務(wù)模型是基于 Google Percolator 的，所以從一開始，我們就考慮使用的是類似 Percolator 的 Timestamp Oracle（TSO）機(jī)制，由 PD 統(tǒng)一進(jìn)行時(shí)間的分配，除了這么做簡(jiǎn)單之外，還有就是性能的考量。

也許有人會(huì)質(zhì)疑，你都多了一次網(wǎng)絡(luò)開銷了，怎么可能性能好？這個(gè)有一定的道理，但要看情況。如果我們的集群在同一個(gè) IDC，網(wǎng)絡(luò)的開銷是非常的小的，通常一次網(wǎng)絡(luò)請(qǐng)求，都是在 0.1 ms 或者 0.2 ms 就返回，這就是意味著，即使有網(wǎng)絡(luò)開銷，使用 TSO 的方式在一些情況下仍然比 Spanner 或者 HLC 的 lantecy 要低。

如果是跨多 IDC 的場(chǎng)景，雖然網(wǎng)絡(luò)問題避免不了，我們?nèi)匀豢梢杂幸恍┓椒▉砭徑?。譬如可以?TiDB 跟 PD Leader 放在一塊， 這樣獲取 timestamp 仍然很快，只是如果 client 跟 TiDB 沒在一個(gè) IDC，這個(gè)延遲就可能比較高了。但我覺得，一套系統(tǒng)如果跨多 IDC 部署了，用戶也應(yīng)該能理解網(wǎng)絡(luò)延遲高的情況，畢竟現(xiàn)在我們還不能超光速傳輸數(shù)據(jù)。

其實(shí)現(xiàn)在對(duì)我們來說，使用 TSO 最大的問題并不是在 TSO 本身，而是坑爹的 Go 調(diào)度，時(shí)不時(shí)會(huì)抽風(fēng)抖動(dòng)一下，導(dǎo)致獲取 TSO 變慢，這個(gè)現(xiàn)在我們也正在優(yōu)化。

小結(jié)

使用 TSO 也許并不是最優(yōu)，但對(duì)我們來說，現(xiàn)階段是最合適的一種方式，沒準(zhǔn)以后我們可能會(huì)考慮其他的方式，但至少不是現(xiàn)在。

而對(duì)于 HLC 來說，它雖然能解決很多問題，但也并不是解決分布式時(shí)間問題的銀彈，并不是所有的系統(tǒng)都適用的。

我個(gè)人覺得，即使 Google 沒把 TrueTime 的實(shí)現(xiàn)開源，但未來這個(gè)技術(shù)其實(shí)很容易搞定，現(xiàn)在一些大廠已經(jīng)在做了，所以沒準(zhǔn) TrueTime 在未來會(huì)變成一個(gè)通用的解決方案了。

當(dāng)然，更可能我們推翻了現(xiàn)有的物理定律，能超光速傳輸數(shù)據(jù)啥的，不過那時(shí)候，我覺得我們應(yīng)該考慮的是跨星球部署 TiDB 的問題了。