Redis事务和一致性保障

1/1Redis事务和一致性保障第一部分事务在Redis中的语义 2第二部分Redis事务的实现机制 3第三部分Redis事务的原子性保证 5第四部分Redis事务的隔离性级别 7第五部分Redis事务的多键一致性 9第六部分Redis事务的持久化策略 12第七部分Redis事务的性能影响 16第八部分Redis事务在数据一致性中的应用 18

第一部分事务在Redis中的语义事务在Redis中的语义

定义

Redis事务是一组按顺序执行的命令，要么全部成功执行，要么全部失败，保证原子性和一致性。

原子性

原子性保证事务中的所有命令要么全部成功执行，要么全部失败回滚，不会出现部分成功的情况。

一致性

一致性保证事务执行前后的数据库状态始终满足业务逻辑的约束条件，不会出现不一致的情况。

隔离性

Redis中的事务不提供隔离性，这意味着并发事务可能观察到中间状态或脏数据。这可以通过使用WATCH命令来实现乐观的并发控制。

持久性

Redis事务在默认情况下并不持久，这意味着如果在事务执行过程中发生故障，事务中的数据将丢失。要确保持久性，需要使用MULTI和EXEC命令将事务包装在MULTI-EXEC块中，并在事务执行前对数据进行持久化操作（例如，使用SAVE或BGSAVE命令）。

语义

Redis事务具有以下语义：

*顺序执行：事务中的命令按顺序执行，后面的命令依赖于前面的命令。

*原子性：要么所有命令都成功执行，要么所有命令都失败回滚。

*一致性：事务执行前后，数据库状态满足业务逻辑的约束条件。

*隔离性：事务不提供隔离性，并发事务可能观察到中间状态或脏数据。

*持久性：默认情况下不持久，可以通过使用MULTI-EXEC块和持久化操作来确保持久性。

局限性

Redis事务也存在一些局限性：

*并发限制：隔离性不足，并发事务可能导致数据不一致。

*命令限制：不能包含某些命令，例如事务控制命令（MULTI、EXEC、DISCARD、WATCH）和慢速命令（例如，SCAN、SORT）。

*死锁：如果两个事务同时对同一个键进行加锁，可能会导致死锁。

总结

Redis事务提供原子性和一致性保证，确保事务中的命令要么全部成功执行，要么全部失败，并满足业务逻辑的约束条件。需要注意的是，Redis事务不提供隔离性，需要通过其他机制（例如乐观并发控制）来保证并发事务的正确性。第二部分Redis事务的实现机制关键词关键要点【ウォッチリスト】

1.事务开始时，Redis创建包含事务所有修改命令的队列。

2.事务执行时，Redis将队列中的命令顺序应用到数据库，直到所有命令都成功执行或遇到错误。

3.Redis使用乐观并发控制，这意味着在事务执行期间，其他客户端可以并发访问数据库。

【事务的原子性】

Redis事务的实现机制

Redis事务通过乐观锁机制实现，该机制利用以下关键组件：

事务日志(transactionlog)：一个有序列表，用于记录事务中的命令。

键空间锁(keyspacelock)：一种轻量级的锁机制，用于保护事务中涉及的键。

事务ID(transactionID)：一个唯一标识符，用于跟踪每个事务。

事务实现步骤：

1.开始事务：客户端发送`MULTI`命令开始事务。服务器响应一个事务ID。

2.记录命令：客户端发送要执行的命令，这些命令被记录在事务日志中。

3.应用事务：客户端发送`EXEC`命令提交事务。服务器验证事务ID，并获得键空间锁以防止外部修改。

4.执行命令：如果验证通过，则按照事务日志中的顺序执行命令。

5.释放锁：完成命令执行后，释放所有键空间锁。

6.提交或回滚事务：如果任何命令执行失败，整个事务将回滚。否则，事务将提交。

乐观锁机制：

Redis事务使用乐观锁，即假设事务执行期间不会发生冲突。这种方法的优点是提高了并发性，因为事务只有在提交时才会检查冲突。

冲突检测：

在执行事务时，服务器会对事务日志中的每个命令进行冲突检测。如果检测到冲突，事务将回滚。以下情况会导致冲突：

*另一个客户端修改了事务涉及的键。

*事务执行期间服务器重启或故障。

事务隔离级别：

