如何降低Cassandra等非规范化数据库多表间的数据不一致性

针对多张表之间共享的非规范化数据，完全可以通过合理设计实现最终一致性，常见的落地方案如下： #

你当前给出的串行双写的写法确实存在中途节点宕机、单条更新失败导致的半写问题，可通过以下方案规避：

• 优先使用Cassandra原生的Logged Batch封装多表更新：Logged Batch会先把整个批次的写入请求持久化到集群的分布式批次日志中，只要批次被集群确认接收，就算执行批次的节点中途宕机，集群也会自动重放批次内的所有更新语句，保证两个表的更新要么全部生效，要么全部不生效，从根源上避免半写导致的不一致。注意单批次涉及的分区数不宜过多，避免批次过大影响写入性能。
• 事件驱动+异步消费架构：先将酒店信息更新请求作为不可变事件写入专用的事件表（以hotel_id和事件时间戳为主键），再通过独立的消费服务消费事件，分别更新两个目标表。消费服务需要做幂等处理，同时定期回扫未处理的事件，就算中途服务宕机，重启后可以从上次消费的位点继续执行，保证所有更新都落地到两张表。
• 定期对账+兜底修复：不管用上述哪种方案，都可以配套定时对账任务，定期比对hotels表和hotels_by_poi表中同一hotel_id的字段值，一旦发现不一致就以hotels表的最新数据为准覆盖修复，作为极端场景下的兜底机制。

这类数据一致性问题在生产中必须重点关注，不能单纯依赖服务可用性指标兜底： #

• 服务可用性5个9仅代表服务全年不可用时间不超过5分钟，但数据不一致的风险和服务可用性没有直接关联：哪怕服务全程可用，每次写入都有概率因为网络抖动、进程OOM、磁盘异常等问题出现半写，写入量越大，出现不一致的数据量就越多。如果每天有10万次更新请求，哪怕每10万次写入才出现一次异常，每天都会产生1条不一致数据，积累下来会严重影响业务体验，比如用户查询POI下的酒店拿到的是旧联系方式，直接导致用户投诉、业务资损。
• 4个9的数据完整性（即万分之一的错误率）在绝大多数业务场景都不满足要求：比如电商、出行、本地生活类业务，每一万条酒店数据就有一条信息错误，意味着每天可能有上百个用户遇到错误信息，业务侧完全无法接受；如果是金融、政务等强监管场景，对数据准确性的要求更高，甚至要求核心业务数据错误率为0。

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