Firebase实时数据库并发请求场景下的执行逻辑验证

这完全符合Firebase Realtime Database的运行逻辑，我来给你拆解下背后的原因：

• 多路径更新的原子性保障：你写的getItem函数执行的是原子性多路径更新——从items删除物品和添加到用户my_items这两个操作是绑定在一起的，要么全部成功，要么全部失败。当用户A的请求先到达服务器时，安全规则会基于更新执行前的数据库快照校验my_items的写入条件：此时目标物品还在items节点里，规则校验通过，整个更新顺利完成，物品成功从公共节点转移到A的私有节点。

• 并发请求的状态依赖：Firebase Database会确保每个原子更新都基于当前最新的数据库状态执行。A的更新完成后，items里的目标物品已经被移除了。当B、C、D的请求到达时，它们的my_items写入操作触发安全规则校验，此时查询items节点已经找不到对应物品，规则直接拦截，整个多路径更新失败，不会产生任何数据变更。

• 安全规则的实时校验逻辑：my_items的安全规则是在写操作执行前触发的，而且每个请求的校验都是独立的。后续请求无法绕过已经变更的数据库状态，自然也就通不过规则验证。

总结下来，就是第一个抢到“转移资格”的用户A能成功，剩下的用户因为物品已经不在公共节点，都会被安全规则挡下来，和你猜想的结果完全一致。

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