Redis提供了以下事务隔离级别：

*可重复读(REPEATABLEREAD)：保证事务期间不会看到其他事务对相同键做的修改。

*读取已提交(READCOMMITTED)：保证事务仅看到已提交的其他事务对相同键做的修改。

WAL和AOF持久化：

事务日志可以写入写前日志(WAL)或追加只写文件(AOF)用于持久化。WAL用于快速故障恢复，而AOF用于提高数据完整性。

事务超时：

事务可以通过`MULTI`和`EXEC`命令之间的超时机制来限制其持续时间。超时后，事务将自动回滚。第三部分Redis事务的原子性保证关键词关键要点【事务的原子性】

1.Redis事务执行时，所有命令作为一个整体被执行，要么全部执行成功，要么全部失败。

2.Redis事务的原子性是通过CAS（Compare-And-Swap）操作实现的，保证在并发情况下命令的执行顺序。

3.Redis事务中，watch命令可以监视多个键，如果在事务提交之前监视的键被修改，事务将失败。

【事务的隔离性】

Redis事务的原子性保证

原子性是事务的四大基本特性之一，它确保事务中的所有操作要么全部成功执行，要么全部失败回滚，不会出现部分成功的情况。Redis的事务机制通过在多个命令执行期间将命令打包在一起并将其视为一个不可分割的单元来保证原子性。

Redis的事务使用乐观并发控制机制，其中事务的执行过程如下：

1.开始事务：使用`MULTI`命令开始一个事务，它将后续命令打包成一个队列。

2.执行命令：使用常规Redis命令执行事务中的操作。这些命令被添加到事务队列中，但不会立即执行。

3.提交事务：使用`EXEC`命令提交事务。如果事务队列中的所有命令都成功执行，则事务被提交，所有更改都永久保存到数据库中。

4.回滚事务：如果事务队列中的任何命令失败，则事务被回滚，所有对数据库的更改都将被撤销。

Redis通过使用单线程执行机制来保证原子性。在事务执行期间，Redis服务器会顺序执行事务队列中的所有命令，而不会被其他客户端或请求中断。这意味着事务中的所有命令要么全部成功执行，要么全部失败回滚，不会出现部分成功的情况。

此外，Redis还提供了`WATCH`命令，它允许客户端监视一个或多个键。如果在事务执行期间被监视的键被其他客户端修改，则事务将失败并被回滚。这有助于防止并发冲突和数据不一致。

值得注意的是，Redis的事务仅在单个Redis实例内提供原子性保证。如果涉及多个Redis实例，则需要使用分布式事务机制，例如XA分布式事务或分布式协调服务，来保证跨实例的原子性。第四部分Redis事务的隔离性级别Redis事务的隔离性级别

隔离性是数据库事务的重要特性，它确保不同事务并发执行时，不会互相干扰，从而保证数据的一致性。Redis中实现了不同级别的隔离性，以满足不同的业务场景需求。

读未提交（READUNCOMMITTED）

在这种隔离级别下，事务可以读取未提交的数据，即其他事务正在执行，但尚未提交的修改。这意味着，一个事务可能读取到另一个事务未完成操作的中间结果，从而导致数据不一致。

读提交（READCOMMITTED）

在此隔离级别下，事务只能读取已提交的数据，即其他事务已成功提交的修改。这可以防止读未提交问题，但仍然可能出现幻读问题，即一个事务可能多次读取同一组数据，却在每次读取时获得不同的结果。

可重复读（REPEATABLEREAD）

这种隔离级别解决了幻读问题。在可重复读隔离级别下，一个事务在执行过程中，始终读取同一时刻的数据快照，不会受到其他并发事务的影响。

串行化（SERIALIZABLE）

串行化隔离级别是隔离性最强的级别。在此级别下，事务按照串行顺序执行，即一个事务必须完全执行完毕，另一个事务才能开始执行。这消除了所有可能的隔离性问题，但也会极大地降低并发性能。

选择隔离性级别的注意事项

选择合适的隔离性级别需要考虑以下因素：

*数据一致性要求：对数据一致性的要求越高，就需要选择更高的隔离性级别。

*并发性要求：更高的隔离性级别会降低并发性，因此需要在一致性和并发性之间进行权衡。

*数据访问模式：如果事务主要进行读取操作，则可选择较低的隔离性级别；如果事务涉及大量更新操作，则需要选择更高的隔离性级别。

