本文通過對CnosDB數(shù)據(jù)庫系統(tǒng)時(shí)鐘故障的討論，提出了在單機(jī)環(huán)境和集群環(huán)境中解決系統(tǒng)時(shí)鐘故障的方案，具有非常重要的指導(dǎo)意義。

可能并不存在的情況引發(fā)的討論

有一天，CnosDB實(shí)習(xí)生小邵在做時(shí)間亂序數(shù)據(jù)處理邏輯的設(shè)計(jì)，時(shí)序數(shù)據(jù)的產(chǎn)生一般有以下幾個(gè)規(guī)律可以遵循：

1. 一般情況下，時(shí)序數(shù)據(jù)由一條條時(shí)間線組成，每一條時(shí)間線背后都是一個(gè)獨(dú)立的數(shù)據(jù)源。

2. 時(shí)序數(shù)據(jù)的產(chǎn)生往往是實(shí)時(shí)的，時(shí)間線上的數(shù)據(jù)也是按照時(shí)間順序排列的，大多數(shù)時(shí)序數(shù)據(jù)庫的底層數(shù)據(jù)存儲設(shè)計(jì)也基于此。

3. 在一些特殊的情況下，一條時(shí)間線上的時(shí)間順序可能會被破壞，一段時(shí)間之前的數(shù)據(jù)可能現(xiàn)在才到達(dá)數(shù)據(jù)庫；由于處理起來太過麻煩，一些數(shù)據(jù)庫會拒絕這種數(shù)據(jù)寫入。

問題出在“一些特殊的情況上”，小邵異想天開地提出了一個(gè)我沒有想到過的可能情況：

1. 如果客戶端發(fā)來的數(shù)據(jù)是沒有時(shí)間戳的，那么數(shù)據(jù)的時(shí)間戳由數(shù)據(jù)庫服務(wù)端的系統(tǒng)時(shí)間戳決定。

2. 如果數(shù)據(jù)庫服務(wù)端的系統(tǒng)時(shí)鐘發(fā)生了修改，比如本來是5點(diǎn)，調(diào)成了3點(diǎn)，就會出現(xiàn)時(shí)間亂序數(shù)據(jù)。

不得不說，這是比“一些特殊的情況”還要特殊的情況，而比較典型的時(shí)間亂序數(shù)據(jù)場景是這樣的；一個(gè)遠(yuǎn)程設(shè)備不斷向數(shù)據(jù)庫端發(fā)送自帶時(shí)間戳的數(shù)據(jù)，可能有兩種情況出現(xiàn)：

1. 網(wǎng)絡(luò)方面的故障，導(dǎo)致從設(shè)備發(fā)來的數(shù)據(jù)，并沒有按照數(shù)據(jù)發(fā)出的時(shí)間到達(dá)。

2. 設(shè)備發(fā)出的數(shù)據(jù)在到達(dá)數(shù)據(jù)庫前丟失或損壞了，設(shè)備在之后的時(shí)間里將這些數(shù)據(jù)重新發(fā)給數(shù)據(jù)庫。

經(jīng)過了一段時(shí)間的思考，我發(fā)現(xiàn)小邵說的那種情況，不應(yīng)該放在時(shí)間亂序數(shù)據(jù)的問題里討論，而是一個(gè)需要單獨(dú)處理的問題。

系統(tǒng)時(shí)鐘故障

相比于掉電宕機(jī)、網(wǎng)絡(luò)故障等常見又嚴(yán)重的故障，系統(tǒng)時(shí)鐘發(fā)生變化的情況其實(shí)很少被考慮到，一般主要影響的也都是日志時(shí)間戳之類，不會直接影響到用戶的部分。

近年來，由于NewSQL的概念普及，許多分布式數(shù)據(jù)庫選擇依賴系統(tǒng)時(shí)鐘與NTP實(shí)現(xiàn)混合邏輯時(shí)鐘，這時(shí)系統(tǒng)時(shí)鐘故障可能才真正被廣泛討論。不過，CnosDB是個(gè)典型的原生時(shí)序數(shù)據(jù)庫，不是那種拼接改造的數(shù)據(jù)庫項(xiàng)目，并不支持事務(wù)，所以在這里并不是討論混合邏輯時(shí)鐘的問題。

