一、分布式数据库核心概念与CAP理论

分布式数据库的核心在于通过多节点协作实现数据的高可用与扩展性，但需在CAP理论（一致性Consistency、可用性Availability、分区容忍性Partition Tolerance）中权衡取舍。面试中常问及：”如何理解CAP理论？实际系统中如何选择？”

关键解析：

1. CAP不可兼得性：网络分区时，若选择强一致性（如两阶段提交），则需牺牲可用性；若选择最终一致性（如Gossip协议），则需容忍短暂数据不一致。
2. 实际系统案例：
   • MongoDB：默认采用最终一致性，通过writeConcern参数控制写入级别（如majority确保多数节点确认）。
   • MySQL Cluster：基于NDB引擎，通过同步复制实现强一致性，但写入性能受限于节点间通信。
3. 面试应对策略：强调根据业务场景选择，如金融系统需强一致性，而社交网络可接受最终一致性。

二、数据分片与路由策略

数据分片（Sharding）是分布式数据库扩展的核心手段，面试中常考察分片键选择、路由算法及数据倾斜问题。

核心考点：

1. 分片键设计原则：
   • 均匀分布：避免热点问题（如用户ID哈希分片优于时间戳分片）。
   • 业务无关性：减少跨分片查询（如订单表按用户ID分片，而非订单ID）。
2. 路由算法对比：
   • 哈希取模：简单但扩容困难（需数据迁移）。
   • 范围分片：支持范围查询，但易导致数据倾斜（如按时间范围分片）。
   • 一致性哈希：减少扩容时的数据迁移量（如Redis Cluster）。

3. 代码示例（Java实现哈希分片）：

   public class ShardingRouter {
    private static final int NODE_COUNT = 4;
    public String route(String shardKey) {
        int hash = shardKey.hashCode();
        int nodeIndex = Math.abs(hash % NODE_COUNT);
        return "node-" + nodeIndex;
    }
   }

三、分布式事务与一致性保障

分布式事务是面试中的高频难点，需掌握2PC、3PC、TCC等协议及其适用场景。

深度解析：

1. 两阶段提交（2PC）：
   • 流程：协调者发起准备阶段，参与者锁定资源；协调者根据参与者响应决定提交或回滚。
   • 缺陷：同步阻塞、单点问题（协调者故障时事务悬停）。
2. TCC补偿事务：
   • Try-Confirm-Cancel：通过预留资源、确认执行、补偿回滚实现柔性事务（如支付系统扣款）。
   • Java实现示例：

     public interface TccService {
     boolean tryReserve(String orderId, BigDecimal amount);
     boolean confirmReserve(String orderId);
     boolean cancelReserve(String orderId);
     }

3. 本地消息表：通过消息队列+本地表实现最终一致性（如订单创建后异步通知库存系统）。

四、高可用与故障恢复机制

分布式数据库需具备自动故障检测与恢复能力，面试中常问及：”如何设计高可用架构？”

关键方案：

1. 主从复制与自动故障转移：
   • MySQL主从：通过semi-sync复制确保至少一个从库接收日志。
   • MongoDB副本集：通过heartbeat检测主节点故障，自动选举新主节点。
2. 数据冗余策略：
   • 三副本：多数派写入（如Cassandra的QUORUM级别）。
   • 跨机房部署：避免单数据中心故障（如阿里云PolarDB的跨AZ部署）。
3. 面试技巧：强调监控告警（如Prometheus+Grafana）与自动化运维（如Ansible脚本）。

五、技术选型与面试避坑指南

面试中常要求对比不同分布式数据库，需掌握以下要点：

1. 数据库类型对比：
   | 数据库 | 适用场景 | 一致性模型 | 扩展性 |
   |———————|———————————————|—————————|———————|
   | HBase | 海量稀疏数据（如日志） | 最终一致性 | 行级扩展 |
   | CockroachDB | 强一致性OLTP | 同步复制 | 自动分片 |
   | TiDB | MySQL兼容+水平扩展 | Raft协议 | 无中心分片 |

2. 避坑建议：

   • 避免过度分片：分片数过多导致管理复杂（建议初始分片数≤节点数×2）。
   • 慎用跨分片事务：性能下降显著（如ShardingSphere的XA事务）。
   • 监控指标：关注延迟（P99）、吞吐量（QPS）、错误率（Error Rate）。

六、实战案例：电商订单系统设计

需求：支持每秒万级订单写入，保证数据不丢失且可查询。
解决方案：

1. 分片策略：按用户ID哈希分片，减少跨分片查询。
2. 事务设计：
   • 订单创建：本地事务写入订单表。
   • 库存扣减：通过Saga模式（订单表→库存服务→消息队列）。
3. 高可用：
   • 订单表采用MySQL主从+MHA自动故障转移。
   • 库存服务使用Redis缓存+本地消息表。

面试回答要点：强调分片键选择、事务补偿机制、故障演练（如Chaos Monkey测试）。

七、总结与面试准备建议

1. 核心知识图谱：
   • 理论：CAP、BASE、Paxos/Raft。
   • 实践：分片策略、事务模式、监控体系。
2. 学习资源推荐：
   • 书籍：《Designing Data-Intensive Applications》。
   • 实践：在本地搭建MySQL Cluster或MongoDB副本集。
3. 面试技巧：
   • 结合业务场景回答（如”我们系统需要强一致性，因此选择…”）。
   • 展示故障处理经验（如”曾遇到分片不平衡，通过…解决”）。

通过系统掌握上述内容，开发者可自信应对分布式数据库面试，同时提升实际项目中的技术决策能力。