当前位置：首页 > news >正文

Apache Ignite 中乐观事务（OPTIMISTIC Transactions）的工作机制

news 2025/7/23 7:19:43

这段内容讲解的是 Apache Ignite 中乐观事务（OPTIMISTIC Transactions）的工作机制，包括它在不同隔离级别下的行为、锁的获取时机、事务冲突检测机制，以及在使用乐观事务时需要注意的一些关键点。下面我将 用通俗易懂的中文 为你详细解释这段内容。

一、什么是乐观事务（OPTIMISTIC Transaction）

在 乐观事务模式 下，事务 不立即加锁，而是在事务提交时才进行冲突检测。如果检测到冲突（比如其他事务修改了相同的数据），事务就会失败。

锁的获取时机：

在 两阶段提交（2PC）的第一阶段（prepare 阶段） 才对数据加锁。
加锁顺序：
- 先在主节点（Primary Node）上加锁；
- 然后推广到备份节点（Backup Nodes）；
如果事务回滚且 从未尝试提交，则 不会加任何锁。

✅ 优点：性能好，适合并发冲突少的场景。
❌ 缺点：如果冲突多，可能会频繁失败，需要重试。

二、乐观事务下的隔离级别（Isolation Levels）

在 OPTIMISTIC 模式下，可以使用以下三种隔离级别：

1. READ_COMMITTED

事务中修改的数据会收集在发起事务的节点上；
提交时才会真正应用到缓存；
读操作 不加锁，也不会缓存数据；
数据可能从主节点或备份节点读取（取决于缓存配置）；
可能出现“不可重复读”（Non-Repeatable Read）：
- 即在同一个事务中多次读取某个 key，可能得到不同的值；
- 因为其他事务可能在你第一次读之后修改了数据；
不检查数据是否被修改过，也不会抛出乐观事务异常（TransactionOptimisticException）。

📌 举例：

事务 A 读了 key=“name”，得到 “Alice”；
事务 B 修改了 key=“name” 为 “Bob” 并提交；
事务 A 再次读 key=“name”，得到 “Bob”；
这在 READ_COMMITTED 下是允许的。

2. REPEATABLE_READ

和 READ_COMMITTED 类似，唯一的区别是：
- 读取的数据会被缓存在事务发起节点的本地事务映射中；
- 后续对该 key 的所有读取都使用本地缓存的值；
保证事务中多次读取同一个 key，结果一致；
不检查数据是否被修改过，也不会抛出乐观事务异常。

📌 举例：

事务 A 读了 key=“name”，得到 “Alice”；
本地缓存了这个值；
事务 B 修改了 key=“name” 为 “Bob”；
事务 A 再次读 key=“name”，仍然是 “Alice”。

3. SERIALIZABLE

是最严格的隔离级别；
在第一次读取某个 key 时，记录它的版本号；
在事务提交时，检查所有涉及的 key 是否被其他事务修改过；
- 如果发现某个 key 的版本号变了（即被其他事务修改），则事务失败；
- 抛出 TransactionOptimisticException，并回滚事务；
即使只是读了某个 key 而没有修改它，如果它的值被别人改了，事务也会失败；
- 因为这个 key 的值可能影响了你的事务逻辑；

📌 举例：

事务 A 读了 key=“balance”，值为 100；
事务 B 修改了 key=“balance” 为 200；
事务 A 提交时，检测到 balance 被改过，事务失败并抛出异常；
即使事务 A 没有修改 balance，只是读了它。

三、代码示例：使用乐观 + 可串行化事务

CacheConfiguration<Integer, String> cfg = new CacheConfiguration<>();
cfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
cfg.setName("myCache");
IgniteCache<Integer, String> cache = ignite.getOrCreateCache(cfg);int retryCount = 10;
int retries = 0;while (retries < retryCount) {retries++;try (Transaction tx = ignite.transactions().txStart(TransactionConcurrency.OPTIMISTIC,TransactionIsolation.SERIALIZABLE)) {// 修改缓存cache.put(1, "foo");cache.put(2, "bar");// 提交事务tx.commit();break; // 成功提交，跳出循环} catch (TransactionOptimisticException e) {// 事务冲突失败，重试}
}

说明：

使用 OPTIMISTIC + SERIALIZABLE 组合，可以保证数据一致性；
如果事务失败，会抛出 TransactionOptimisticException；
建议使用 重试机制，比如最多重试 10 次；
适用于并发冲突多、但又不想使用悲观事务的场景。

四、关于锁顺序的重要说明

虽然乐观事务不立即加锁，但在 READ_COMMITTED 和 REPEATABLE_READ 模式下，锁仍然是 按访问顺序逐个获取的。

⚠️ 如果多个事务以不同的顺序访问相同的 key，可能导致死锁。

建议：

统一访问 key 的顺序，避免死锁；
尽量减少事务中涉及的 key 数量；
对于高并发场景，优先考虑使用乐观事务 + SERIALIZABLE 隔离级别。

✅ 总结对比表

隔离级别	是否缓存读取数据	可重复读	是否检测冲突	是否抛出乐观异常	适用场景
READ_COMMITTED	❌ 不缓存	❌ 不可重复读	❌ 不检测冲突	❌ 不抛出异常	读多写少、一致性要求不高的场景
REPEATABLE_READ	✅ 缓存在本地	✅ 可重复读	❌ 不检测冲突	❌ 不抛出异常	一致性要求较高、写操作较少的场景
SERIALIZABLE	✅ 缓存在本地	✅ 可重复读	✅ 提交时检测冲突	✅ 抛出异常	高并发、强一致性要求的场景