OB有問必答 | OceanBase 如何做到 RTO < 30秒？

上一期我們談到了 OceanBase 如何保證資料的可靠性，以此為前提，服務可用性就成為了另一個焦點：如果某個服務節點發生了故障，使用者不但希望資料不丢（RPO=0），而且希望服務能夠盡快恢複（RTO 越小越好）。

在曆史上，在傳統資料庫的高可用能力不足時，有很多種高可用方案是結合了硬體和作業系統的高可用能力，不過這些方案通常在架構上過于複雜，而且無法在資料庫層面保證資料的一緻性。随着資料庫内置的高可用能力逐漸完善，使用者也轉向了資料庫自帶的高可用方案，典型代表就是“主從熱備”技術，比如Oracle Data Guard、IBM DB2 HADR 等。

但是，主從熱備技術在高可用上有一個很難解決的問題：當主節點故障的時候，如何讓備用節點快速接管服務。如果讓備用節點判斷主節點的狀态，并且在主節點故障時“自動”接管服務，那麼就會面臨一個緻命的問題，就是“腦裂（Split-brain）”：備用節點和主節點同時提供服務了，兩個節點間的資料将再也無法保持一緻。

為了避免腦裂問題，資料庫的主從熱備機制都不會提供“備庫自動接管服務”的能力，備庫的接管動作要引入人工決策的流程，需要人為在備用節點發起服務接管的動作。這樣一來，RTO 就會達到數十分鐘甚至以小時計。為了避免腦裂問題，同時又減小 RTO，有些資料庫産品引入了自動 failover 的機制，比如Oracle 資料庫的 Fast-Start Failover（FSFO）；但由于引入了額外的元件或者服務，整個解決方案的複雜度明顯增大，而且這些元件或者服務自身的高可用又成了新的問題。總體來說，由于主從熱備的本質沒有發生改變，隻是額外引入了第三方仲裁者的角色，是以這種方案并沒有解決根本問題，也不能100%保證避免腦裂。

OceanBase 利用了 Paxos 協定中的多數派共識機制來保證資料的可靠性，在高可用方面，OceanBase 也利用了同樣的機制。首先，根據 Paxos 協定，在任一時刻隻有多數派副本達成一緻時，才能推選一個leader，其餘的少數派副本則不具備推選 leader 的資格。

其次，如果正在提供服務的 leader 副本遇到故障而無法繼續提供服務，隻要其餘的 follower 副本滿足多數派并且達成一緻，他們就可以推選一個新的 leader 來接管服務，而正在提供服務的 leader 自己無法滿足多數派條件，将自動失去 leader 的資格。是以，我們可以看到 Paxos 協定在高可用方面有明顯的優勢：

1）從理論上保證了任一時刻至多有一個 leader，徹底杜絕了腦裂的情況。

2）由于不再擔心腦裂，當 leader 故障而無法提供服務時，follower 便可以自動觸發選舉來産生新的 leader 并接管服務，全程無須人工介入。

這樣一來，不但從根本上解決了腦裂的問題，還可以利用自動重新選舉大大縮短 RTO，可以說完美解決了主從熱備技術在高可用上所面臨的難題。

當然，這裡面還有一個很重要的因素，那就是 leader出現故障時，follower 能在多長時間内感覺到 leader的故障并推選出新的 leader，這個時間直接決定了RTO 的大小。在OceanBase中，為了能夠及時感覺Paxos 組中各個副本（包括 leader 和 follower）的狀态，在各個副本之間會有定期探活的消息。另一方面，探活機制雖然能夠檢測到節點的故障，但是在網絡不穩定的情況下，也可能由于偶發的探活消息丢包而産生“誤報（False-alarm）”的情況。為了避免誤報對系統穩定性帶來的影響，OceanBase也采取了很多應對措施：

1）首先，探活消息的周期必須要合理。

如果周期太長就不能及時感覺到節點故障，如果周期太短就會增大誤報的機率，而且也可能會影響性能。目前在 OceanBase 中的探活總體耗時為10秒左右，確定能及時感覺到節點故障，并且也不會頻繁産生誤報。

2）其次，要能夠容忍偶發性的消息丢包，減小誤報的機率。

具體來說，OceanBase 不會由于一次探活的失敗就認定某個節點發生了故障，而是在連續多次嘗試都失敗後才确認真正的節點故障。這就有效避免了偶發性消息丢包所導緻的誤報。

3）如果真的發生了誤報，需要将影響範圍降到最小。

OceanBase 将 Paxos 組的粒度下沉到了表的分區一級，也就是每一個分區都會有一個 Paxos 組，用來維護這個分區的多個副本之間的 leader-follower 關系,如果由于少量網絡丢包導緻“某個分區”的探活消息沒有收到回複，那麼受影響的隻是這個分區，同一台機器上的其它分區會照常工作，這就有效地控制了問題的影響範圍。

4）某些特殊情況的處理。

舉個例子，如果某台機器出現間歇性故障（比如網卡或者作業系統出了問題），導緻這台機器頻繁發生網絡傳輸故障，就會使這台機器上所有的 leader 副本持續受到影響。這種情況下，OceanBase 可以通過設定特定參數限制這台機器暫時不參與 leader 選舉，這樣就有效地起到了隔離作用，避免了局部故障對整個叢集的可用性造成持續影響。

在具備了上述這些處理機制後，OceanBase 目前已經能做到最多10秒鐘檢測到服務節點異常，并在10~30秒内完成服務的自動恢複。需要說明的是，具體的恢複時間和遇到問題的機器個數、表的分區個數、故障類型（機器硬體故障、網絡裝置故障等）都有密切的關系，是以上面說的服務恢複時間隻是作為一個參考值，在某些特殊情況下也可能發生偏差。