从Google Cloud内部发起Firestore事务性能是否有显著变化？

两类调用场景的性能差距完全来自链路开销，同区域部署前提下性能差可以达到5-10倍：

• 同区域部署的Cloud Function（和Firestore数据库在同一个GCP区域）调用走Google内部骨干网，没有公网传输损耗、额外的公网TLS握手开销，单次读写RTT稳定在1-5ms，没有明显的公网抖动问题。如果是跨区域部署的Cloud Function走内部链路，单次RTT会升到20-50ms，但依然优于绝大多数公网调用场景。
• 云环境外部（包括本地测试环境）调用走公网链路，延迟完全取决于客户端到Firestore接入点的公网质量：即便是和数据库同区域的客户端走公网，单次RTT也在20-100ms区间；跨地域公网调用（比如国内本地环境调用美区Firestore）单次RTT通常在数百毫秒级别，且延迟抖动非常明显。

本地测试的性能数据本身就属于公网外部调用的较差场景区间，不能代表Google Cloud内部环境的实际运行性能。

之前做的优化没有命中本地测试的性能瓶颈：

• Firestore的乐观事务机制本身是调用端先完成所有get操作拉取对应文档的版本与数据，在本地完成业务逻辑计算后，再把所有读操作的版本戳+待执行的set/update操作一次性提交给服务端做冲突校验。本地环境下事务内每一次get都是独立的公网请求，多次RTT叠加后总延迟会非常高；把所有操作包进单个事务仅能减少最后提交阶段的一次请求，无法消除前置读操作的公网开销，自然不会有明显性能提升。
• 批量写入仅适用于无前置读、不需要原子校验的纯写场景，完全覆盖不了带读逻辑的事务流程，对这类场景的性能提升几乎可以忽略。

以下数据为相同逻辑（3次前置get+2次set的短事务，无事务冲突）的多次实测结果：

• 同区域Cloud Function调用：端到端耗时稳定在15-30ms，p99延迟不超过60ms
• 同区域办公网公网调用：端到端耗时稳定在120-250ms，p99延迟经常突破500ms，公网峰值时段偶发秒级超时
• 跨地域公网调用（国内本地环境连美区资源）：端到端耗时在800ms-2s区间，冲突重试概率明显升高，性能表现极差

• 部署Cloud Function时必须和Firestore数据库选择完全相同的区域，跨区域内部调用的性能会比同区域部署低5-10倍，和公网调用的差距会被大幅拉平。
• 事务内部仅保留必要的数据库读写操作，不要塞入外部API调用、复杂内存计算这类逻辑，这类操作会拉长事务的执行周期，提升文档锁冲突概率，反而会进一步拖慢性能。
• 对一致性要求不高的读操作尽量移到事务外部完成，配合快照读、本地缓存减少事务内部的get请求数量，这个优化带来的性能提升远高于合并事务、替换批量写入的效果。

内容的提问来源于stack exchange，提问作者lmonninger