最终一致性

为什么放弃强一致性

强一致性（线性一致性）要求所有节点对每个读写立即达成共识，这在网络分区下是不可能的——CAP 定理已证明这一点。要让全球多数据中心在每次写入时同步确认，光网络延迟就会让用户等几百毫秒。Amazon 购物车服务选择最终一致性：加购操作先在本地副本写入，异步复制到其他副本，偶尔两副本看到不同版本的购物车，系统用合并策略（取并集）解决冲突，丢几分钟的一致性比让用户无法加车要好得多。[1]

工程实践的挑战

最难处理的场景是读-写间隙：用户刚更新昵称，刷新却看到旧值。常见解法是读自己的写（Read-Your-Own-Writes）：写入后同一用户的读请求路由到主节点，或带版本号 Token 让从节点等同步完成再返回。Cassandra 提供多种一致性级别（ONE、QUORUM、ALL），允许在单次请求粒度上选择一致性强度，是最终一致性工程实践的典型教材。