Firestore Datastore模式下事务中数组更新被覆盖问题排查

核心原因 #

你遇到的并发覆盖问题，本质是事务内未正确使用悲观锁，加上可能的客户端缓存干扰，导致并发事务都读取到了实体的初始状态：

1. 未显式获取悲观排他锁：
   尽管你启用了Datastore的悲观并发控制，但代码中client.get(key)默认是乐观读取——不会主动获取排他锁。这意味着两个并发事务可以同时读取到数组长度为0的实体快照，各自修改为长度1后提交，后提交的事务会直接覆盖前一个的结果。

2. 客户端缓存可能干扰读取：
   Datastore Python客户端默认可能启用内存缓存，如果事务内的get操作命中了缓存中的旧数据，会绕过数据库的锁机制，导致读取到过时的实体状态。

修复步骤 #

1. 在事务内读取实体时显式加悲观锁

修改事务内获取实体的代码，添加lock=True参数，明确请求排他锁。这样第一个事务读取实体后会锁定它，其他并发事务必须等待当前事务提交/回滚才能读取，从根源避免并发读取旧值：

# 替换原来的client.get(key)
entity = client.get(key, lock=True)

2. 强制事务内读取使用强一致性（可选但推荐）

为了彻底避免缓存干扰，在get操作中指定强一致性读取，确保直接从数据库获取最新的加锁状态：

from google.cloud import datastore

entity = client.get(key, lock=True, read_consistency=datastore.ReadConsistency.STRONG)

3. 验证事务锁的生效

修改后，并发事务会串行处理：第一个事务锁定实体并修改数组，第二个事务等待锁释放后读取到更新后的数组（长度1），append后变成2，最终数组长度符合预期。

额外注意点 #

• allocate_ids在事务外执行是安全的：预分配键的操作是幂等且独立于事务的，不会影响事务的一致性。
• 如果后续仍遇到问题，可以捕获事务提交的冲突异常并重试（针对乐观锁场景的 fallback 方案），但使用悲观锁后一般不需要。

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