翻譯CockroachDB的這篇博客?Living without atomic clocks: Where CockroachDB and Spanner diverge（不依賴原子鐘：CockroachDB和Spanner的分野。原文地址?https://www.cockroachlabs.com/blog/living-without-atomic-clocks/）。

因?yàn)樵妮^長，所以分成了兩篇發(fā)布。這是下篇。

TrueTime是如何提供線性一致性的？

好的，回到Spanner和TrueTime。重要的是要記住，TrueTime不能保證時(shí)鐘完全同步。相反，TrueTime給出了集群中節(jié)點(diǎn)之間時(shí)鐘偏移的上限。同步硬件（譯者注：指原子鐘）有助于最小化上限。在Spanner的案例中，谷歌提到了7ms的上限。這很嚴(yán)格了；相比之下，使用NTP進(jìn)行時(shí)鐘同步可能會(huì)在100ms到250ms之間。

那么，在時(shí)鐘之間仍然存在不準(zhǔn)確的情況下，Spanner是如何使用TrueTime來提供線性化的呢？事實(shí)上，它非常簡單。它在等待。在允許節(jié)點(diǎn)報(bào)告事務(wù)已提交之前，它必須等待7毫秒。因?yàn)橄到y(tǒng)中的所有時(shí)鐘都在7ms以內(nèi)，所以等待7ms意味著沒有后續(xù)事務(wù)可以在更早的時(shí)間戳提交，即使更早的事務(wù)是在時(shí)鐘最快7ms的節(jié)點(diǎn)上提交的。相當(dāng)聰明。（譯者注：這就是為什么Spanner的性能不高的原因，因?yàn)槿魏我粋€(gè)事務(wù)提交，至少也需要7ms的時(shí)間用來等待）

細(xì)心的讀者會(huì)注意到，整個(gè)“等待不確定性”的想法并不是基于原子鐘的存在?？梢院芎玫氐却魏蜗到y(tǒng)中的最大時(shí)鐘偏移并實(shí)現(xiàn)線性化。當(dāng)然，在每次寫入時(shí)都必須消耗NTP偏移是不切實(shí)際的（譯者注：這里的意思是，你每提交一個(gè)事務(wù)等待7ms，感覺還是可以接受的；但你每提交一個(gè)事務(wù)等待200ms，這就完全沒法接受了，所以NTP沒法替代原子鐘），盡管最近在這一領(lǐng)域的研究可能有助于將其降低到一毫秒以下。

有趣的事實(shí)是：早期的CockroachDB有一個(gè)隱藏的、可線性化的開關(guān)，基本上可以實(shí)現(xiàn)上述功能，所以從理論上講，如果你確實(shí)有一些原子鐘（或者通常有一個(gè)可接受的最大時(shí)鐘偏移），你會(huì)得到類似Spanner的能力?？紤]到它的測試不足，我們已經(jīng)刪除了它，但隨著云提供商傾向于公開類似TrueTime的API，也許恢復(fù)它是有意義的。

此外芯片級(jí)原子鐘（chip-scaleatomic clock，也稱CPT原子鐘）逐漸走向?qū)嵱?；一個(gè)放在服務(wù)器主板上的芯片級(jí)原子鐘將來會(huì)把石英晶體振蕩器（譯者注：也就是目前計(jì)算機(jī)的本地時(shí)鐘）打得落花流水。（譯者注：這塊我也了解了一下，芯片級(jí)原子鐘是近幾年出現(xiàn)的，結(jié)合了集成電路制造的技術(shù)工藝方法，以相干布居數(shù)囚禁(CPT)原理為基礎(chǔ),研制出來的一種器件級(jí)別的微型化原子頻率基準(zhǔn)產(chǎn)品。相比于傳統(tǒng)的原子鐘（比如銫原子鐘），芯片級(jí)原子鐘體積小、耗電少，但精度有所下降。）

Linearizability真的重要嗎？

更有力的保證是一件好事，但有些比較重要，有些沒那么重要。有先后關(guān)系事務(wù)提交時(shí)間戳顛倒的可能性在實(shí)踐中可能就是一個(gè)沒那么重要問題?？赡馨l(fā)生的情況是，以歷史時(shí)間戳檢查數(shù)據(jù)庫可能會(huì)產(chǎn)生矛盾的情況，即事務(wù)T1（的結(jié)果）在事務(wù)T2已提交后還不可見，即使事務(wù)T1已知早于T2, 因?yàn)樗鼈冇许樞蜿P(guān)系。然而，只有當(dāng)（a）在事務(wù)期間讀取或?qū)懭氲膋ey之間沒有重疊，以及（b）客戶端之間存在可能影響DBMS活動(dòng)的外部低延遲通信通道時(shí)，才會(huì)發(fā)生這種情況。（譯者注：再拿起我們前面分析過的扣款例子，A的賬戶扣款后，就會(huì)觸發(fā)給B發(fā)一個(gè)短信，可以對(duì)外表現(xiàn)出來的確是B先收到了短信，A才扣了款。但這種情況會(huì)有什么影響嗎？可以認(rèn)為基本是沒有的，因?yàn)檫@并不違反事務(wù)最高的隔離級(jí)別Serializability，只是看起來不太符合我們的客觀印象而已。）

