2. 分布式存储核心概念与理论基础

面试问题：请解释 CAP 定理，并举例说明在分布式存储中如何取舍。

面试官考察点：理论理解深度、实际工程权衡能力、能否结合实际系统（如 HBase / Cassandra）说明。

回答框架：
① 定理定义：C（强一致性）、A（可用性）、P（分区容错性），三者最多同时满足两个。
② 解释分区容忍的必要性：网络分区是常态，P 必须选。
③ 权衡：CA（传统单库）、CP（一致优先）、AP（可用优先），举例对应系统。

简短示例回答：
“CAP 定理即 Consistency、Availability、Partition tolerance 三者不能兼得。在分布式存储中，P 是必须的，因此实际在 C 和 A 间取舍。例如 ZooKeeper 选择 CP，保证强一致但牺牲部分可用性；Cassandra 选择 AP，保证高可用但最终一致。”

可能追问：
▪ 什么是“最终一致性”？和强一致性的性能差异？
▪ 如果网络恢复，系统如何从 CP 模式切换到 AP？

避坑提醒：
❌ 避免说“CAP 定理是正确的”，实际在分区恢复后系统可趋向一致。
✅ 强调真实系统通常是在一致性和可用性之间做动态平衡，而不是完全选一端。

面试问题：BASE 理论是什么？它和 ACID 有什么关系？

面试官考察点：对分布式事务和最终一致模型的理解，能否区分不同场景。

回答框架：
① BASE 全称：Basically Available（基本可用）、Soft state（软状态）、Eventually consistent（最终一致）。
② 对比 ACID：ACID 强一致，BASE 弱一致；ACID 用于单机事务，BASE 用于分布式海量数据。
③ 典型场景：购物车、朋友圈点赞等允许短时不一致的读。

简短示例回答：
“BASE 是 ACID 在分布式下的对立模型，强调基本可用和最终一致。例如 DynamoDB、Cassandra 等 NoSQL 数据库核心思想就是 BASE。读请求可能返回旧数据，但经过少量时间后所有副本趋于一致。”

可能追问：
▪ 最终一致的时间窗口如何控制？引入 Quorum 机制？
▪ 什么时候必须回到 ACID（如支付、账号扣款）？

避坑提醒：
❌ 不要将 BASE 等同于“不可用”，基本可用指系统大部分功能正常。
✅ 结合 CAP：BASE 对应 AP 系统时的具体实现策略。

面试问题：Gossip 协议的原理是什么？在分布式存储中如何保证最终一致性？

面试官考察点：对无中心节点通信协议的理解，传播效率与冗余控制。

回答框架：
① 核心：类似“谣言传播”，每个节点随机选择 k 个节点交换状态。
② 传播模型：周期性 push/push-pull 模式，信息快速覆盖全集群。
③ 容错性：节点加入/离开无需中心协调，对网络分区有韧性。

简短示例回答：
“Gossip 协议是无中心节点的分布式通信机制。每个节点周期向随机节点发送自身状态，收到方合并并继续传播。在 Cassandra 中用于节点发现和元数据同步，传播数轮后集群全部知晓，保证最终一致。”

可能追问：
▪ 如何避免消息冗余无限放大？使用反熵（Anti-Entropy）和种子节点？
▪ 延迟与收敛时间如何估算？

避坑提醒：
❌ 不要忽略消息风暴问题，生产中通常会限制扇出数（如 fanout=3）。
✅ 强调 Gossip 适合集群规模不大（<1000 节点），超出时需结合种子节点或分层 Gossip。

项目名称：自研分布式 Key-Value 存储系统（ODKVS）

业务背景：公司业务需要毫秒级读写、水平扩展的 KV 存储，替换单机 Redis 集群痛点（分片不均衡、运维复杂）。

规模指标：日均 QPS 200 万 +；存储节点 50 台；单节点 1TB SSD；数据总量 ~10TB。

技术栈：Go（业务层）、Raft 一致性库（etcd/raft）、Gossip 节点发现、一致性哈希分片、RocksDB 持久化引擎。

核心难点：
▪ 节点扩缩容时数据迁移抖动大 → 设计虚拟节点 + 后台平滑迁移。
▪ 强一致与高可用矛盾 → 采用 Raft 单组内强一致，跨组最终一致。

面试高频追问：
“Raft 的 Leader 选举在分区时如何行为？”
“一致性哈希的虚拟节点如何避免热点？”
“Gossip 协议在扩缩容时如何通知全集群？”

可迁移回答话术：
“在我们自研的 KV 存储中，采用 Raft 集群保证每个分片内的强一致，使用虚拟一致性哈希实现数据均匀分布。扩缩容时，Gossip 协议自动传播节点变化，后台搬迁线程以批处理方式迁移数据，避免瞬间冲击。这对任何需要高可用、强一致的分片存储系统（如 TiKV）都有参考价值。”