题目重点：明确提交等待的复制条件，区分数据持久、reader可见和新主可恢复。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 明确追问replication模型及设计理由；以下以通用主写/复制读模型推导，不把抽象log-quorum算法声称为Aurora具体实现。
- 客户端需求需声明RPO/RTO、read-your-writes及允许陈旧度；跨AZ与跨region网络延迟不是同一预算。
解题路线
- 写提交先确定ack意味着日志到内存、持久化副本达到条件还是已应用。durable和visible是不同位点；复制收到了日志不证明reader已经重放到用户刚提交的版本。
- 同步复制可降低故障时丢已确认写的风险，却让提交等待网络/慢副本；异步复制降低等待但failover可能丢尾部已确认数据。权衡必须对应业务容忍，不只说“一致性更高”。
- 读写会话可带commit位点，让reader等到满足位点或回writer；否则严格read-your-writes不能靠随机挑低负载reader。等待有deadline，超时返回可解释结果而非装作读到了最新。
- 切主不仅选“看起来最活跃”的实例，需核对持久与应用位点、选主权限和旧writer fencing。网络分区时旧writer不能继续被部分客户端当有效主，避免分叉写。
手动走一遍
订单提交位点100，reader只到98。页面立刻读不到订单不是数据必丢；可以等到100或读writer。若writer失联，新主必须按既定RPO和fencing规则提升，不能同时让旧主继续确认写。
规模与取舍
复制带宽≈日志字节/s×副本传输份数，提交延迟包含所等待副本路径。慢reader积压log数量随写速率和重放差扩大；读路径等待位点会改变尾延迟。
易错点与追问
容易失分的边界
- 把接收日志、flush日志、重放可见混为一谈。
- 异步复制也承诺任意故障零丢失。
- 选新主却没有阻止旧主写。
继续深挖
- 跨region灾备可接受哪些未复制尾部？
- 如何把reader lag转为可执行的读路由策略？