定義

在具體討論之前，先給系統(tǒng)時(shí)鐘故障一個(gè)明確的定義：指由于惡意攻擊、用戶誤操作等原因，導(dǎo)致數(shù)據(jù)庫部署環(huán)境的系統(tǒng)時(shí)鐘突然發(fā)生跨度較大的變化，比如前一秒系統(tǒng)時(shí)鐘為17:00，下一秒變成了3:19。

由于從數(shù)據(jù)庫的角度無法確認(rèn)這種變化是否正確、是否符合用戶的預(yù)期，所以將這種變化視為故障。

集群中的情況

單機(jī)下的情況比較簡單，就是上文中的定義情況，而集群中的情況可以大致分為三種：

1. 只有少數(shù)節(jié)點(diǎn)的系統(tǒng)時(shí)鐘發(fā)生變化。

2. 超過半數(shù)節(jié)點(diǎn)的系統(tǒng)時(shí)鐘發(fā)生變化。

3. 所有節(jié)點(diǎn)同步切換到新的、相同的系統(tǒng)時(shí)鐘。

對時(shí)序數(shù)據(jù)庫的影響

就像上文中小邵所說的“特殊情況”，系統(tǒng)時(shí)鐘故障會影響沒有自帶時(shí)間戳的數(shù)據(jù)，其背后是時(shí)序數(shù)據(jù)庫對這類數(shù)據(jù)處理的策略：

1. 要求用戶寫入的所有數(shù)據(jù)都必須自帶時(shí)間戳。

2. 對于沒有時(shí)間戳的數(shù)據(jù)，自動添加客戶端的系統(tǒng)時(shí)間戳。

3. 對于沒有時(shí)間戳的數(shù)據(jù)，自動添加數(shù)據(jù)庫服務(wù)端的系統(tǒng)時(shí)間戳。

據(jù)我觀察，目前策略三應(yīng)該是比較主流的方案，所以一個(gè)時(shí)序數(shù)據(jù)庫最好還是要考慮如何處理系統(tǒng)時(shí)鐘故障。否則，一旦出現(xiàn)問題，就會有大量“時(shí)間戳異常”的數(shù)據(jù)寫入到數(shù)據(jù)庫中，影響到數(shù)據(jù)庫的性能還是小事，出現(xiàn)了用戶角度的“臟”數(shù)據(jù)就是大麻煩了。

故障的處理

根據(jù)既往的經(jīng)驗(yàn)和知識，一個(gè)足夠健壯的系統(tǒng)，在處理故障時(shí)需要依循以下四個(gè)原則：

1. Fail-Fast：能夠第一時(shí)間發(fā)現(xiàn)故障的產(chǎn)生。

2. Fail-Safe：盡將故障的影響范圍控制在最小。

3. Fail-Over：在發(fā)生故障時(shí)能夠進(jìn)行主備切換，由沒有發(fā)生故障的備份/備用節(jié)點(diǎn)繼續(xù)提供服務(wù)。

4. Fail-Back：在主副本/主節(jié)點(diǎn)從故障狀態(tài)恢復(fù)到正常狀態(tài)之后，可以切回到主副本/主節(jié)點(diǎn)提供服務(wù)。

基于這樣的原則，針對單機(jī)和集群兩種情況，做出了以下設(shè)計(jì)。

單機(jī)：發(fā)現(xiàn)故障然后服務(wù)降級

在單機(jī)的環(huán)境中，系統(tǒng)發(fā)現(xiàn)故障之后，需要做以下的操作：

1. 周期性獲取當(dāng)前系統(tǒng)時(shí)間戳，并與上一次獲取到的值對比，如果兩者的偏差超過了容忍閾值，判定為出現(xiàn)了時(shí)鐘故障。

