如何同步更新Cassandra非规范化表，跨表主键变更该如何处理？

针对反规范化设计下易变字段作为多张表主键的更新问题，常用可行方案如下：

• 主键查询+原子批处理方案
  该方案的实际开销远低于预期：Cassandra 基于主键的单条查询为O(1)耗时极短，你可以用全局唯一、不可变更的用户ID（如user_id）作为主表的主键，更新邮箱前仅需用user_id查询主表拿到旧邮箱值，再通过Logged Batch保证原子性执行三个操作：
  1. 更新主表的邮箱字段
  2. 删除user_by_email表旧邮箱对应的条目
  3. 插入user_by_email表新邮箱对应的条目
     Spring Data Cassandra 中可以直接使用CassandraBatchTemplate实现上述批量操作，对于用户属性更新这类低频操作，Logged Batch的性能开销完全可以接受。
• 软标记+异步清理方案
  适合对写延迟要求极高的场景：更新邮箱时仅插入user_by_email的新条目，同时给旧邮箱条目设置TTL或者在主表中记录旧邮箱的过期时间，后台定时任务异步清理过期的历史数据。查询user_by_email时增加过滤条件排除已过期/已标记删除的条目即可。
  该方案写路径性能最优，缺点是存在少量存储冗余，查询逻辑需要额外加过滤条件。
• 数据模型调整方案
  从根源避免问题：如果邮箱字段的变更频率很高，可以评估是否用二级索引替代独立的user_by_email表，直接在主表的邮箱字段上创建二级索引，更新邮箱时仅需更新主表即可，无需额外维护多表同步。
  注意该方案仅适合中小规模用户量场景，Cassandra 二级索引不适合超大规模、高基数字段的高性能查询场景。
• CDC异步同步方案
  开启Cassandra的CDC（变更数据捕获）功能，监听主表的字段更新事件，当捕获到邮箱字段变更时，由异步消费程序自动完成user_by_email表的旧数据删除和新数据插入。
  该方案业务侧代码无需处理同步逻辑，写性能最高，缺点是存在短暂的一致性延迟，仅适合接受最终一致性的业务场景。

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