OpenTenBase学习——分布式数据库 / 集群主流架构分类

分布式数据库与数据库集群的架构可从多个核心维度划分，不同分类对应不同的设计目标（扩展性、一致性、可用性、成本等）。以下是行业主流的架构分类体系，覆盖底层原理、工程实现、高可用等多个视角。

一、经典分类：按核心资源共享模式

这是分布式数据库最本质的底层架构划分，基于计算与存储资源的共享方式区分，直接决定了数据库的扩展上限与瓶颈点。

1. Shared Everything（全共享架构）

• 定义：所有计算单元共享全局内存、磁盘等全部硬件资源，本质是单机对称多处理（SMP）架构的延伸，严格来说不属于典型分布式架构，通常作为对比基准。
• 特点：数据仅一份，无跨节点同步开销，一致性极强；但整体能力受限于单机硬件上限，几乎无法水平扩展。
• 代表产品：单机 MySQL、PostgreSQL，小型机上的集中式数据库。
• 适用场景：中小规模业务，对扩展性要求低、追求极致简单性。

2. Shared Disk（共享存储架构）

• 定义：多个计算节点拥有独立的 CPU、内存，但共享同一份底层存储（SAN 阵列、分布式块存储等），所有节点访问同一份完整数据。
• 特点 ：
  • 计算节点可独立扩容，新增节点无需数据搬迁，生效速度快；
  • 存储层是全局瓶颈，IO 与容量扩展能力有限；
  • 多节点写入需要分布式锁协调，写入扩展性差。
• 代表产品：Oracle RAC、IBM DB2 pureScale、阿里云 PolarDB（共享存储版）、AWS Aurora（计算层共享底层分布式存储）。
• 适用场景：读多写少、需要快速弹性扩读节点的业务，对数据一致性要求高。

3. Shared Nothing（无共享架构）

• 定义：每个节点拥有独立的 CPU、内存、磁盘，节点间仅通过网络交互；数据按规则分片分散存储在不同节点，每个节点仅管理本地分片数据。
• 特点 ：
  • 水平扩展能力极强，可支持上千节点，容量与性能随节点数近似线性提升；
  • 无全局资源瓶颈，可承载超大流量与 PB 级海量数据；
  • 跨节点事务、关联查询、扩容数据重分布成本高，架构复杂度高。
• 代表产品 ：
  • 分析型场景：Greenplum、Teradata、ClickHouse 集群（MPP 大规模并行处理是该架构的典型分支）；
  • 事务型场景：Cassandra、HBase、物理分库分表集群；
  • 存算分离数据库的存储层（如 TiKV）。
• 适用场景：海量数据、高并发、需要持续水平扩展的业务。

二、云原生分类：按计算与存储的耦合度

随着云计算普及，计算存储解耦成为主流演进方向，据此可分为两大类架构。

1. 一体化紧耦合架构

• 定义：每个数据库节点同时承担计算引擎和数据存储职能，计算与存储绑定部署在同一台服务器上。
• 特点：数据本地读写，网络 IO 开销低，延迟表现好；但扩容必须同时扩计算和存储，资源配比不灵活，易出现资源浪费，节点故障恢复需要拷贝数据。
• 代表产品：早期 OceanBase、Greenplum、MongoDB 分片集群、Cassandra。
• 适用场景：对延迟敏感、资源配比稳定的私有化部署场景。

2. 存算分离解耦架构

• 定义 ：计算层和存储层完全解耦、独立部署、独立扩缩容。计算层负责 SQL 解析、优化、执行，无状态；存储层负责数据持久化、多副本高可用。该架构又可细分为两个技术路线：
  • 共享存储型存算分离：底层是统一的共享存储系统，所有计算节点访问同一份数据，本质是 Shared Disk 的云化升级。代表：AWS Aurora、腾讯云 TDSQL-C、阿里云 PolarDB MySQL 版；特点是一写多读，读节点扩容秒级，写入仍受单主节点限制。
  • 分布式存储型存算分离：底层是 Shared Nothing 架构的分布式存储集群，数据分片多副本存储，计算层可访问任意分片数据。代表：TiDB（TiDB 计算层 + TiKV 存储层）、OceanBase 4.0+、Google Spanner；特点是计算和存储均可水平扩展，支持分布式写入，扩展性更强。
