多地域双活数据库，写入的时间花在哪里

一次下单请求里，几条SQL执行得很快，用户却迟迟看不到“下单成功”。换成可以就近读写的多地域数据库，能把这段等待一起消掉吗？

AWS在2026年7月28日发布、8月更新的Aurora DSQL扩展实践，适合拿来拆解这个问题。它把事务执行与提交协调分开了。理解这项设计的价值，需要沿着一次写入走到最后，不能停在SQL执行完成的地方。

就近执行之后，还要等一次确认

根据AWS的架构说明，DSQL多地域集群在接收请求的地域执行事务，修改数据的事务到提交时才进行跨地域协调。只读事务不需要承担这一步写入提交的协调成本。这里的“本地”，指数据库地域内，不是用户手机到数据库的网络距离为零。

假设一笔订单要查商品、核对账户，再更新库存。若每条语句都要越过地域边界找远端主库，业务步骤越多，重复往返越明显。把执行放在本地，可以缩短这些往返；但本地完成计算，并不等于这次修改已经获得最终提交确认。应用要向用户承诺订单成立，仍须等提交结果。

这也解释了为什么SQL监控很好看，接口却未必同幅度变快。连接等待、应用计算、数据库执行、提交确认、失败后的重试，都可能落在用户等待的路径上。只看语句耗时，会漏掉后几段。

做一个明确的假设算例：同一次请求的串行路径里，其他开销10毫秒、本地执行10毫秒、提交阶段80毫秒，合计100毫秒。如果只把本地执行压到2毫秒，另外两段保持不变，总耗时是92毫秒。执行耗时减少了80%，整次请求耗时只减少了8%。这些数不是DSQL实测，也不是某一地域组合的延迟承诺。

这个算例只能对同一次请求、互不重叠的阶段相加。不能把几个监控面板上的P99直接加成接口P99：各阶段最慢的请求未必是同一批。实际评估要用请求链路把时间对应起来，再按完整请求统计分位数。

图1｜假设单次请求其他开销10毫秒、提交80毫秒不变，本地执行从10降至2毫秒，总耗时由100降至92毫秒。条形共用零起点刻度；不是实测，也不是P99相加。

因此，“多地域双活”首先改变的是哪些地方能接收读写、哪些阶段需要协调。它不自动回答某笔交易能否达到响应目标。对长距离部署，测量提交阶段尤其重要；对调用链很长的业务，减少数据库之外的串行调用也可能更有效。

更多入口，为什么没有更多库存可卖

如果不同用户修改不同订单，多个地域的执行能力可以分担负载。把所有用户都引到同一件热门商品的最后一份库存上，局面就不同了：可写入口增加，互相冲突的业务对象仍是同一个。

DSQL采用乐观并发控制，在提交时检查冲突。现行文档说明，并发修改同一行可能使其中一个事务失败，需要应用处理重试。没有持锁等待，不代表相互冲突的修改都能成功。

最后一份库存就是一个容易理解的假设场景。两个事务各自看到还有货，随后竞争修改同一库存行。一个先提交，另一个被拒绝；后者重新执行时，必须重新读取库存并重新判断能否下单。只重复提交旧的计算结果，丢掉了重试的业务意义。

图2｜两个入口面对同一件库存。场景比喻说明共享对象没有因入口增加而增多，不表示数据库以物理抢夺方式提交。

冲突密集时，失败前的查询和计算已经消耗资源；重做又产生新请求。无上限、无退避的立即重试，还可能让竞争更激烈。验收要同时看冲突率、每笔成功交易需要几次尝试，以及最终响应时间。单看收到多少写请求，容易把重复劳动当成吞吐提升。

随机化订单主键能分散订单写入，却不能消除库存行的竞争。把库存拆成多个额度分片也有代价：每片只能在获分额度内承诺，跨片调剂要另行协调，还可能出现总量有剩余、某片却暂时售罄。分散热点是否值得，取决于业务能否接受这种分配约束。

选型还差一个问题：哪些结果绝不能同时成立

除了同一行争用，还要检查跨行规则。DSQL文档将隔离级别描述为相当于PostgreSQL的Repeatable Read。快照隔离不能直接当成可串行化；数据副本一致，也不意味着任意业务约束自动成立。

例如，假设同一班次至少留一人值班，甲乙各占一行。两个并发事务都先查到两人在岗，再分别把自己那一行改成离岗。如果实现只依赖普通快照读取，各写各的行，这类写偏差就是需要专门验证的风险。两次更新分别看似合理，合起来却可能留下空班。

可以考虑让同一班次的退出操作竞争一条共同的约束记录，并在同一事务中检查和更新相关状态。这样更容易把规则落实到冲突检测上，但班次记录也成为新的争用点。另一个候选手段是显式声明所读行参与冲突检查；DSQL的SELECT FOR UPDATE采用提交时的乐观检查，不能照搬传统数据库“读到就一直持锁”的理解。具体方案还须覆盖新增人员、批量操作等全部修改路径。

这时，选型结论才比较清楚。大量地域内读取、写入对象分散、应用能正确处理事务重试的业务，更有条件获得就近执行的收益。集中扣减同一余额或库存的业务，先解决热点及约束表达，增设地域本身不会解除竞争。只服务一个地域、响应预算又很紧的业务，也没有必要仅为“两个地方都能写”增加协调距离。

最终试验应保留真实键分布，而非全用随机键压测；既测正常提交，也测冲突、提交回执丢失和地域不可达。回执丢失时先核对业务结果，不能把未知结果一律当成未提交。数据库之外的流量切换、连接和依赖服务也要一起走通。能够在这些条件下满足业务规则与响应目标，双活才算兑现了价值。