MongoDB WiredTiger快照与数据锁的关联疑问

这个问题问到点子上了！我刚啃WiredTiger文档的时候也卡在这里好久——快照和锁看起来像重复保障，但其实他俩管的是完全不同的“地盘”，根本不冲突。 #

先给你拆解清楚：

1. 先纠正一个关键误解：默认情况下，你的快照读根本不会加共享锁！ #

WiredTiger的默认读操作就是无锁快照读——你执行普通的文档查询时，只会获取一个数据库级的时间点快照，全程不会给任何文档/集合加共享锁，更不会阻塞写入操作。你读到的是读时刻的一致数据，后续的写入哪怕改同一份文档，也和你的读操作完全无关，不会干扰你。

那你疑惑的“共享锁阻塞写入”场景，其实只发生在特殊操作里，不是普通快照读的常规行为。

2. 锁的作用：管的是「写操作的冲突」和「原子性需求」，和你的快照读没关系 #

快照解决的是读操作自身的一致性——让你不管并发写怎么闹，都能读到某个时间点的完整数据视图。但锁的核心职责是解决下面这些快照搞不定的问题：

• 写-写冲突的避免：比如两个用户同时修改同一份文档的同一个字段，如果没有文档级锁，就可能出现“写覆盖”——第一个写改了一半，第二个写就把它冲掉了，最后得到的是不完整的错误数据。WiredTiger的文档级排他锁，就是保证同一时刻只有一个写操作能修改某份文档，确保写操作的原子性和数据完整性。
• 读写混合操作的原子性：比如你用findAndModify先读文档再修改它，这个操作需要“读-写”的原子性——如果没有锁，在你读完之后、修改之前，另一个写操作改了这份文档，那findAndModify的逻辑就彻底乱了（比如你本来要给余额减100，结果刚读完余额是500，另一个操作先把余额改成了300，你再减100就变成200，这显然不符合业务逻辑）。这时候就需要锁来把“读-写”绑定成一个不可分割的原子操作，而快照读做不到这一点——快照只能保证读的时刻的一致性，没法关联后续的写动作。
• DDL等全局操作的一致性：比如你给集合加索引，这时候需要集合级的锁来防止加索引期间的写入破坏索引结构，这时候相关的写操作会被阻塞，但普通的快照读依然可以正常进行，不受影响。

3. 再回到你的疑问：既然读的是快照，为什么要在意锁？ #

答案是：你完全不需要在意！ 因为你的普通快照读根本不会触发锁，也不会被写操作干扰。锁是用来保护写操作之间的秩序，以及特殊原子操作的正确性，和你的常规读操作没有交集。你之前可能混淆了“锁的存在”和“读操作会触发锁”这两个概念——WiredTiger的锁机制主要服务于写侧，读侧默认是无锁快照，完全并行。

一句话总结 #

快照是给读操作开的“时光机”，保证你读到的是某个时刻的一致数据；锁是给写操作立的“规矩”，保证写操作之间不打架、原子操作不出错。二者是互补的机制，不是替代关系，一起撑起了WiredTiger的ACID保障。

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