分布式数据库

CAP 指分布式系统在一致性（所有节点同一时刻看到相同数据）、可用性（每个请求总能得到响应）、分区容错性（网络分区时仍能工作）三者中最多同时满足两个。由于网络故障在公网与机房内不可避免，P 必选，实际是在 C 与 A 之间按业务权衡：CP（etcd、ZooKeeper、HBase）分区时拒绝写入保一致；AP（Cassandra、Eureka、DynamoDB 默认）分区时各分片可用但可能返回旧数据。细化概念：强一致、线性一致、顺序一致、因果一致、最终一致是谱系；实践按操作降级——账户余额要 CP，评论与点赞可用最终一致。BASE 是 AP 的工程化主张：基本可用（限流降级有损服务）、软状态（允许中间态）、最终一致（收敛到一致）。答题点是用业务场景选 CP 或 AP 而非背定义。

Raft 把共识问题拆成领导者选举与日志复制。角色与任期：节点是 leader、follower 或 candidate，时间划分为单调递增的任期 term，任期是逻辑时钟也是正确性基础。选举：follower 随机超时（150 到 300 毫秒量级）未收到心跳则变 candidate，自增任期投票给自己并拉票；获多数票当选 leader，随机超时打散同时竞选；每任期每人只投一票先到先得，保证选举安全（每任期至多一个 leader）。复制：客户端请求进 leader 日志，leader 并行发 appendEntries 给 follower，多数节点持久化后提交并应用状态机，随后通知 follower 提交；leader 通过下次心跳隐式确认。安全性约束：日志匹配（同 index 同 term 则之前全同）、提交只能通过本任期的日志条目间接提交旧任期日志、以及选举限制（投票者日志须不旧于候选人）。成员变更走单步或联合共识。能讲选举与多数派复制即达标。

2PC 基础：协调者准备、提交两阶段，阻塞与协调者单点是缺陷，数据库用高可用协调者（把提交状态本身 raft 复制）缓解。Percolator（Google 论文，TiKV 沿用）把协调者打散进数据：每行主键加列锁的结构，两阶段写入——第一阶段对所有键写数据加预写与锁，其中选一个 primary 锁，其他锁指向它；第二阶段提交 primary（原子写 commit 元数据），再异步清理。死锁与阻塞检测靠锁冲突时回查 primary 状态：已提交则帮忙推进，已回滚则清锁；本质是把事务状态存于行内，用单点 primary 的原子性做提交点，配合时钟快照实现快照隔离加写冲突检测（SI 加 PCW，TiDB 默认，介于 RC 与 RR 之间）。优化：大事务限制、单 region 内走单阶段提交、Pipelined 写入与 async commit 减少延迟。能画 primary 加 secondary 结构图即优秀。

分片键选择是第一决策：高频查询维度做键避免跨分片（用户表按 user_id），热点键要加盐或时间分桶。策略对比：哈希分片分布均匀、实现简单，但不支持范围扫描，扩容需一致性哈希或带槽位映射（Redis Cluster 的 16384 槽）减少迁移；范围分片（TiKV region、HBase、Spanner）按键空间切块，范围查询高效、扩容只需分裂迁移相邻块，但写入热点（自增主键集中尾部，需 pre-split 与打散）；查表分片（目录服务映射键到节点）灵活但元数据服务是瓶颈与单点。再平衡目标是最小迁移达成均衡：范围方案按大小与负载自动分裂与调度（region 调度器搬最繁忙块）；哈希方案用虚拟节点按权重迁移；迁移过程要双写或追增量加切流验证，在线迁移的暂停与回切是工程难点。能对比哈希与范围并讲一次在线扩容流程即完整。

副本放置：多机架与多可用区打散防整体故障。一致性模型谱系：线性一致（读也走共识或读 leader 加租约，etcd 线性读经 leader 校验 quorum）、顺序一致、因果一致（会话保证：单调读、读己之写、单调写）、最终一致（收敛但期间可读旧）。读写组合策略：主从复制读写分离——主写从读有复制延迟，读己之写需粘主或会话令牌；quorum 读写——写 W 副本读 R 副本，W 加 R 大于副本数保证交集读到新值（RWN），调大 R 换强一致牺牲延迟；sloppy quorum 与 hinted handoff 保可用。故障切换：心跳与 lease 判定、leader 选举提升最新副本（比较日志位置）、脑裂防护靠 quorum 与 fencing token（旧主写被拒）。答出谱系加 quorum 公式加 fencing 即高分。