Redis中的隔离性实现

Redis使用乐观并发控制机制来实现事务隔离性。在事务执行期间，Redis不会锁住涉及的数据，而是使用版本号来跟踪数据的修改。当事务提交时，Redis会检查事务修改的数据的版本号，如果版本号与事务执行时一致，则提交事务；否则，回滚事务并报告冲突。

具体实现细节

*读未提交：不使用版本号，直接读取数据。

*读提交：使用版本号，但仅在事务提交时检查。

*可重复读：在事务开始时获取数据快照，使用版本号检查所有读取的数据。

*串行化：使用分布式锁，强制事务串行执行。

其他注意事项

*Redis事务的隔离性仅限于单个Redis实例，跨实例的事务无法保证隔离性。

*Redis事务的隔离性并不是绝对的，在某些情况下，仍然可能出现隔离性问题，如网络分区或硬件故障。

*Redis提供了`WATCH`命令，允许事务在提交前监控某些键，如果键被其他事务修改，则终止事务。第五部分Redis事务的多键一致性关键词关键要点事务中的多键操作原子性

1.事务中的所有命令序列要么全部执行成功，要么全部回滚，确保多键操作的原子性。

2.Redis使用乐观锁机制来处理并发更新，防止脏写（即同一时刻多个事务修改同一数据）。

事务中的隔离性

1.Redis事务提供隔离性保证，防止脏读（即读取其他正在进行事务的修改结果）。

2.事务中的数据修改只对该事务可见，直到事务提交后才会对其他事务可见。

事务中的顺序性

1.Redis事务中的命令序列以严格的顺序执行，确保多键操作的先后顺序不被其他操作干扰。

2.事务中命令执行的顺序与客户端发送命令的顺序一致，保证操作的预期效果。

事务中的持久性

1.Redis事务可以通过持久化机制（例如AOF或RDB）将数据修改持久化，即使服务器发生故障，也能保证事务的执行结果。

2.一旦事务提交，数据修改就会持久化存储，不会丢失。

事务中WATCH命令

1.WATCH命令用于监视一个或多个键，检查这些键在事务执行前是否被其他客户端修改。

2.如果监视的键在事务执行前被修改，事务将被放弃，防止基于过时数据的操作。

事务的性能优化

1.尽量减少事务中命令的数量，因为命令数量越多，事务执行的开销越大。

2.避免在事务中执行耗时的操作，例如排序或聚合，以免影响事务整体性能。Redis事务的多键一致性

Redis的事务机制提供了对多个键操作的一致性保证。在事务执行期间，涉及的键被锁定，以防止其他客户端修改这些键，从而确保事务的原子性。

多键一致性保障机制

Redis通过以下机制实现多键一致性：

*WATCH命令：在事务开始前，使用WATCH命令监视需要操作的键。如果在事务执行期间这些键被修改，事务将被中止，并返回一个错误。

*MULTI命令：开启事务。之后，可以使用任何Redis命令对事务内的键进行操作。

*EXEC命令：提交事务。如果事务中的所有命令都执行成功，并且监视的键没有被修改，事务将被提交，所有操作都会被持久化到数据库中。

如果事务中的任何命令执行失败，或者监视的键被修改，事务将被中止，并返回一个错误。

多键一致性示例

考虑以下示例，其中一个事务同时对两个键进行操作：

```

#开启事务

MULTI

#对键key1进行操作

INCRkey1

#对键key2进行操作

DECRkey2

#提交事务

EXEC

```

在事务执行期间，键key1和key2被锁定。如果在事务执行期间另一个客户端尝试修改key1或key2，该操作将被阻止，直到事务提交或中止。

如果事务成功提交，key1和key2将被更新，并且更新将被持久化到数据库中。如果事务因任何原因被中止，对key1和key2的修改将被丢弃，并返回一个错误。

实现多键一致性的好处

Redis的多键一致性机制提供了以下好处：

*原子性：确保事务中的所有操作要么全部执行成功，要么全部失败。

*一致性：确保事务中的所有操作在所有副本上都以相同的方式执行。

*隔离性：确保事务中的操作与其他客户端的操作隔离。

*持久性：一旦事务成功提交，对数据库中的数据的修改将是永久性的。

限制

值得注意的是，Redis的多键一致性机制有一些限制：

