Aerkui的博客

缓存一致性（Cache Consistency）当数据库中的数据发生变化时，如何保证缓存中的数据与数据库保持同步，避免读到“脏数据”或“过期数据”。缓存提升性能，但引入了数据不一致的风险。在高并发场景下，一个看似简单的“更新用户信息”操作，可能因缓存处理不当，导致用户看到旧头像长达数分钟！一致性级别方案适用场景强一致分布式锁 + 同步更新极少（性能差）最终一致90%+ 场景弱一致仅设置 TTL非核心数据🌟记住没有完美的强一致性缓存方案。在性能与一致性之间做权衡，才是工程的艺术。

幂等性（Idempotency）对同一个接口发起一次或多次相同请求，其结果完全一致，不会产生副作用。查询用户信息（GET） → 天然幂等取消一个“待支付”订单 → 成功后再次取消仍返回“已取消”，不报错扣减余额 10 元 → 调用两次就扣 20 元创建订单接口无去重 → 生成两个订单在分布式系统中，由于网络超时、客户端重试、消息重复投递等原因，幂等性不是“可选项”，而是“必选项”。保证接口幂等性，本质是“去重 + 状态判断”。创建类操作→ 用业务唯一键；状态变更→ 用状态机；表单提交。

缓存（Cache）是一种临时存储机制，把“计算耗时”或“读取慢”的数据保存在更快的存储介质中，下次直接读取，避免重复计算或查询。✅Redis（内存数据库）✅Memcached✅本地缓存（如✅浏览器缓存要不要✅ 要用于热点数据❌ 不要缓存所有数据✅ 要处理缓存穿透/雪崩/击穿❌ 不要假设数据100%一致✅ 要监控和降级❌ 不要在小项目过度设计缓存不是“银弹”，而是一把双刃剑。用得好，系统性能飞升；用不好，数据错乱、系统崩溃。理解它的优点，更要敬畏它的风险。

ZAB 协议通过Leader 主导的原子广播机制，实现了 ZooKeeper 的高可用与强一致性。写请求：必须经 Leader，通过 Zxid 保证顺序，过半提交。读请求：本地快速响应，提升性能。Zxid：逻辑时钟，协调状态与选举。通过本文的原理剖析与 Python 模拟实现，相信你已对 ZAB 协议有了更深入的理解。掌握 ZAB，不仅是理解 ZooKeeper 的钥匙，更是迈向分布式系统设计的必经之路。

本文深入解析了ZooKeeper的核心协议ZAB（ZooKeeper Atomic Broadcast）的故障恢复机制。ZAB协议通过选举阶段、发现与同步阶段、广播阶段三部分实现高可用性，其中关键在于基于ZXID的Leader选举和前向同步策略。文章对比了ZAB与Paxos、Raft的差异，并总结了分布式系统设计的四大启示：状态收敛、数据完整性、任期机制和事务日志的重要性。ZAB协议的优雅设计展现了如何在分布式系统中实现从混乱到有序的恢复过程。

本文深入解析了ZooKeeper的ZAB协议在Leader节点崩溃时的恢复机制。当Leader失效后，集群通过心跳检测触发选举流程，基于zxid和Server ID选出新Leader。恢复过程分为发现阶段（收集各节点最后处理的zxid）和同步阶段（补发缺失日志或回滚未提交事务），确保数据一致性。ZAB通过多数派确认、全局递增zxid和epoch机制，保障已提交事务不丢失且未提交事务不误提交，最终使集群重新进入广播模式恢复服务。该机制体现了分布式系统应对单点故障的健壮性，在短暂不可用后能自动恢复，维持数据一致

ZAB协议作为ZooKeeper的核心机制，通过全局唯一的zxid（48位epoch+16位counter）和单一Leader模式，为分布式系统提供严格的操作顺序保证。关键设计包括：1）集中式zxid分配确保全局可排序；2）Leader广播提案并按多数派确认提交；3）崩溃恢复时通过epoch递增和日志同步维持顺序连续性。这种顺序性支撑了分布式锁、选主等关键功能，相比Paxos更专注于状态机复制场景。实践建议：写操作需通过Leader，合理设置超时处理Leader切换，并注意读操作不参与ZAB流程。

BASE理论是分布式系统设计的核心原则，强调牺牲强一致性（ACID）来换取高可用性和性能。它包含三大特性：基本可用（核心功能保底）、软状态（允许中间态）和最终一致性（数据最终同步）。通过Python+RabbitMQ的电商库存案例，演示了如何用消息队列实现最终一致性。BASE适用于高并发场景（如电商秒杀），但需注意幂等性、重试机制和监控。该理论是分布式系统在可用性与一致性之间的智慧权衡，通过异步通信等机制实现系统健壮性。

两阶段提交（2PC）协议是分布式事务领域的一座丰碑。它清晰地揭示了在分布式环境下实现强一致性的基本思路和巨大挑战。深入理解2PC的原理、流程和致命缺陷，是掌握更高级、更实用的分布式事务解决方案（如TCC、Saga、消息队列）的。

摘要：CAP理论是分布式系统设计的核心原则，指出在Consistency（一致性）、Availability（可用性）和Partition tolerance（分区容错性）三者中只能同时满足两项。由于分区容错是分布式系统的必备特性，实际选择通常是在CP（强一致性）和AP（高可用性）之间权衡。CP系统优先保证数据一致性但可能牺牲可用性，适用于金融等关键场景；AP系统优先保证服务可用性但可能暂时牺牲一致性，适用于社交网络等场景。理解CAP理论有助于在分布式系统设计中做出合理的技术选型和架构决策。