一、CAP理论：分布式系统的三角约束

CAP理论由Eric Brewer于2000年提出，指出分布式系统无法同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）三个特性，必须做出权衡。

一致性（Consistency）：所有节点在同一时刻的数据视图一致。例如，在银行转账场景中，若A账户扣款100元，则所有副本必须立即同步该变更，否则会出现数据不一致。
可用性（Availability）：系统在合理时间内返回响应，即使部分节点故障。例如，电商系统在节点宕机时仍能处理订单，但可能返回过时数据。
分区容忍性（Partition Tolerance）：系统在网络分区时仍能正常运行。例如，跨地域部署的数据库在某个数据中心断网时，其他区域仍可提供服务。

实践建议：根据业务场景选择权衡策略。金融系统通常优先保证CP（如Zookeeper），而社交网络可能选择AP（如Cassandra）。可通过异步复制、最终一致性模型（如Gossip协议）平衡CAP。

二、分片（Sharding）：水平扩展的核心技术

分片是将数据按特定规则分散到多个节点的过程，旨在解决单节点存储与计算瓶颈。

分片键（Shard Key）：决定数据分布的字段，需满足低基数、均匀分布的特性。例如，用户ID的哈希值可作为分片键，避免热点问题。
分片策略：

• 哈希分片：对分片键取哈希后模运算，数据分布均匀但扩容困难。
• 范围分片：按字段范围划分（如时间戳），便于范围查询但可能导致数据倾斜。
• 目录分片：通过中间表映射分片键与节点，灵活性高但增加查询跳数。

实战案例：某电商平台采用用户ID哈希分片，将1亿用户数据分散到10个节点，查询吞吐量提升5倍。但需注意跨分片事务的复杂性，可通过最终一致性或分布式事务框架（如Seata）解决。

三、副本（Replica）：高可用的基石

副本是通过数据复制提升系统可用性与容错能力的机制，分为强同步与异步复制。

强同步复制：主节点写入后需等待至少一个副本确认，确保数据不丢失但牺牲性能。例如，MySQL Group Replication采用Paxos协议实现强一致。
异步复制：主节点写入后立即返回，副本异步追赶，性能高但可能丢失数据。例如，MongoDB的副本集默认异步复制。
多副本一致性协议：

• Raft：简化版的Paxos，通过领导者选举与日志复制实现强一致，广泛用于TiDB、Etcd。
• Gossip协议：通过随机传播消息实现最终一致，适用于Cassandra等AP系统。

优化建议：根据业务容忍度选择复制方式。支付系统需强同步（RPO=0），而日志系统可接受异步复制。副本数量建议为3或5，平衡可用性与成本。

四、分布式事务：跨节点的数据一致性

分布式事务需协调多个节点的操作，常见方案包括两阶段提交（2PC）、三阶段提交（3PC）与TCC（Try-Confirm-Cancel）。

两阶段提交（2PC）：

1. 准备阶段：协调者询问所有参与者是否能提交，参与者锁定资源并返回响应。
2. 提交阶段：协调者根据响应决定全局提交或回滚。
   缺点：同步阻塞、单点问题，实际中较少直接使用。

TCC模式：将事务拆分为三个阶段：

// 示例：转账业务的TCC实现
public interface TccAccountService {
    // 尝试阶段：预留资源
    boolean tryReserve(String fromId, String toId, BigDecimal amount);
    // 确认阶段：提交预留
    boolean confirm(String fromId, String toId, BigDecimal amount);
    // 取消阶段：释放预留
    boolean cancel(String fromId, String toId, BigDecimal amount);
}

优势：非阻塞、适合长事务，但需业务层实现补偿逻辑。

实践建议：优先使用本地消息表、事务消息（如RocketMQ）等最终一致性方案，仅在强一致场景下使用TCC或Saga模式。

五、全局索引与分片路由：查询优化的关键

全局索引是跨分片查询的利器，但需权衡性能与一致性。

全局索引：在所有分片上维护索引，支持快速查询但写入开销大。例如，Elasticsearch的全局索引适用于日志检索。
分片路由：通过路由表或计算规则将查询定向到特定分片。例如，MySQL Router根据分片键哈希值路由SQL。

优化案例：某社交平台通过用户地理位置分片，结合GeoHash编码实现附近人查询，QPS从2000提升至15000。

六、分布式SQL与NewSQL：兼容与创新的平衡

分布式SQL数据库（如CockroachDB、YugabyteDB）通过扩展关系模型支持分布式场景，而NewSQL（如TiDB）结合了NoSQL的扩展性与SQL的易用性。

关键特性：

• 自动分片：无需手动指定分片键，系统自动管理数据分布。
• 分布式执行计划：跨节点优化查询，减少数据移动。
• 在线扩容：支持无缝添加节点，无需停机。

选型建议：传统业务迁移可选TiDB，新项目可评估CockroachDB的强一致性模型。

七、总结与展望

分布式数据库的核心名词反映了技术演进的脉络：从CAP的理论约束，到分片与副本的工程实践，再到分布式事务与全局索引的优化手段。未来，随着AI与边缘计算的融合，分布式数据库将向自动化运维、智能调优方向发展。开发者需深入理解这些术语背后的原理，结合业务场景选择合适的技术栈，方能在分布式时代构建高可用、高性能的系统。