从自建Cassandra迁移至Amazon Keyspaces后，Logged Batches替代方案咨询

针对跨表数据一致性场景，Amazon Keyspaces没有直接等效的Logged Batches特性，但可以通过以下几种方案实现类似的一致性保障：

1. 原子批量写入（Atomic Batches） #

Amazon Keyspaces支持同分区键的原子批量操作——如果你的多张表可以共享同一个分区键，将跨表写入操作放在同一个原子批量中，就能保证所有操作要么全部成功，要么全部失败，实现强一致性。

注意：原子批量仅支持同一分区键下的操作，这是由Keyspaces的分区存储模型决定的，同分区操作可在单个节点内原子执行。
比如你有用户基础信息表和用户订单统计表，两者分区键都是user_id，可将两个表的写入请求打包成一个原子批量：

BatchStatement batch = new BatchStatement(BatchType.UNLOGGED);
batch.add(new SimpleStatement("INSERT INTO user_info (user_id, name) VALUES (?, ?)", userId, userName));
batch.add(new SimpleStatement("INSERT INTO user_order_stats (user_id, order_count) VALUES (?, ?)", userId, orderCount));
session.execute(batch);

2. 客户端补偿事务 #

如果必须跨分区或不同分区键的表，可在客户端层面实现补偿逻辑，模拟事务一致性：

• 第一步：写入第一个表，并在专门的操作日志表中记录操作详情（比如操作ID、涉及表、数据内容、状态），操作ID建议用UUID保证唯一性。
• 第二步：写入第二个表，成功后更新操作日志表状态为SUCCESS。
• 异常处理：若某一步写入失败，根据操作日志记录回滚已成功的操作（比如删除已写入记录），并设置状态为FAILED；同时添加重试机制，处理网络抖动等临时故障。
• 关键要求：所有写入操作需设计为幂等性，比如写入前检查操作ID是否已存在，避免重试时重复写入导致数据不一致。

3. 状态表+TTL的异步一致性保障 #

对于非实时要求的场景，可用状态表跟踪操作进度，结合TTL自动清理无效记录：

• 创建operation_status表，主键为operation_id，字段包含status（IN_PROGRESS/SUCCESS/FAILED）、created_at、ttl。
• 发起跨表操作时，先插入IN_PROGRESS状态的记录，设置合适TTL（比如1小时）防止残留数据。
• 依次执行各表写入操作，全部完成后更新状态为SUCCESS。
• 部署定时任务扫描operation_status表，对超时的IN_PROGRESS记录触发重试或标记为FAILED并执行回滚。

4. 重新设计数据模型（最优解） #

如果业务允许，优先调整数据模型，避免跨表同步需求：

• 采用宽表设计：将分散在多张表的关联数据合并到一张表，用复合主键覆盖不同查询场景。比如原来的用户信息表和用户偏好表，可合并为一张表，用(user_id, data_type)作为复合主键，同时存储基础信息和偏好数据，一次写入即可保证一致性。
• 利用静态列：若部分数据在同分区内共享，可用静态列存储，避免重复写入和同步问题。

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