• 通用优势：资源按需分配，利用率高；计算节点秒级扩缩容，弹性好；存储层统一做多副本与容灾，运维效率高。
• 适用场景：云原生业务、流量波动大、需要弹性扩缩容的场景。

三、工程实现分类：按分片路由的实现层级

针对水平分片的分布式数据库，根据分片逻辑的实现位置，分为三类落地架构。

1. 客户端分片架构

• 定义：分片路由逻辑实现在应用端或数据库客户端驱动中，应用层直接感知分片规则，自行选择目标节点。
• 特点：无中间层性能损耗，性能最高；但对应用侵入性强，分片规则变更困难，运维成本高。
• 代表产品：Redis Cluster（客户端智能路由）、早期业务自研分库分表方案。
• 适用场景：分片规则稳定、对性能要求极高的场景。

2. 中间件代理架构

• 定义：在应用和底层数据库之间部署一层代理中间件，由中间件统一完成 SQL 解析、分片路由、结果合并、事务协调等工作，底层通常是多个单机数据库实例。
• 特点：对应用透明，侵入性低；底层复用成熟单机数据库，稳定性高；但中间件本身是性能和可用性瓶颈，复杂 SQL、分布式事务支持能力有限。
• 代表产品：ShardingSphere-Proxy、MyCat、Vitess、阿里云 DRDS。
• 适用场景：传统业务快速分布式改造，复杂查询少的 OLTP 场景。

3. 内核原生分布式架构

• 定义：分布式能力完全实现在数据库内核中，从 SQL 层、事务层、存储层原生支持分布式，无需额外中间件。
• 特点：功能完整，对分布式事务、复杂 SQL、全局索引支持度高，一致性保证能力强；技术门槛高，研发周期长。
• 代表产品：TiDB、OceanBase、CockroachDB、Google Spanner、Greenplum。
• 适用场景：大规模核心业务，对事务一致性、SQL 兼容性要求高的场景。

四、高可用分类：按副本共识机制

所有分布式数据库都会搭配多副本高可用架构，主流分为三类。

1. 主从 / 主备复制架构

• 定义：一主一备或一主多从，主节点负责写入，从节点通过日志异步 / 半同步同步数据，可承担读流量；主节点故障时手动或自动切换备节点。
• 特点：实现简单，成本低；存在数据同步延迟，极端切换场景可能丢数据，RPO/RTO 指标一般。
• 代表方案：MySQL 主从复制 + MHA/Keepalived、PostgreSQL 流复制。
• 适用场景：对数据一致性要求不极致的非核心业务。

2. 共享存储多主架构

• 定义：多个节点均可读写，共享同一份存储数据，通过分布式锁协调写入冲突。
• 特点：无主从切换问题，可用性高；写入冲突多，扩展性差，依赖高端存储硬件。
• 代表产品：Oracle RAC。
• 适用场景：传统企业级核心系统，对可用性要求高、写入量不大的场景。

3. 共识协议多副本架构

• 定义：基于 Raft/Paxos 等分布式共识协议，数据写入多数副本成功才返回，自动选主，保证数据强一致和故障自动切换。
• 特点：RPO=0（不丢数据），RTO 秒级，强一致与高可用兼顾；写入需要多数副本确认，延迟略高于主从架构。
• 代表产品：TiDB（TiKV Raft）、MongoDB 副本集、CockroachDB、OceanBase。
• 适用场景：金融、交易、订单等核心业务系统，对数据一致性和可用性要求极高。

五、一致性分类：按 CAP 选型维度

1. 强一致（CP）架构

网络分区发生时，优先保证数据一致性，牺牲部分可用性，通常基于共识协议实现。代表：TiDB、OceanBase、Google Spanner。适用于金融、交易等核心场景。

2. 最终一致（AP）架构

网络分区发生时，优先保证服务可用性，允许数据短暂不一致，最终通过后台同步达成一致。代表：Cassandra、DynamoDB、Redis Cluster 默认模式。适用于社交、内容、日志等高并发非核心场景。

Shared Nothing架构 opentenbase所属

