Python3 App Engine使用db/ndb时是否需考虑最终一致性？

• appengine-python-standard提供的db/ndb封装底层基于Firestore in Datastore mode，但会刻意模拟旧Python2 Datastore的行为，包括默认的最终一致性逻辑。
• Firestore in Datastore mode并非完全抛弃最终一致性，它保留了和旧Datastore一致的一致性规则，你仍需根据操作类型考虑一致性问题。

1. Firestore in Datastore mode的一致性规则 #

它并没有彻底改变旧Datastore的一致性模型，规则和之前基本一致：

• 单个实体的get/put/delete操作是强一致性的
• 跨实体的普通查询（非祖先查询）默认仍是最终一致性
• 祖先查询可以指定强一致性（和旧版Datastore逻辑对齐）

它的优势在于自动扩缩能力和更高的性能，但一致性逻辑是向下兼容的。

2. db/ndb封装的行为逻辑 #

这个库的设计目标就是让旧Python2代码尽可能无缝迁移到Python3，所以：

• 对外暴露的接口、行为完全对齐旧db/ndb，包括一致性表现——比如默认查询还是最终一致，事务处理逻辑也和以前一样
• 底层虽然调用Firestore的API，但不会主动启用Firestore的新特性（比如文档嵌套结构），除非你直接使用Firestore原生Python SDK

3. 分片流程的重写建议 #

要不要改分片，得看你当初做分片的核心原因：

• 如果是为了缓解高并发写入的冲突（比如计数器乐观锁失败）：分片依然有意义，因为单实体强一致但高并发写还是会有冲突，分片能分散写入压力
• 如果是为了规避旧Datastore查询的最终一致性问题：现在可以尝试用祖先查询的强一致性来替代，但要注意祖先查询的扩展性限制（同一祖先下的实体数量不能过多）
• 要是想彻底利用Firestore的全部能力，可以逐步把db/ndb替换成Firestore原生SDK，这样能直接使用实时更新、更灵活的查询等特性，但代码改动量会更大

4. 性能相关说明 #

你测试到响应时间良好是正常情况：appengine-python-standard的封装层开销极小，再加上Firestore in Datastore mode本身性能优于旧Datastore，所以不会给应用带来明显的性能损耗。

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