2. 用戶可以通過查看系統(tǒng)表中的某項(xiàng)，查看當(dāng)前CnosDB節(jié)點(diǎn)是否處于時(shí)鐘故障狀態(tài)，此狀態(tài)不會因CnosDB進(jìn)程的重啟而變化。

3. 出現(xiàn)故障后，只允許用戶自行指定時(shí)間戳的數(shù)據(jù)寫入，拒絕未指定時(shí)間戳的數(shù)據(jù)寫入。

4. 用戶可以通過使用管理員權(quán)限執(zhí)行一條命令，解除當(dāng)前CnosDB節(jié)點(diǎn)的時(shí)鐘故障狀態(tài)。

我們在處理單機(jī)故障時(shí)，可以用以下的用戶接口設(shè)計(jì)去定義：

統(tǒng)一的命名規(guī)則

clock_fault_XX

系統(tǒng)變量/參數(shù)

1. clock_fault_check_interval

a. 獲取系統(tǒng)時(shí)間戳并進(jìn)行檢查的時(shí)間間隔。

b. 默認(rèn)值5min，可在線變更。

2. clock_fault_last_timestamp

a. 最后一次獲取到的系統(tǒng)時(shí)間戳。

b. 只讀。

3. clock_fault_check_threshold

a. 時(shí)鐘故障的觸發(fā)閾值。

b. 當(dāng)前系統(tǒng)實(shí)際時(shí)間戳與clock_fault_last_timestamp + clock_fault_check_interval的差值超過此閾值時(shí)，當(dāng)前CnosDB節(jié)點(diǎn)切換為時(shí)鐘故障狀態(tài)。

c. 默認(rèn)值為1h，可在線變更。

4. clock_fault_state

a. 當(dāng)前CnosDB節(jié)點(diǎn)是否處于時(shí)鐘故障狀態(tài)

b. 處于時(shí)鐘故障狀態(tài)，此值為error；反之，為normal。

c. CnosDB將此值設(shè)置為error時(shí)，需要同時(shí)在日志中進(jìn)行記錄。

d. 可在線變更，但只能由CnosDB管理員手動設(shè)置為normal，代表CnosDB管理員對目前的情況已經(jīng)完全掌握并進(jìn)行了相應(yīng)的處理。

系統(tǒng)時(shí)間線

clock_fault_timestamp：記錄每次進(jìn)行檢查時(shí)獲取的系統(tǒng)時(shí)間戳，用戶可以通過查看此時(shí)間線來判斷時(shí)鐘故障發(fā)生的具體時(shí)間點(diǎn)。

集群：復(fù)雜的故障發(fā)現(xiàn)與主備切換機(jī)制

在集群環(huán)境中，因?yàn)槎喙?jié)點(diǎn)的原因，處理的過程相對于單機(jī)的機(jī)制會更加的復(fù)雜，那么也有以下的相應(yīng)操作：

1. 以每個(gè)CnosDB節(jié)點(diǎn)的單節(jié)點(diǎn)故障處理為基礎(chǔ)。

2. 當(dāng)一個(gè)節(jié)點(diǎn)處于時(shí)鐘故障狀態(tài)時(shí)，未指定時(shí)間戳的數(shù)據(jù)寫入將自動路由到其他節(jié)點(diǎn)進(jìn)行執(zhí)行。

3. 定期檢查集群所有節(jié)點(diǎn)的系統(tǒng)時(shí)鐘：

a. N為當(dāng)前集群內(nèi)的主機(jī)（物理機(jī)、虛擬機(jī)或容器）總數(shù)量， μ為集群內(nèi)全部主機(jī)某個(gè)子集，μ包含的主機(jī)數(shù)量超過N/2。

b. 如果存在一個(gè)μ在兩個(gè)節(jié)點(diǎn)間的系統(tǒng)時(shí)間戳差值不超過一個(gè)預(yù)先設(shè)定的閾值，這個(gè)μ就可以稱為時(shí)鐘基準(zhǔn)主機(jī)組。