對(duì)于順序顛倒可能有問題的情況，CockratchDB使用交易過程中遇到的最大時(shí)間戳作為“順序令牌（causality token）”。它在順序關(guān)系鏈中從一個(gè)參與者傳遞到下一個(gè)參與者，并作為連續(xù)事務(wù)的最小時(shí)間戳，以確保每個(gè)事務(wù)都有一個(gè)有序的提交時(shí)間戳。當(dāng)然，這種機(jī)制并不能正確地排列獨(dú)立的順序鏈，盡管想象一個(gè)有問題的用例需要?jiǎng)?chuàng)造力。（譯者注：這里其實(shí)描述的挺玄乎，其實(shí)本質(zhì)上很簡單，就是記錄一個(gè)事務(wù)的提交時(shí)間戳，并且后面一個(gè)事務(wù)的提交時(shí)間戳不能小于前面的提交時(shí)間戳，從而強(qiáng)制保證了所有事務(wù)提交的單調(diào)遞增。但在CockroachDB中，這肯定不是一個(gè)全局生效的機(jī)制，因?yàn)槟蔷透鶷rueTime一樣了嘛。這里說的挺模棱兩可的，我猜測CockroachDB可能是設(shè)計(jì)了一種特殊的語法，比如跟某個(gè)定制化的hint，用來對(duì)這種情況做兜底處理，后面有機(jī)會(huì)研究一下。）

但TrueTime還有一個(gè)比給事務(wù)排序更重要的用途。當(dāng)啟動(dòng)從多個(gè)節(jié)點(diǎn)讀取數(shù)據(jù)的事務(wù)時(shí)，必須選擇一個(gè)時(shí)間戳，該時(shí)間戳保證至少與所有節(jié)點(diǎn)的最高提交時(shí)間一樣大。如果不是這樣，那么新事務(wù)可能無法讀取已經(jīng)提交的數(shù)據(jù)——這是對(duì)一致性的不可接受的破壞。有了TrueTime，解決方案就很簡單；只需選擇當(dāng)前的TrueTime。由于每個(gè)已經(jīng)提交的事務(wù)必須至少在7ms前提交，因此當(dāng)前節(jié)點(diǎn)取到的時(shí)間就一定大于或等于最近提交的事務(wù)。哇，這既簡單又高效。那么CockroachDB是怎么做的呢？

（譯者注：再簡單闡述一下文章這一節(jié)的論述邏輯，上篇已經(jīng)討論了Linearizability>Serializability，這一節(jié)首先討論了Linearizability在實(shí)踐中并不重要，所以CockroachDB沒有特別著重的去保證Linearizability；但Serializability，也就是分布式事務(wù)的概念，還是要保證的，所以下一節(jié)就會(huì)論述Cockroach是怎么在不依賴Percolator的單點(diǎn)Timestamp Oracle，也不依賴TrueTime的基礎(chǔ)上實(shí)現(xiàn)分布式事務(wù)的。而這個(gè)論證的重點(diǎn)就在于，分布式事務(wù)的提交版本號(hào)必須比已經(jīng)開始的讀更大，否則就會(huì)出現(xiàn)臟讀的情況了，Cockroach怎么避免這一點(diǎn)呢？）

Cockroach如何選擇交易時(shí)間戳？

先簡短的回答一下？是一個(gè)不那么容易也不那么有效的方法。更具體的答案是，CockroachDB在事務(wù)進(jìn)行時(shí)會(huì)為事務(wù)找到一個(gè)合適的時(shí)間戳，如果需要，有時(shí)會(huì)在稍后的時(shí)間戳重新啟動(dòng)。

如前所述，我們?yōu)?strong>事務(wù)選擇的時(shí)間戳必須大于或等于我們打算從中讀取的所有節(jié)點(diǎn)的最大提交時(shí)間戳。如果我們提前知道要讀取的節(jié)點(diǎn)，我們可以向所有的這些節(jié)點(diǎn)發(fā)送一個(gè)并行請(qǐng)求，以獲取最大時(shí)間戳，并使用這個(gè)最新的時(shí)間戳。但這有點(diǎn)笨拙，因?yàn)镃ockratchDB是為了支持讀/寫集不確定的會(huì)話SQL而設(shè)計(jì)的，所以我們無法提前知道節(jié)點(diǎn)。這也是低效的，因?yàn)槲覀兩踔帘仨毜却盥墓?jié)點(diǎn)響應(yīng)才能開始執(zhí)行。除此之外：讀者可能對(duì)Calvin和SLOG感興趣，這是一個(gè)圍繞預(yù)先聲明讀/寫集（盡管放棄了會(huì)話式SQL）開發(fā)的一系列研究，因此能夠避免這類問題。（譯者注：Calvin和SLOG都屬于確定性數(shù)據(jù)庫，deterministic database。對(duì)于需要處理的事務(wù)，確定性數(shù)據(jù)庫會(huì)在全局確定好事務(wù)的順序，并按照這個(gè)順序執(zhí)行。Calvin一系列的確定性分布式事務(wù)模型算是Percolator之外的另一流派，學(xué)術(shù)界研究較多，工業(yè)界不怎么主流）

