分布式是大型架构核心，下面我详解一致性@mikechen
核心设计区别
强一致：任何读取操作都能立即看到最近一次成功写入的结果。
最终一致：写入在短期内可能只作用于部分副本，读操作可能读取到旧值或不同副本的不一致状态。
但在没有新的更新时，系统会逐步收敛到一致状态，最终所有副本一致。
延迟设计区别
强一致：通常需要同步协调（如两阶段提交、分布式锁或多数派确认）。
因此延迟较高，且在网络分区或部分节点不可用时可能降低可用性以保证一致性。
最终一致：允许异步复制与弱协调，读写延迟较低。
系统在分区或节点失败时仍能提供较高可用性，适合对延迟敏感的场景。
数据设计区别
强一致：冲突通过中心化/或同步机制在写入时解决。
应用层通常无需显式处理冲突，逻辑较为简洁。
最终一致：由于并发写入可能在不同副本上产生冲突。
须采用冲突解决策略（如最后写胜出、版本向量、应用级合并或CRDT），这增加了实现复杂度与设计成本。
适用场景区别
强一致：适用于金融交易、库存扣减、身份认证等场景。
对数据正确性与顺序性要求极高的业务场景，但需接受较高的延迟与可用性折衷。
最终一致：适合社交媒体分发、缓存系统、日志聚合等，对短期不一致可容忍但要求高吞吐、与可用性的场景。
风险在于短时间内读到陈旧、或冲突数据。
可能导致用户体验或业务逻辑异常，需在业务层进行补偿或幂等处理。
mikechen睿哥
10年+一线大厂架构实战经验，就职于阿里、淘宝等一线大厂，操盘多个亿级大厂核心项目。