Hazelcast中CPMap与TransactionalMap的适用场景及一致性疑问

适用场景区分 #

• CPMap：用于要求全局强一致性、线性化语义的场景，比如分布式锁、全局配置中心、分布式ID生成器、关键业务状态存储等。这类场景下，所有节点必须实时看到完全一致的数据状态，任何操作的结果都要经过集群共识后才生效。
• TransactionalMap：用于需要单业务流程内多操作原子性，但不要求全局强一致的场景，比如用户下单时同时扣减库存+增加积分、批量更新同用户的多个关联数据等。它只保证一组操作要么全部提交成功，要么全部回滚，不追求所有节点实时同步状态。

为什么TransactionalMap的ACID无法满足强一致性？ #

TransactionalMap的ACID特性是事务内部的原子性、一致性、隔离性、持久性，但它的设计目标不是全局强一致，核心原因如下：

• 事务无全局共识机制：TransactionalMap的事务基于本地节点的副本操作，跨节点事务依赖的是两阶段提交（2PC）或单阶段提交（1PC），但没有经过Raft这类共识协议的全局确认。也就是说，事务提交时只保证本地主副本的修改成功，其他副本的同步是异步进行的，这就导致其他节点可能在事务提交后仍读到旧数据。
• 副本异步同步：底层基于Hazelcast的AP数据结构，副本之间采用异步复制策略。即使事务提交成功，修改只会先写入主节点，再慢慢同步到从节点，这段时间内不同节点看到的数据状态是不一致的，不符合强一致性“任何时刻所有节点状态统一”的要求。
• 隔离级别与全局顺序缺失：TransactionalMap默认隔离级别是READ_COMMITTED，只能保证事务内不会读到未提交的脏数据，但无法保证全局操作的线性化顺序。比如两个并发事务修改同一个key，不同节点可能看到的操作顺序不同，最终导致状态分歧——这在CPMap中不会出现，因为Raft协议会保证所有操作按全局唯一顺序执行。

举个直观例子：
节点A上的事务T1将key balance从100改为50，提交成功；同一时间节点B上的事务T2读取balance，此时因为异步同步未完成，节点B读到的还是100。这就是典型的强一致性缺失，而CPMap会在T1提交前确保大多数副本都同步到50，T2无论在哪个节点都会读到最新值。

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