雖然 Oceanbase、TiDB 和 CockroachDB 都是原生分布式資料庫，但它們彼此之間有著明顯的架構獨特性：TIDB 集群至少由三個不同的節點角色組成，單點風險較大; 但是，CRDB集群只有乙個節點角色，完全是點對點部署架構，是終極分發最一致的架構。 OB介於兩者之間，實現了點對點部署，但系統中的關鍵功能模組仍然使用集中式服務。
架構差異的主要原因是由於事務處理機制不同。 資料庫在資料計算過程中必須確保 ACID 特徵。 所有資料庫無一例外都使用相同的基本方法，即為每個事務分配乙個遞增的“標誌”，該標誌可以通過比較兩個事務的大小來反映發生的順序，從而為解決衝突提供事實依據。 此外，在資料庫可以操作資料之前，它必須知道資料儲存在哪個節點、磁碟、目錄和檔案上，並且這些路由資訊由元資料維護。 在本機分布式資料庫中，每個計算節點都可以接受 SQL 連線並處理事務請求。 如何保證不同節點上的事務都能獲得全域性遞增的身份？ 如何讓每個節點都能訪問有效的元資料？ 最簡單的解決方案是單獨部署乙個管理節點，所有計算節點在交易發生時都申請交易識別符號，並在管理節點上查詢元資料，以避免資料不一致。 （就像乙個部門，設定乙個領導，什麼都做不做，怎麼做，聽領導的話，避免大家各行其是，最後工作不能合併在一起） TiDB 就是使用這樣的架構，整個集群由多個不同角色的節點組成， 包括：TiDB 節點，是乙個模仿 MySQL 引擎的計算節點;tikv 節點是儲存資料的節點，由 Raft 協議和 RocksDB 組成; 然後是 PD 節點，它們是單獨部署的管理節點，用於處理事務和元資料，它還管理集群的狀態，例如擴充套件、故障識別和響應。 
雖然部署了多個 PD 節點，但其中只有乙個節點負責核心任務（事務管理），其他節點都是為高可用做好準備的從節點。 這種架構簡單、方便、易於實現，但存在以下幾個缺陷：1）管理節點的 leader 出現故障怎麼辦？如果 PD 中的主領導失敗，跟隨者可以重新選擇主。 但是，我們這些做過資料庫運維的人都知道，這種主備切換需要經過發現、重連、故障確認、切換等一系列過程。 如果重試次數和響應時間引數較小，系統經常會在主備之間切換，穩定性會變差。 如果設定很大，則在進行故障轉移後將需要很長時間。 在切換過程中，所有計算節點都需要等待新的 leader 生成，然後分配乙個事務 ID，這樣集群就會被完全壓縮，服務就會暫停。 2） 當管理節點全部出現故障時會發生什麼情況？3-5 個管理節點的數量。
10.對於數百個節點的大型集群來說，畢竟是少量的物理節點，元資料只能儲存在這幾個固定節點中。 因此，系統的生死完全取決於幾個PD節點的健康。 3）跨中心多活動部署更不可能。雖然可以跨地域部署在不同的地方，但遠端節點只能用於容災，不能承接事務性服務，因為遠端事務無法承受去PD Leader申請事務身份、跨幾百千公里訪問元資料所產生的效能消耗。 雖然 TIDB 還是有這些小缺陷，但不可否認的是，它已經是乙個非常好的分布式資料庫了，應該足以應用到一般的業務系統中了。 但是我們不得不考慮，在分布式架構中，有沒有更完善的解決方案，能夠將分布式資料庫從單個少量管理節點的束縛中解放出來，讓計算節點實現更大的自由度、更可靠的系統、更安全的資料？
- 你可以去了解CRDB的架構，或者（**世界觀察）等明天，我將分享CRDB和OB是如何完成的。