需要线性一致性的三类典型场景

判断一个系统到底要不要为线性一致性付出代价，可以对照三类典型需求：一是加锁与领导者选举——单主复制的数据库必须确保所有节点对”谁是主库”这件事达成一致，否则容易脑裂，用ZooKeeper/etcd这类工具实现分布式锁和领导者选举时，锁服务必须线性一致，否则两个客户端可能同时以为自己拿到了锁；二是唯一性约束——要求用户名、文件名、订单号等在系统中全局唯一时，本质是在做一次线性一致的”检查后设置”操作，多个并发请求争抢同一个键必须有明确的先后判定；三是跨通道的时序依赖——当同一份数据通过两条不同的路径传播时（例如图片先被写入存储再触发异步压缩任务），如果两条路径读到的新鲜度不一致，会出现”看到压缩结果却看不到原图”这类竞态错误，只有在读路径上保证线性一致才能避免。发散：这三类场景的共性是”存在竞争，且错误的判定结果会造成不可逆后果”，不满足这个前提的普通业务读写通常不必付出线性一致性的代价。