虽然 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是如何完成的。