BigTable checkAndMutate原子性与行为问询：是否会获取陈旧数据？流程是否合理？

一、先聊聊 checkAndMutate 的核心行为 #

checkAndMutate 是BigTable专为原子条件更新设计的API，整个执行流程是原子性的，不会被其他并发操作打断：

• 第一步：按照你指定的规则（比如某列是否存在、某列的值是否等于特定内容），检查目标行的当前状态。
• 第二步：如果检查条件满足，立刻执行预先定义的修改操作（比如更新列值、新增列、删除列等）；如果条件不满足，则跳过所有修改。
• 第三步：返回结果，告知你条件是否匹配、修改是否执行成功。

简单来说，这个API把「检查+修改」打包成了一个不可拆分的操作，从根源上避免了并发场景下的竞态问题。

二、调用前读行会不会拿到陈旧数据？ #

答案是肯定有可能，主要有两个原因：

1. BigTable默认读操作是最终一致性：你读到的数据可能是该行的历史版本，其他客户端的最新修改还未同步到你访问的节点，导致拿到过时数据。
2. 就算使用强一致性读（能获取当前最新数据），从完成读操作到调用checkAndMutate之间依然存在时间窗口——这个间隙里，其他客户端完全可能修改该行，让你手里的数据瞬间过期。

三、你的思路是否可行？ #

很遗憾，这个思路存在严重竞态条件，不可行。

举个具体场景就能明白：

1. 你通过行键读取某行，得到列score的值是90。
2. 你在应用端计算后要把它改成95，准备调用checkAndMutate，条件设为「score等于90时更新为95」。
3. 但就在你读完到调用API的间隙，另一个客户端已经把score改成了92。
4. 此时你的checkAndMutate会因条件不满足而失败，你基于旧数据的修改逻辑完全失效。

正确的做法是把所有逻辑交给checkAndMutate的原子操作：比如要基于当前值修改，直接在checkAndMutate里判断当前值是否符合预期，满足条件时再执行修改，全程让BigTable保证原子性，不要在应用端做中间的读和修改步骤。

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