Shared Nothing（无共享）是分布式数据库领域扩展性最强、应用最广的底层架构之一，也是海量数据场景下的主流选型。它的核心思想是彻底消除全局共享资源，通过数据分片 + 节点自治实现近乎线性的水平扩展，下面从设计本质、架构组成、技术分支、优缺点、典型实现等维度展开讲解。

一、核心定义与设计本质

1. 基本定义

Shared Nothing 架构中，每个数据库节点拥有完全独立的 CPU、内存、磁盘，不存在任何全局共享的硬件资源；全量数据按照规则拆分为多个分片，分散存储在不同节点上，每个节点仅负责管理本地分片的数据读写；节点之间仅通过高速网络进行通信与协作。

简单来说：每个节点都是一个独立的 "小型数据库"，各自管一部分数据，互不依赖，靠网络协同完成全局能力。

2. 设计哲学

其核心是 "分而治之"，用大量普通 x86 服务器堆叠，通过水平拆分消除单机硬件瓶颈，最终获得远超集中式数据库的容量、并发和吞吐量。

• 和 Shared Everything 相比：没有共享内存 / 总线瓶颈，不受单机上限约束；
• 和 Shared Disk 相比：没有共享存储的 IO 瓶颈，写入和容量都能随节点数同步扩展。

二、核心架构组成

一套完整的 Shared Nothing 分布式数据库，通常由四个核心模块构成：

1. 数据分片层（Sharding/Partition）

分片是 Shared Nothing 的根基，全量数据会被拆分为多个互不重叠的子集（分片），每个节点承载其中一部分。

• 常见分片策略
  • 范围分片：按分片键的数值区间划分（如按 ID、时间范围），范围查询效率高，但容易出现数据热点；代表：TiDB Region、HBase Region。
  • 哈希分片：对分片键做哈希运算后取模，数据均匀分布在所有节点，完美解决热点问题，但范围查询性能差；代表：Cassandra、Greenplum。
  • 列表分片：按枚举值划分（如按地区、业务线），适合业务边界清晰的场景。
• 分片粒度：粒度越小，扩容和负载均衡越灵活，但元数据管理成本越高；行业常见粒度从几十 MB 到几十 GB 不等。

2. 元数据与路由层

负责记录 "分片 → 节点" 的映射关系，是请求分发的 "导航系统"。

• 中心式路由：由独立的中心节点统一管理元数据和路由，架构清晰、一致性好，中心节点需做高可用；代表：TiDB 的 PD 节点、Greenplum 的 Master 节点。
• 去中心化路由：每个节点都持有全量路由信息，通过 Gossip 等协议同步状态，无单点故障，但元数据存在短暂延迟；代表：Cassandra、Redis Cluster。

3. 节点间通信层

节点之间的高速内网互联是性能的关键，通常采用万兆 / 25G 甚至更高带宽的网络。

• OLTP 场景：跨节点交互少，以低延迟的点对点通信为主；
• OLAP 场景：存在大量数据 shuffle（跨节点数据传输），对网络带宽和延迟非常敏感。

4. 副本与高可用层

为了避免单点故障，每个分片都会在多个节点上保存副本：

• 强一致路线：基于 Raft/Paxos 共识协议，写入必须多数副本确认才返回，自动选主，RPO=0 不丢数据；代表：TiKV、MongoDB 副本集。
• 最终一致路线：通过异步同步复制副本，可用性优先，允许短暂数据不一致；代表：Cassandra 的 NWR 可调一致性模型。

三、两大主流技术分支

Shared Nothing 在事务型和分析型场景下演化出了完全不同的执行模式，差异非常大。

1. 事务型（OLTP）Shared Nothing

核心目标是高并发低延迟的点查、点写，尽量让请求命中单个分片，减少跨节点交互。

• 执行特点：绝大多数业务请求通过分片键路由到单个节点，本地完成读写，性能接近单机数据库；仅少量跨分片事务需要多节点协作。
• 核心痛点：分布式事务开销、非分片键查询性能差、全局索引实现难。
• 典型代表：TiDB（TiKV 存储层）、Cassandra、HBase、MongoDB 分片集群。

2. 分析型（MPP 大规模并行处理）Shared Nothing

核心目标是海量数据的复杂聚合、关联计算，追求极致的计算吞吐量。

