直接回答：最终一致性的实现模式按场景分：读修复与反熵（副本间定期比对同步，Cassandra 的 read repair/anti-entropy）；最后写入胜出（LWW，靠时间戳裁决，简单但时钟漂移会丢数据）；版本向量（vector clock 检测并发冲突，冲突交应用层解决，Dynamo 系）；CRDT（冲突无关复制数据类型，从数据结构层面保证并发修改天然可合并，无需裁决）；操作日志（op-based，如 CRDT 的另一种形态，要求操作可交换）。
展开解析：CRDT 深入一层：分状态型（CvRDT，传全量状态，合并取 join，要求合并满足交换/结合/幂等）与操作型（CmRDT，传操作，要求操作可交换，通信可靠前提下状态必然收敛）。典型结构：G-Counter（只增计数）、PN-Counter（增减各一个）、OR-Set（可加可删的集合）、LWW-Register。落地场景：协同编辑（Yjs/Automerge 的文本 CRDT）、分布式计数与购物车、多地域 session 状态同步。版本向量更适合“冲突稀有但需要人/应用裁决”的场景（文件同步、离线优先 App）。工程现实：CRDT 的元数据开销（墓碑、向量）随操作增长，需要压实与垃圾回收；多数业务用不上完整 CRDT，“操作幂等 + 时间戳排序 + 对账补偿”三板斧已能解决 90% 的最终一致问题。选型先看业务能否定义明确的合并语义——能定义才有自动化合并，定义不了就该质疑多主写入本身是否合理。
追问方向：墓碑（tombstone）为什么必须保留一段时间？LWW 丢数据的场景举一个？
（约 490 字）