直接回答：线性一致性：每个操作看起来在调用与返回之间的某个瞬间原子生效，且全局存在一个与实际时间顺序一致的操作序列——效果等同“只有一份数据、一次只服务一个请求”。它是最强的单对象一致性模型：写读有序（写完任何人立刻读到）、操作实时排序（A 先于 B 返回，则全局序中 A 在 B 前）。
展开解析：与相近概念的边界：顺序一致性（sequential consistency）要求存在全局序列但不要求与真实时钟对齐——CPU 内存模型常用；因果一致性更弱只保因果序。实现路径与代价：单主加同步复制——写经 leader，多数派确认后返回，读走 leader 或带 quorum——本质每次读写给共识交税，延迟增加一个 RTT 以上；读路径优化——leader 读（leader 任期确认自己仍合法，要心跳 quorum 确认）、lease 读（时钟假设）、follower read index（向 leader 确认 commit index 再本地读），每种都省一点但都绕不开某种形式的多数派确认；CAP 视角——线性一致写在分区时必须牺牲可用性（少数派拒绝服务）。常见误解澄清：同步复制不等于线性一致——双主同步复制在脑裂下照样分叉；串行化（serializability）是事务概念（多对象多操作），线性一致是单对象单操作，serializable + linearizable = strict serializable。工程决策：真正需要线性一致的场景比想象少——配置、选主、分布式锁、唯一约束；业务读大多数可接受读己之写（read-your-writes）或单调读，用会话级保证省掉全局税。etcd/ZooKeeper 的线性读与可串行化读分离设计就是这个权衡的样板。
追问方向：leader lease 读为什么有时钟假设风险？读己之写如何在多副本下实现？
（约 500 字）