• 执行特点：一条 SQL 查询会被拆解为大量子任务，下发到所有持有数据的节点并行执行；中间结果通过网络 shuffle 交换，最终汇总返回给用户。
• 核心优势：数据本地计算，尽量减少数据搬运；计算能力随节点数线性增长。
• 典型代表：Greenplum、ClickHouse 集群、Teradata、Doris/StarRocks。

四、核心优势

1. 近乎线性的水平扩展能力没有共享存储、全局锁等单点瓶颈，容量、并发、吞吐量可随节点数近似线性提升，可支持上千节点、PB 级甚至 EB 级数据，是三种架构中扩展上限最高的。

2. 硬件成本极低完全基于通用 x86 服务器构建，不需要昂贵的小型机、SAN 存储阵列，单位数据量的成本仅为 Shared Disk 架构的几分之一甚至十分之一。

3. 故障隔离性好单个节点故障只会影响其上的分片，不会导致整个集群不可用；配合多副本机制，分片可自动秒级选主恢复，故障影响范围可控。

4. 部署灵活度高可部署在物理机、虚拟机、容器上，支持私有化部署、混合云、公有云；可按需逐步扩容，不需要一次性投入大量高端硬件。

五、核心缺陷与技术挑战

Shared Nothing 的扩展性优势，是以复杂度提升为代价的，这也是它的核心痛点：

1. 分布式事务成本高跨节点事务需要两阶段提交（2PC），增加多轮网络往返和锁等待，延迟显著升高；极端情况下还可能出现事务阻塞、数据不一致风险。业界主流优化方案：TiDB 的 Percolator 乐观事务、OceanBase 的一阶段提交优化、业务层 TCC/Saga 柔性事务。

2. 跨节点查询性能损耗大非分片键查询、跨分片 JOIN、全局聚合需要扫描多个节点，再通过网络传输合并结果，性能远低于单机；复杂 SQL 优化器设计难度呈指数级上升。业界主流优化方案：Colocate Join（同分片键的表数据落在同一节点）、Broadcast Join（小表广播到大表节点）、分布式二级索引。

3. 扩容数据重分布开销大新增节点后，集群需要将现有分片迁移一部分到新节点（数据重平衡 Rebalance），过程中会占用大量 IO 和网络资源，可能影响在线业务；大数据量下迁移周期可达数小时甚至数天。

4. 全局能力实现困难全局唯一主键、全局索引、全局排序等能力，在 Shared Nothing 架构下都需要跨节点协调，要么牺牲性能，要么只能保证最终一致性。

5. 运维复杂度高节点数量多，分片、副本、故障恢复、负载均衡等管理难度大；慢查询、性能瓶颈排查需要跨节点关联分析，对运维团队的技术要求远高于单机数据库。

六、典型产品实现差异

产品	架构类型	分片策略	一致性方案	核心特点
TiDB	存算分离，存储层 Shared Nothing	范围分片（Region）	Raft 强一致 + Percolator 事务	兼容 MySQL，分布式事务完善，适合核心 OLTP
Greenplum	经典 MPP，计算存储一体	哈希分片	本地事务 + 分布式两阶段提交	分析性能强，SQL 兼容性高，适合数仓
Cassandra	完全去中心化 Shared Nothing	一致性哈希	NWR 可调最终一致性	可用性极高，写入性能强，适合日志、时序
ClickHouse 集群	分片 + 副本 Shared Nothing	自定义分片规则	副本异步 / 强一致可选	列式存储，查询吞吐量极高，适合 OLAP
HBase	计算层 Shared Nothing，存储基于 HDFS	范围分片（Region）	行级强一致	基于 Hadoop 生态，适合海量 KV 随机读写

七、适用与不适用场景

适用场景

• 数据量达到 TB/PB 级，单机存储和性能无法满足需求；
• 高并发读写场景，需要持续水平扩展承载业务增长；
• 成本敏感，希望用通用服务器替代高端小型机 / 存储阵列；
• 访问模式清晰，可通过分片键拆分，跨分片操作较少的 OLTP 业务；
• 海量数据分析、离线数仓、用户画像等 OLAP 场景。

不适用场景

• 数据量小、并发低，单机完全可以满足需求；
• 业务逻辑复杂，存在大量跨表关联、全局事务，且无法按分片键拆分；
• 团队运维能力不足，无法支撑复杂分布式集群的排障和调优。