Firestore高并发场景事务数据争用相关问题咨询

1. 两类报错的事务终止判定 #

两类报错触发时，当前事务都会被终止，你的原有认知存在偏差。
Firestore采用乐观锁实现事务，所有以10 ABORTED开头的错误，无论后缀描述如何，都代表当前事务已被服务端终止，不会执行事务内的写入操作，也不会再自动重试，因此都会触发代码中的catch块。
你看到的官方文档相关描述大概率混淆了自动重试规则：第一类Too much contention报错是重试耗尽后的最终报错，Firestore客户端SDK默认会对可重试的事务冲突做最多5次自动重试，多次重试都失败才会抛出该错误；第二类cross-transaction contention是单次事务执行时的实时冲突报错，如果还没达到重试次数上限，SDK会先尝试自动重试，重试失败后才会抛到上层触发catch，两类报错最终出现时，对应的事务实例都已经完全终止。

2. 无写入的并行请求对争用的影响 #

无写入的事务也会加剧数据争用，会被计入争用统计。
Firestore为了保证事务的串行一致性，所有事务（无论最终是否执行写入）在调用t.get()读取文档时，都会记录该文档的当前版本号，事务提交前会校验所有读取过的文档版本是否发生变化，只要有变化就会判定为冲突。
哪怕事务B全程没有写入操作，只要它读取了正在被其他事务修改的文档，就会参与版本校验的竞争：既可能因为其他事务修改了文档版本导致自身冲突终止，也会提升其他事务做版本校验时的冲突概率。

3. 两类报错对数据更新的影响差异 #

二者对数据的最终影响没有任何区别：报错触发时，事务内的所有写入操作都不会生效，数据会保持事务执行前的状态。
二者唯一的区别是触发场景：

• Too much contention属于累积过载类报错：代表当前该文档的并发请求量已经超过Firestore单文档的处理上限（官方参考阈值为每秒1次稳定写入，峰值最多承受每秒10次左右的并发写入），一般出现在持续高并发的场景下
• cross-transaction contention属于单次互斥冲突报错：代表至少有两个并行的事务/普通写入操作同时操作同一个文档，刚好触发了乐观锁的版本校验失败，偶发该报错属于正常的事务冲突逻辑，只有高频出现时才代表并发量超出承载上限

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