c. 時(shí)鐘基準(zhǔn)主機(jī)組應(yīng)盡可能包含更多主機(jī)。

d. 如果部署在時(shí)鐘基準(zhǔn)主機(jī)組中的所有節(jié)點(diǎn)都沒有處于時(shí)鐘故障狀態(tài)，這些節(jié)點(diǎn)的集合就可以成為時(shí)鐘基準(zhǔn)節(jié)點(diǎn)組。

e. 當(dāng)集群中無法找出一個(gè)時(shí)鐘基準(zhǔn)節(jié)點(diǎn)組時(shí)，整個(gè)集群將被判定為處于時(shí)鐘異常狀態(tài)。

f. 只有當(dāng)集群中可以找到時(shí)鐘基準(zhǔn)節(jié)點(diǎn)組時(shí)，CnosDB集群管理員才可以將集群解除時(shí)鐘異常狀態(tài)。

g. 當(dāng)某一節(jié)點(diǎn)的系統(tǒng)時(shí)鐘與時(shí)鐘基準(zhǔn)主機(jī)組中一個(gè)節(jié)點(diǎn)的系統(tǒng)時(shí)鐘的差值超過了一個(gè)預(yù)先設(shè)定的閾值，集群會將該節(jié)點(diǎn)的clock_fault_state設(shè)置為error（通過集群內(nèi)部的一個(gè)賬號，一般用戶無法進(jìn)行這樣的操作）。

我們在處理集群故障時(shí)，可以用以下的用戶接口設(shè)計(jì)去定義：

統(tǒng)一的命名規(guī)則

cluster_clock_fault_XX

系統(tǒng)變量/參數(shù)

1. cluster_clock_fault_check_interval

a. 集群范圍內(nèi)進(jìn)行clock_fault_check的時(shí)間間隔。

b. 默認(rèn)值5min，可在線變更。

2. cluster_clock_fault_check_threshold

a. 用于判定時(shí)鐘基準(zhǔn)節(jié)點(diǎn)是否存在的閾值。

b. 默認(rèn)值為10s，可在線變更。

3. cluster_clock_fault_state

a. 當(dāng)前CnosDB集群處于時(shí)鐘故障狀態(tài)時(shí)，此值為error；反之，為normal。

b. CnosDB將此值設(shè)置為error時(shí)，需要同時(shí)在日志中進(jìn)行記錄。

c. 可在線變更，但只能由CnosDB管理員手動設(shè)置為normal，代表CnosDB管理員對目前的情況已經(jīng)完全掌握并進(jìn)行了相應(yīng)的處理。

系統(tǒng)時(shí)間線

1. cluster_clock_fault_base_clock_node_list：記錄當(dāng)前基準(zhǔn)時(shí)鐘節(jié)點(diǎn)組包含的節(jié)點(diǎn)列表。

2. cluster_clock_fault_base_clock_host_list：記錄當(dāng)前基準(zhǔn)時(shí)鐘主機(jī)組包含的節(jié)點(diǎn)列表。

結(jié)語

盡管系統(tǒng)時(shí)鐘故障并不是一個(gè)時(shí)序數(shù)據(jù)庫首要去考慮如何處理的故障，對于集群層面的時(shí)鐘故障檢測與處理，可能也不需要直接放在時(shí)序數(shù)據(jù)庫這一層來實(shí)現(xiàn)，但這個(gè)思考和做大體設(shè)計(jì)的過程還是很有趣的，于是決定分享給大家。

如果大家有真實(shí)遇到這種問題的案例，可以告訴我們，這樣本文中的設(shè)計(jì)會考慮得更加嚴(yán)謹(jǐn)，也會更快地在CnosDB中落地。

CnosDB簡介

CnosDB是一款高性能、高易用性的開源分布式時(shí)序數(shù)據(jù)庫，現(xiàn)已正式發(fā)布及全部開源。

歡迎關(guān)注我們的社區(qū)網(wǎng)站：https://cn.cnosdb.com? ?