1. Primary-Backup Replication 在传统数据库主备复制的工程取舍。
问题
请阐述 Primary-Backup 复制（主备复制）在传统数据库主备场景中的工程取舍，包括其一致性、可用性与性能的权衡？
考察点
- 主备复制的同步/异步复制语义
- 故障转移与数据丢失风险
- 与 Paxos/Raft 多副本共识的对比
答案
Primary-Backup 复制中只有一个主节点（Primary）接受写请求，其余备节点（Backup）仅被动复制主节点的日志。主节点将写操作同步或异步地复制到备份：同步复制要求备份确认后才对外 commit，可保证强一致（不丢已确认数据），但写延迟受备份 RTT 拖累；异步复制吞吐高但主节点故障时可能丢失最后若干已确认但未复制的写操作。工程上，主备复制通常依赖"主节点故障转移"协议（如选主、心跳）来切换主备，但故障转移本身不是多副本共识，存在"裂脑"（split-brain）风险，因此常需借助租约或 Quorum 仲裁。对比 Paxos/Raft，主备复制实现简单、吞吐高，但一致性与可用性弱于多数派确认。
解析
核心矛盾在于"同步复制保证一致性但降低可用性与延迟，异步复制提高性能但容忍丢数据"。主备复制牺牲了多数派共识的容错能力，把复杂度转移到故障转移与租约机制上，换取简单与高吞吐。
示例代码
// 主备复制的写路径：同步复制需等待备节点 ack
class PrimaryBackup {
List<BackupNode> backups;
boolean syncMode;
long commit(LogEntry e) {
if (syncMode) {
for (BackupNode b : backups) {
if (!b.replicateAndAck(e)) return -1; // 同步失败
}
} else {
backups.forEach(b -> b.asyncReplicate(e)); // 异步不阻塞
}
return apply(e);
}
}