CockroachDB所做的實(shí)際上與Spanner所做的驚人地相似，盡管時(shí)鐘同步要求要寬松得多。簡單地說：

雖然Spanner總是在寫入后等待，但CockratchDB有時(shí)會(huì)重試讀取。

當(dāng)CockroachDB啟動(dòng)事務(wù)時(shí)，它會(huì)根據(jù)當(dāng)前節(jié)點(diǎn)的wall time（譯者注：一個(gè)專有名詞，可以理解成CockroachDB定義的一個(gè)節(jié)點(diǎn)上的特殊時(shí)間）選擇一個(gè)臨時(shí)提交時(shí)間戳。它還通過添加集群的最大時(shí)鐘偏移量\[commit timestamp, commit timestamp + maximum clock offset]來建立所選wall time的上限。這個(gè)時(shí)間間隔代表了不確定性的窗口。（譯者注：也就是說，CockroachDB的提交時(shí)間戳是一個(gè)時(shí)間窗口）

當(dāng)事務(wù)從各個(gè)節(jié)點(diǎn)讀取數(shù)據(jù)時(shí)，只要不遇到在此間隔內(nèi)寫入的key，它就可以順利進(jìn)行。如果事務(wù)在低于其臨時(shí)提交時(shí)間戳的時(shí)間戳處遇到一個(gè)value，它會(huì)在讀取期間簡單地觀察該值，并在寫入期間覆蓋較高時(shí)間戳處的值。只有當(dāng)觀察到一個(gè)值在這個(gè)不確定性區(qū)間內(nèi)時(shí)，CockroachDB特定的機(jī)制才會(huì)啟動(dòng)。這里的核心問題是，考慮到時(shí)鐘偏移，我們不能確定遇到的值是否在交易開始前提交。在這種情況下，我們只需執(zhí)行不確定性重新啟動(dòng)（uncertainty restart），將臨時(shí)提交時(shí)間戳剛好高于遇到的時(shí)間戳，就可以做到這一點(diǎn)。至關(guān)重要的是，不確定性區(qū)間的上限在重新啟動(dòng)時(shí)不會(huì)改變，因此不確定性窗口會(huì)縮小。從許多節(jié)點(diǎn)讀取不斷更新的數(shù)據(jù)的事務(wù)可能會(huì)被迫多次重新啟動(dòng)，但時(shí)間永遠(yuǎn)不會(huì)超過不確定性間隔，每個(gè)節(jié)點(diǎn)也不會(huì)超過一次。

如上所述，Spanner和CockroachDB之間的對(duì)比是Spanner總是將寫入延遲一小段時(shí)間，而CockroachDB有時(shí)會(huì)延遲讀取。延遲多長時(shí)間？這主要取決于幾乎同時(shí)讀取和寫入同一行的頻率。大多數(shù)時(shí)候，當(dāng)這種情況發(fā)生時(shí)，只需重試一次讀取，因此假設(shè)的2ms讀取變?yōu)?ms。如果運(yùn)氣不好，可能需要多次重試讀取。根據(jù)時(shí)鐘的同步方式，可以進(jìn)行的重試次數(shù)有上限。對(duì)于NTP，這可能是250毫秒，因此即使是最倒霉的事務(wù)也不必因時(shí)鐘相關(guān)原因重試超過250毫秒。

由于CockroachDB依賴于時(shí)鐘同步，節(jié)點(diǎn)會(huì)定期比較它們之間的時(shí)鐘偏移。如果任何節(jié)點(diǎn)超過了配置的最大偏移量，則會(huì)自行終止。如果你想知道當(dāng)違反最大時(shí)鐘偏移量時(shí)會(huì)發(fā)生什么，我們?cè)谶@里已經(jīng)考慮過了。

總結(jié)

如果你已經(jīng)走到了這一步，謝謝你一直堅(jiān)持下去。如果你是新手，這是一件棘手的事情。甚至我們偶爾也需要好好琢磨一下這一切是如何結(jié)合在一起的，而我們創(chuàng)造了這該死的東西。（譯者注：作者的自我調(diào)侃，現(xiàn)在面對(duì)分布式場景下的時(shí)鐘問題，注定是性能和一致性兩方面的艱難取舍。而分布式事務(wù)的研究，歸根結(jié)底，就是要在保證一致性的基礎(chǔ)上，盡可能的達(dá)到更高的性能。）