Cassandra是否支持类REPEATABLE READ语义？应用层实现方法问询

1. Cassandra 是否提供与 REPEATABLE READ 类似的语义？ #

Cassandra 原生不支持传统关系型数据库中的 REPEATABLE READ 隔离级别。它默认的隔离级别是读已提交（Read Committed），且基于最终一致性模型，没有原生的强一致性可重复读语义。

2. 批量 LWT 实现该语义的开销与阻塞问题？ #

用批量轻量级事务（LWT）确实能模拟近似 REPEATABLE READ 的效果，但PAXOS 共识协议带来的网络开销是客观存在的——LWT 需要节点间达成共识，相比普通写操作，延迟会明显升高。

关于阻塞：批量 LWT 不会完全阻塞所有并发的批量 LWT。只有当多个 LWT 操作的是相同分区键的数据时，才会触发互斥阻塞；如果操作的是不同分区，它们可以并行执行，互不干扰。这和 RDBMS 中 REPEATABLE READ 允许非冲突事务正常进展的逻辑一致，只是 Cassandra 的阻塞范围被限定在了分区级别。

3. 应用层实现 REPEATABLE READ 的常用技术（避免幻读、丢失更新） #

针对 Cassandra 的分布式特性，开发者通常在应用层采用以下方案：

• 乐观锁（版本控制）：给每行数据添加版本号字段，更新前先读取当前版本，更新时用 LWT 的 IF 子句校验版本号，版本不匹配则重试。这种方式能有效避免丢失更新，同时通过固定读取同一版本数据来模拟可重复读。
• 客户端快照：在事务启动时，一次性把需要操作的所有数据读到客户端内存，后续操作都基于这个快照执行，更新时再用 LWT 验证数据是否被修改。这种方式能避免幻读，但要注意控制数据量，防止客户端内存过载。
• 分区内原子性约束：把需要保持一致性的数据集中在同一个分区，利用 Cassandra 分区内的原子性和 LWT 的分区锁特性，确保同一分区内的操作满足近似可重复读的语义。但这种做法可能导致热点分区，需要权衡数据分布。
• 事件溯源：不直接修改数据，而是记录所有操作事件，通过重放事件生成当前状态。这种方式天然避免丢失更新，还能通过重放特定时间点的事件实现可重复读效果，适合修改频率低的场景。

内容的提问来源于stack exchange，提问作者D.B.K