*乐观并发控制：它依赖于WATCH命令来检测键的修改，这可能导致在高并发场景下出现竞争条件。

*不适用于分布式环境：它只能在单个Redis实例内提供多键一致性。

*性能开销：使用WATCH命令和MULTI/EXEC命令会带来额外的性能开销，尤其是在对大量键进行操作时。

替代方案

对于需要更强的多键一致性保障的应用程序，可以考虑以下替代方案：

*使用Lua脚本：它允许在原子操作中更新多个键。

*使用分布式数据库：它提供跨多个服务器的强一致性保障。

*使用分布式事务协调器：它管理跨多个服务的分布式事务。第六部分Redis事务的持久化策略关键词关键要点AOF持久化

1.AOF（Append-OnlyFile）持久化将所有写入命令追加到一个文件，保证数据持久性。

2.AOF通过fsync操作将数据同步到磁盘，支持三个fsync策略：每秒fsync、每次写fsync、禁用fsync。

3.AOF重写功能可以定期将文件压缩，减少文件大小，提高性能。

RDB持久化

1.RDB（RedisDataBase）持久化将整个数据库状态保存在一个二进制文件中。

2.RDB通过bgsave或save命令触发持久化，bgsave在后台进行，不阻塞主线程。

3.RDB适用于需要快速恢复大数据集的情景，但持久化过程会阻塞写操作。

混合持久化

1.混合持久化同时使用AOF和RDB，提供持久性和快速恢复的平衡。

2.初始数据保存在RDB中，后续写入操作通过AOF记录。

3.当AOF文件达到一定大小或时间间隔时，触发RDB持久化，创建新的RDB文件。

主从复制

1.主从复制将主服务器的数据同步到多个从服务器，保证数据一致性。

2.从服务器从主服务器接收复制流，将数据持久化到自己的AOF或RDB中。

3.主从复制支持异步复制和半同步复制两种模式，提供不同的写入延迟和一致性保证。

哨兵模式

1.哨兵模式是Redis的高可用解决方案，用于监控主从复制集群。

2.哨兵节点会选举主服务器，并监控主从服务器的健康状况。

3.当主服务器故障时，哨兵节点会触发主从切换，保证集群的可用性。

集群模式

1.Redis集群模式将数据分片到多个服务器，实现可扩展性和分片故障隔离。

2.集群模式使用哈希槽分配数据，每个槽对应一个主从节点。

3.集群模式支持跨节点数据迁移，可动态调整数据分布以适应业务需求。Redis事务的持久化策略

Redis事务的持久化策略旨在确保在事务执行期间对数据的持久化，并在事务失败时将数据恢复到事务开始之前的情况。Redis提供了两种主要的事务持久化机制：

#1.AOF（追加仅附加）

AOF是一种持久化策略，通过将所有写入操作记录到一个持久化文件（称为AOF文件）来实现。当事务开始时，Redis会将事务中的所有命令追加到AOF文件中。如果事务成功提交，则AOF文件将被刷新到磁盘，从而持久化事务中的更改。如果事务失败，则AOF文件中相应的事务命令将被丢弃。

AOF的优点：

*文件大小较小：仅记录写入操作，不记录读取操作，因此AOF文件通常比RDB文件小得多。

*持久性强：只要AOF文件被定期刷新到磁盘，数据就不会丢失。即使Redis服务器发生故障，AOF文件也可以用于重建数据。

*追加写入：AOF文件是追加写入的，这意味着追加新操作不会覆盖现有数据。

*易于恢复：AOF文件可以被直接读取，因此在恢复数据时无需解析复杂的二进制格式。

AOF的缺点：

*写入性能较低：AOF需要对每个写操作进行同步追加到文件，这可能会影响写入性能。

*恢复时间较长：恢复大容量数据时，需要重播AOF文件中的所有命令，这可能需要花费大量时间。

#2.RDB（Redis数据库）

RDB是一种持久化策略，通过定期生成一个二进制快照文件（称为RDB文件）来实现。RDB文件包含Redis数据库中某个时刻的完整数据集。当事务开始时，Redis不会对事务中的更改进行任何持久化。相反，它等待事务成功提交，然后将更新后的数据集转储到RDB文件中。

RDB的优点：

*写入性能高：RDB持久化是在后台进行的，并且通常使用二进制格式，因此它对写入性能影响较小。

