1.项目背景
| 项目 |
内容 |
| 成立时间 |
2013年，2015年正式开源 |
| 创始人 |
Spencer Kimball（前谷歌工程师，GIMP创建者之一）、Ben Darnell、Andy Bonventre |
| 公司 |
Cockroach Labs |
| 融资 |
累计融资数亿美元（Benchmark、Google Ventures、Sequoia等投资） |
| 技术渊源 |
基于谷歌发表的 Spanner 和 Paxos 论文 |
| 定位 |
云原生分布式SQL数据库 |
2.核心架构
2.1 整体架构层次
┌─────────────────────────────────────────────────
│ SQL Layer
│ (PostgreSQL Wire Protocol 兼容)
│ • DDL/DML 解析
│ • 查询优化器
│ • 分布式事务执行
└─────────────────────────┬───────────────────────
│
┌─────────────────────────▼───────────────────────
│ Storage Layer
│ • 键值存储 (Key-Value Store)
│ • RocksDB 引擎
│ • Range 分片管理
└─────────────────────────┬───────────────────────
│
┌─────────────────────────▼───────────────────────
│ Replication Layer
│ • Raft 共识协议
│ • Range 多副本同步
│ • Leaseholder 管理
└─────────────────────────┬───────────────────────
│
┌─────────────────────────▼───────────────────────
│ Node 层
│ • 计算 + 存储融合 (Shared-Nothing)
│ • 每个节点独立存储
└─────────────────────────────────────────────────
2.2 核心概念详解
Range（数据分片）
整个 Keyspace (所有数据)
│
├── Range 1: [a, m) → 节点A的Leader + 节点B、C的Follower
├── Range 2: [m, z) → 节点B的Leader + 节点A、D的Follower
├── Range 3: [z, ~) → 节点C的Leader + 节点A、E的Follower
└── ...
| 特性 |
说明 |
| 大小 |
默认约64-68MB |
| 最小单元 |
Range是复制和移动的最小单位 |
| 自动拆分 |
Range增长超过阈值自动Split |
| 自动合并 |
Range缩小后自动Merge |
Raft 共识协议
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Leader │ │ Follower │ │ Follower │
│ (提交写请求)│─────▶│ (复制日志) │ │ (复制日志) │
└─────────────┘ └─────────────┘ └─────────────┘
│ │
│◀──────── 心跳 + 复制响应 ──────────────│
# 写入流程：
客户端 → Leader → 写入本地WAL → 复制给Follower → Quorum确认 → 返回成功
# 读流程：
客户端 → Leaseholder → 直接读取（绕过Raft）→ 返回数据
| Raft 角色 |
职责 |
| Leader |
协调所有写操作，向Follower复制日志 |
| Follower |
接收Leader的日志复制，保持数据一致 |
| Candidate |
竞选Leader的过渡状态 |
Leaseholder（租约持有者）
- 每个Range有一个Leaseholder
- Leaseholder负责服务该Range的所有读请求
- 读写都必须经过Leader（写）或Leaseholder（读）
- Lease定期续约，节点失效则租约丢失
2.3 分布式事务处理
两阶段提交 (2PC) 流程：
Phase 1: Prepare
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Client │───▶│ Node A │───▶│ Node B │
│ │ │ (Writer)│ │(Writer) │
└─────────┘ └─────────┘ └─────────┘
│ │
▼ ▼
Write Intent Write Intent
(事务标记) (事务标记)
Phase 2: Commit
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Client │───▶│ Node A │───▶│ Node B │
│ │ │(Commit) │ │(Commit) │
└─────────┘ └─────────┘ └─────────┘
| 隔离级别 |
说明 |
| Serializable |
默认隔离级别，保证最高一致性 |
| Read Committed |
可选降级，提升性能 |
2.4 节点与集群
┌─────────────────────────────────────────────
│ Cluster
│ (多个跨数据中心/区域的节点)
├──────────┬──────────┬──────────┬───────────
│ Node 1 │ Node 2 │ Node 3 │ Node N
│ (存储+计算)│ (存储+计算)│ (存储+计算)│ (存储+计算)
└──────────┴──────────┴──────────┴───────────
| 部署模式 |
说明 |
| 单节点 |
开发测试用 |
| 多节点集群 |
生产环境推荐至少3节点 |
| 多区域部署 |
跨数据中心容灾 |
| 全球分布式 |
多Region跨洲部署 |
3.技术特点对比
3.1 与主流数据库对比
| 特性 |
CockroachDB |
PostgreSQL |
Spanner |
TiDB |
| 分布式 |
✅ |
❌ (需额外工具) |
✅ |
✅ |
| 水平扩展 |
✅ |
❌ |
✅ |
✅ |
| 强一致性 |
✅ SERIALIZABLE |
✅ |
✅ |
✅ |
| SQL兼容 |
PostgreSQL协议 |
原生 |
自定义 |
MySQL协议 |
| 云支持 |
多云/自托管 |
任意 |
GCP专用 |
多云 |
| 自动分区 |
✅ Range自动Split |
❌ |
✅ |
✅ Table分区 |
| 容灾能力 |
多Region |
需手动 |
内置 |
需配置 |
| 开源 |
✅ (CSL许可) |
✅ (PG许可) |
❌ |
✅ (Apache) |
3.2 核心优势
优势一：PostgreSQL兼容性
├── 使用标准PG Wire协议
├── 大多数PG驱动无需修改即可使用
├── 支持窗口函数、CTE、存储过程
└── 迁移成本低
优势二：自动水平扩展
├── Range自动Split/Merge
├── 数据自动再平衡
└── 无缝添加节点
优势三：高可用性
├── 多副本自动同步
├── Leader故障自动切换
├── 容忍多个数据中心故障
└── 零数据丢失
优势四：强一致性
├── 默认Serializable隔离级别
├── 跨Range事务保证
└── 无最终一致性妥协
4.应用场景
4.1 金融交易场景
| 场景 |
需求 |
CockroachDB方案 |
| 银行转账 |
强一致性、零误差 |
SERIALIZABLE事务保证 |
| 支付处理 |
高并发、低延迟 |
水平扩展支持高吞吐 |
| 风控系统 |
实时分析、数据一致 |
分布式SQL实时查询 |
| 对账系统 |
多节点容错 |
自动故障恢复 |
实际案例：
SumUp（全球支付公司）使用CockroachDB服务400万+商户，覆盖35个市场，满足DORA监管要求，无需按国家部署独立数据库。
4.2 电商场景
| 场景 |
需求 |
CockroachDB方案 |
| 订单处理 |
高并发下单 |
水平扩展吞吐 |
| 库存管理 |
强一致性 |
分布式事务保证库存准确 |
| 用户账户 |
数据安全 |
多副本容灾 |
| 促销峰值 |
弹性伸缩 |
动态扩容 |
4.3 游戏行业
应用场景：
├── 玩家账户数据
├── 游戏道具/货币
├── 实时排行榜
├── 跨区域多人游戏状态同步
└── 游戏存档
优势：
├── 全球部署低延迟
├── 自动分区保证数据局部性
└── 强一致性保证游戏状态正确
4.4 IoT物联网场景
| 场景 |
说明 |
| 设备数据 |
海量设备产生的时序数据 |
| 实时监控 |
设备状态实时查询 |
| 边缘计算 |
多Region部署靠近数据源 |
| 数据聚合 |
跨地域数据汇总分析 |
4.5 SaaS应用
SaaS场景需求：
├── 多租户数据隔离
├── 全球化部署
├── 合规要求（GDPR等）
└── 成本可控
CockroachDB方案：
├── 地理分区控制数据位置
├── 全球单数据库视图
├── 数据本地化存储合规
└── 按节点计费，弹性伸缩
5.典型部署架构
5.1 标准生产部署
每Range 3副本分布在不同可用区
┌─────────────────┐
│ Load Balancer │
│ (HAProxy/LVS) │
└────────┬────────┘
│
┌───────────────────┼───────────────────┐
│ │ │
┌────▼────┐ ┌────▼────┐ ┌────▼────┐
│ Node 1 │ │ Node 2 │ │ Node 3 │
│ (US-East)│ │(US-West) │ │(EU-Central)│
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
┌────▼────┐ ┌────▼────┐ ┌────▼────┐
│ Range A │ │ Range B │ │ Range C │
│ Replica │ │ Replica │ │ Replica │
└─────────┘ └─────────┘ └─────────┘
5.2 多区域容灾部署
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ 区域 A │ │ 区域 B │ │ 区域 C │
│ (主区域) │◄───▶│ (备用区域) │◄───▶│ (备份区域) │
│ │ │ │ │ │
│ ┌─────────────┐ │ │ ┌─────────────┐ │ │ ┌─────────────┐ │
│ │ Node 1,2,3 │ │ │ │ Node 4,5,6 │ │ │ │ Node 7,8,9 │ │
│ │ (Leader) │ │ │ │ (Follower) │ │ │ │ (Follower) │ │
│ └─────────────┘ │ │ └─────────────┘ │ │ └─────────────┘ │
└─────────────────┘ └─────────────────┘ └─────────────────┘
│ │ │
└──────────────────────┴──────────────────────┘
│
Raft复制 (异步/同步)
6.适用与不适用场景
适合使用CockroachDB的场景
| 场景 |
原因 |
| 需要强一致性的OLTP系统 |
SERIALIZABLE隔离级别 |
| 需要水平扩展的高并发系统 |
Range自动分片 |
| 多Region/多云部署 |
全球分布式架构 |
| 传统单机数据库瓶颈 |
无缝迁移替代 |
| 金融/支付关键业务 |
高可用、零数据丢失 |
| 需要PostgreSQL兼容性 |
PG Wire协议 |
不适合使用CockroachDB的场景
| 场景 |
原因 |
| 简单读写密集型应用 |
单机PostgreSQL更轻量 |
| 不需要分布式功能 |
额外运维复杂度 |
| 超大规模分析查询 |
建议搭配ClickHouse等 |
| 成本敏感的小型项目 |
部署至少3节点 |
7.总结
CockroachDB核心价值：
├── 分布式 + SQL = 简化分布式开发
├── PostgreSQL兼容 = 低迁移成本
├── 自动分片 = 无需人工干预
├── 强一致性 = 适合关键业务
└── 云原生 = 多云/多区域部署