*恢复时间较短：RDB文件包含数据库的完整数据集，因此恢复数据时只需要加载RDB文件即可。

RDB的缺点：

*文件大小较大：RDB文件包含数据库的完整数据集，因此它通常比AOF文件大得多。

*数据丢失风险：如果在RDB文件生成期间Redis服务器发生故障，则可能丢失最近写入的数据。

*恢复困难：RDB文件是二进制格式的，因此在恢复数据时需要解析复杂的格式。

#3.选择持久化策略

选择合适的持久化策略取决于特定的应用程序要求和权衡：

*对于需要高写入性能的应用程序，AOF通常是更好的选择。

*对于需要高持久性和快速恢复的应用程序，RDB通常是更好的选择。

此外，还可以同时启用AOF和RDB持久化，这提供了更高的数据保护级别，但也会影响写入性能和恢复时间。第七部分Redis事务的性能影响Redis事务的性能影响

Redis的事务机制通过保证原子性和隔离性来增强数据一致性，但同时也可能对性能产生影响。以下详细分析了Redis事务的性能开销：

1.预写日志（AOF）的性能开销

*事务日志记录：开启AOF后，所有事务执行期间的命令都会被记录到AOF文件，这会导致额外的日志写入开销。

*文件同步策略：AOF的同步策略（always、everysec和no）决定了日志记录和磁盘同步的频率，这会影响性能和数据丢失的风险。always同步会带来最小的数据丢失风险，但也会导致最大的性能开销。

2.内存开销

*事务队列：当一个事务开始时，Redis会创建一个事务队列来记录事务中的所有命令。事务队列的大小取决于事务中包含的命令数量，因此大事务会占用更多的内存。

*复制缓冲区：在主从复制模式下，事务命令会在主服务器上的复制缓冲区中进行复制，这会导致额外的内存开销。

3.执行时间开销

*原子性保证：Redis的事务机制通过将所有命令捆绑在一起来实现原子性，这意味着单个命令的执行时间会受到事务中其他命令的影响。事务中命令的数量越多，执行时间就越长。

*隔离性保证：Redis通过在事务执行期间锁定涉及的键来实现隔离性。这会导致其他客户对这些键的访问被阻塞，从而增加总体执行时间。

4.网络开销

*复制延迟：在主从复制模式下，事务命令需要从主服务器复制到从服务器，这会引入网络延迟。如果复制延迟过大，可能会导致事务执行超时或数据不一致。

*客户端等待：当事务执行时，客户端会等待事务完成并返回结果。这可能会导致客户端请求的延迟增加。

影响性能的因素

以下因素会影响Redis事务的性能开销：

*事务大小：事务中包含的命令数量越多，性能开销就越大。

*命令类型：某些命令（如SET、DEL）比其他命令（如INCR、LPUSH）需要更多的执行时间，因此它们对事务性能的影响更大。

*负载量：Redis服务器上的总负载量会影响事务的性能，因为服务器需要处理其他请求和任务。

*硬件配置：Redis服务器的硬件配置（CPU、内存、网络带宽）会影响事务的性能。

性能优化建议

为了优化Redis事务的性能，可以考虑以下建议：

*减少事务大小：尽量将事务分解为更小的事务，以减少性能开销。

*选择适当的命令：避免在事务中使用复杂或耗时的命令。

*避免事务嵌套：避免嵌套事务，因为嵌套事务会进一步增加性能开销。

*使用管道化：将多个事务命令管道化可以显著减少网络开销。

*调整AOF同步策略：根据数据丢失容忍度和性能要求调整AOF同步策略。

*优化硬件配置：确保Redis服务器拥有足够的CPU、内存和网络带宽来处理事务负载。第八部分Redis事务在数据一致性中的应用关键词关键要点【Redis事务和原子性】

1.Redis事务保证原子性，即事务中的所有操作要么全部成功，要么全部失败。

2.当出现网络故障或服务器宕机时，Redis会回滚事务中的所有操作，确保数据一致性。

3.Redis的事务机制基于乐观锁，减少了锁争用并提高了并发性。

【Redis事务和隔离性】

Redis事务在数据一致性中的应用

引言

数据一致性是数据库系统中至关重要的属性，它确保数据库中的数据始终处于一致的状态。Redis作为一种高性能的键值存储，提供了事务机制来保证数据一致性。

事务概念

事务是一组原子且隔离的操作，它保证要么所有操作都被成功执行，要么没有任何操作被执行。原子性意味着事务中的所有操作作为一个整体执行，要么全部成功，要么全部失败。隔离性意味着事务与其他并发事务隔离开来，不会受到其他事务的影响。

Redis事务

Redis的事务使用MULTI和EXEC命令来实现。MULTI命令将后续的一系列命令打包成一个事务，而EXEC命令执行事务中的所有命令。如果事务中的任何命令执行失败，则整个事务将回滚，并且不会对数据库进行任何更改。

数据一致性保证

Redis事务可以保证以下数据一致性属性：

*原子性：事务中的所有操作要么全部成功，要么全部失败。

*隔离性：事务与其他并发事务隔离开来，不受其他事务的影响。

*持久性：一旦事务成功执行，其更改将被持久化到磁盘。

应用场景

Redis事务在以下场景中可用于确保数据一致性：

*转账：在两个账户之间转账时，使用事务可以确保转账要么成功完成，要么没有发生。

*库存管理：在更新库存时，使用事务可以确保库存水平始终保持准确。

*数据清理：在执行复杂的数据清理操作时，使用事务可以确保数据以一致的方式删除。

限制

虽然Redis事务提供了数据一致性保证，但仍有一些限制需要考虑：

*性能开销：事务比单个命令执行开销更大，因为需要额外的处理和日志记录。

*死锁：在高并发场景中，事务可能会导致死锁，因为每个事务都持有对键的锁。

*并发限制：Redis服务器一次只能执行一个事务，这可能会限制并发性。

最佳实践

为了有效利用Redis事务，请遵循以下最佳实践：

*仅在需要绝对数据一致性时使用事务。

*缩小事务的范围以减少竞争和死锁的风险。

*使用管道来将多个小事务组合成一个大事务，以提高性能。

*仔细考虑事务隔离级别，以在一致性和并发性之间取得平衡。

结论

Redis事务是确保Redis数据库中数据一致性的强大工具。通过利用原子性、隔离性和持久性属性，可以执行复杂的数据操作，同时保证数据完整性和可靠性。然而，应谨慎使用事务，并在需要时使用，以避免性能开销和并发问题。关键词关键要点事务在Redis中的语义：

【原子性】

*事务中的所有操作要么全部执行，要么全部不执行。

*如果事务中某个操作失败，该事务中的所有其他操作都会被回滚。

【一致性】

*事务操作保持数据库的一致性，即数据库状态在事务前后保持不变。

*如果事务执行失败，数据库状态不会受到影响。

【隔离性】

*事务与其他并发事务隔离，互不影响。

*每个事务看到的是数据库的快照，其他事务的操作不会被看到。

【持久性】

*一旦事务成功提交，其更改将持久化到磁盘。

*即使发生故障，事务中的更改也不会丢失。

【顺序执行】

*事务中的操作按照指定的顺序执行。

*后续操作依赖于前序操作的结果，不能并行执行。

【批处理】

*事务允许将多个操作打包成一个批处理。

*批处理操作一次性执行，无需多次往返服务器。关键词关键要点主题名称：Redis事务隔离性级别介绍

关键要点：

1.Redis事务实现了读已提交隔离级别，这意味着事务只能看到在事务开始之前已提交的写操作。

2.当一个事务读取一个键时，它会创建一个快照副本，因此事务期间对该键所做的任何修改都不会影响快照中的数据。

3.事务提交后，快照中的修改才会被提交到主存储库中，并对其他事务可见。

主题名称：读取已提交（ReadCommitted）

关键要点：

1.事务只能看到在事务开始前已经提交的修改。

2.事务中的修改对其他事务不可见，直到事务提交。

3.脏读和写入偏差风险被消除，但幻读风险仍然存在。

主题名称：串行化（Serializable）

关键要点：

1.保证事务按顺序依次执行，避免并发冲突。

2.实现了隔离级别中的最高级别，消除了所有类型的并发异常。

3.性能开销相对较高，只在需要强一致性的情况下使用。

主题名称：重复读（RepeatableRead）

关键要点：

1.事务在执行期间可以读取相同键的多个版本。

2.防止脏读和写入偏差，但幻读仍然可能发生。