Dai Wei

普通取模扩缩容会大规模迁移 key。一致性哈希把变动控制在相邻节点，是 Memcached、Redis Cluster 等方案的常用思路之一。 要解决什么问题分布式缓存或分片集群增删节点时，hash(key)%N 会导致几乎所有 key 重映射，引发缓存击穿和迁移风暴。大促前扩容若未预估迁移量，可能拖垮后台 DB。需要扩缩容只影响环上局部区间。 核心原理哈希值映射到环，key 顺时针找第一个节点负责。新增节点只接管一部分 key；删除节点将其 interval 交给后继。虚拟节点：每物理机多个环上点，改善负载均衡。Jump Hash、Maglev 等是替代方案，实现和倾斜特性不同。 方案权衡一致性哈希不保证绝对均匀，虚拟节点数需调优（常见 100~200/物理节点）。Redis Cluster 16384 slot 是固定槽位变体，迁移按 slot 进行。范围分片利于范围查询但易热点；取模简单但扩缩容代价高。按访问模式选型。 落地要点监控各节点 key 数与 QPS；扩缩容前预热；结合副本提高可用；客户端缓存拓扑视图并处理 moved/ask。测试 ske...

分布式协调回答两件事：谁做决定，状态怎么同步。本文对比 Leader+Quorum 与 Gossip 等模式，并说明 Lease 和 Fencing 如何防止旧主捣乱。 要解决什么问题多节点需选主写元数据、抢锁、避免脑裂。无协调则各自为政；协调不当则单点或分裂。Lease 过期后旧 Leader 仍可能写存储；没有 fencing 的锁在 TTL 场景下无法阻止迟到写覆盖新主的数据。 核心原理中心化：Leader 串行化写，Follower 复制；Quorum (N/2+1) 决定 commit。Lease 授予带时限的权威，过期需重新获取。Fencing Token 单调递增，存储层拒绝旧 token。去中心化：Gossip pairwise 传播，最终一致，适合 membership 和 Cassandra 反熵，不保证即时一致写。 方案权衡中心化一致性强、路径清晰（ZK/Raft）；Gossip 扩展性好但冲突解决复杂、收敛有时间。脑裂防护需 Quorum 或 fencing，不能仅靠”我觉得我还是主”。选模式看一致延迟要求、节点规模和网络拓扑。 ...

CAP 被误读为”三选二”太久了。本文按分区场景重新解释 C、A、P 及 BASE 实践含义，并引入 PACELC 补充无分区时的延迟权衡。 要解决什么问题分布式系统网络分区不可避免。分区发生时，系统要么拒绝部分请求保线性一致，要么继续服务但允许读到旧值——这是架构选型的根本分歧。业务方常问”能不能既要又要”，需要工程师用 CAP/PACELC 语言解释物理约束而非简单拒绝。 核心原理CAP 中 C 指 linearizability，A 指非故障节点必须响应，P 指网络分区容忍。分区时只能在 C 与 A 间取舍；CA 仅单机无分区模型可行。BASE：基本可用、软状态、最终一致，是 AP 方向的工程化落地。PACELC：无分区时在 Latency 与 Consistency 间权衡，如 MySQL 异步复制 vs 半同步。 方案权衡ZK/etcd 偏 CP，选举期间可能拒绝写；Eureka/Cassandra 偏 AP，允许注册信息短暂不一致。同一系统不同操作可能 CP 或 AP——读 Follower 可能是 AP，写 Leader 是 CP。...

Raft 假设节点故障但不作恶。拜占庭模型把”撒谎的节点”也纳入考量，是区块链与开放联盟链的理论基础之一。 要解决什么问题Crash-stop 故障下 Raft 够用；若节点被入侵、伪造消息或双重投票，简单多数派无法保证安全。跨组织联盟链、部分许可链需要在不可信参与者间达成共识，成本远高于公司内部 etcd 集群。 核心原理拜占庭将军问题：n 个将军需一致行动，存在叛徒传假消息。经典结论：3f+1 节点最多容忍 f 个拜占庭节点。PBFT 等 BFT 算法通过 pre-prepare/prepare/commit 多轮交互和签名验证达成一致，消息复杂度 O(n²) 级别，延迟显著高于 Raft。 方案权衡BFT 安全强但性能开销大，一般企业内部系统用 CP 的 Raft/ZAB 即可，假设节点非恶意但会 crash。区块链因开放参与和经济激励才广泛用 BFT 变体（PoW/PoS 等是另一种威胁模型）。威胁模型驱动算法选择，不要过度设计。 落地要点内部微服务用 mTLS 和审计降低恶意风险；评估是否真需要 BFT 往往答案是否。了解 P...

跨库跨服务时本地事务不够用了。本文梳理分布式事务方案谱系及边界，强调”先减少分布式事务，再选对一致性级别”的工程思路。 要解决什么问题微服务各用独立数据库，下单涉及订单库、库存库、支付库，任一环节失败需整体回滚或补偿。单机 ACID 无法跨进程；分库分表后即使同一业务也可能跨物理库。若强行 2PC，锁持有时间长、吞吐下降，且协调者单点风险高。 核心原理2PC/XA 强一致但阻塞；Seata AT 基于 undo log 自动回滚，对业务侵入低；TCC 业务层 Try/Confirm/Cancel，灵活但编码和幂等成本高；Saga 长流程正向链+补偿链；本地消息表与 RocketMQ 事务消息通过”先落库再异步确认”实现最终一致。BASE 是大多数互联网业务的真实选择。 方案权衡强一致适合短事务、高价值金融场景；最终一致适合订单、积分、通知等可补偿场景。没有银弹——选方案看一致性要求、开发成本、运维成熟度。能合并服务或单库事务就尽量合并，是成本最低的”分布式事务解决方案”。 落地要点Outbox 模式保证消息与本地写同事务落库；TCC Confir...

理解 ZK 内部，关键是 ZAB 如何在崩溃后恢复一致并选出 Leader。本文整理广播、恢复两阶段与 session 机制，便于与 Raft 对照学习。 要解决什么问题协调服务自身必须高可用。节点宕机、网络分区时，谁有权写入、如何保证已提交事务不丢，是 ZAB 要解决的问题。运维还需面对 epoch 变更期间的服务短暂不可用、Follower 落后过多时的同步耗时等现实问题。 核心原理ZAB 分崩溃恢复（选举+同步）和消息广播（类似 quorum ack）。Epoch 标识 Leader 任期；zxid 高 32 位 epoch 低 32 位计数。选举比较 zxid 和 myid，最大者胜出。Follower 收到提案 ACK 过半 Leader 即可 commit。Session 心跳维持临时节点；超时则认为客户端死亡并删除临时 ZNode。 方案权衡写必须走 Leader，读可从 Follower 但可能 stale；选举期间不服务写。与 Raft 相似度 high 但术语和实现细节不同，面试常要求对比。Observer 节点扩展读不参与投票，适合跨机房读扩展但写路径仍...

本地锁管不住跨进程竞争。本文厘清何时需要分布式锁、锁该具备什么语义，以及哪些场景其实用 DB 条件更新或幂等就能解决，避免锁滥用拖垮吞吐。 要解决什么问题秒杀库存、定时任务互斥、分布式资源协调等场景，多个服务实例同时修改共享资源。JVM 内 synchronized 无法跨进程，可能出现超卖或 cron 重复执行。若只锁”查询库存”而不锁”扣减+写订单”整段临界区，仍然会在并发写路径上出错。 核心原理分布式锁把互斥状态存到所有进程可访问的外部系统（Redis/ZK/DB/etcd）。基本条件：互斥、高可用防死锁（TTL/会话）、安全释放（只删自己的锁）。进阶语义包括可重入、阻塞/tryLock 语义、看门狗续约，以及 Fencing Token——下游存储只接受更大 token 的写，拦截锁过期后的迟到写。锁与 Leader 选举、Quorum 同属协调问题家族。 方案权衡锁降低并发度，能用 DB 条件更新（where count>0）、唯一索引、乐观锁、MQ 串行消费的场景不必上锁。Redis 锁高性能适合短临界区；Z...

技术方案要落到业务语境才有意义。本文从订单号、券码、支付码等场景梳理 ID 设计的额外约束，说明如何在通用算法之上叠加业务编码规则。 要解决什么问题纯技术 ID 方案未考虑业务可读性、防猜测、对账需要和渠道编码。订单号可能要带日期和业务线便于客服查询；优惠券要短且难爆破；一码付二维码需固定长度便于扫码设备解析。若直接暴露 DB 自增 ID，还存在竞对估算销量和恶意遍历的风险。 核心原理业务 ID 常在 Snowflake/号段之上叠加：时间分段（按日分库分表）、业务前缀（区分订单类型与渠道）、随机盐（防遍历）、校验位（防手工输错）。订单号可用”日期+序列+分片位”组合；短码用 Base62 压缩并剔除易混淆字符；支付码绑定用户/session 并设 TTL，消费后立即失效。 方案权衡可读性 vs 安全性：纯递增易猜测，需加随机段或哈希；长度 vs 容量：短码用户友好但熵空间小，要监控使用率；中心化发号易管控但增加依赖，本地生成低延迟但 workerId 治理复杂。对外 ID 与对内 surrogate key 分离是常见折中：内部仍用 bigint，对外展...

订单号、消息 ID、分库分表主键都需要”全局唯一且可用”。本文对比常见生成方案及选型维度，帮助在性能、有序性和运维复杂度之间做理性取舍。 要解决什么问题多节点并发生成 ID 时，数据库单表自增成为瓶颈且暴露业务量；UUID 虽唯一但无序，B+ 树索引插入性能差，也不利于按时间范围排查。业务还可能要求趋势递增、固定长度、不含敏感信息或便于客服口述，单一技术方案往往无法同时满足所有维度。 核心原理评估维度包括：唯一性、吞吐、趋势递增、信息安全、高可用与运维成本。UUID 本地生成无中心瓶颈但无序；Snowflake 用时间戳+机器号+序列号，趋势递增但依赖时钟与 workerId 分配；号段模式从 DB 批量取号，降低 DB 压力；Leaf、Tinyid 等在 Snowflake 或号段思路上做双 buffer、缓存优化等工程增强。 方案权衡UUID 适合日志 traceId 等无排序场景；Snowflake 适合高并发订单号；号段适合可容忍预分配、希望减少 DB 访问的场景；Redis INCR 实现简单但需考虑持久化、主从切换时的重复风险。不要用一种方案套所有业务——对外订单...

配置散落在各服务里时，改一个开关要发版十几次。配置中心解决的是”配置如何集中发布、审计与热生效”，本文对比主流方案并给出落地注意事项。 要解决什么问题微服务实例众多，数据库连接串、功能开关、限流阈值分散在本地文件或环境变量中。变更常需重启或重新打包，缺乏审计、灰度和一键回滚，还易出现测试与生产配置漂移。事故复盘里常见的”配置改错一台没改全”本质上是缺乏单一可信源和推送机制。 核心原理配置中心提供集中存储、版本管理、推送或长轮询、权限与变更审计。客户端启动拉取全量配置，运行中订阅变更并热更新到 Spring Environment 或等价机制。与注册中心的职责边界：配置中心管参数与开关，注册中心管实例地址与健康状态。Nacos 两者兼有，但概念上仍应分开设计命名空间与权限模型。 方案权衡Apollo 功能完整，灰度发布、权限、审计成熟，适合大型 Java 团队；Nacos 配置+注册一体化，运维组件少；Spring Cloud Config 依赖 Git 作为后端，适合配置即代码但实时性偏弱；K8s ConfigMap/Secret 适合容器原生部署，但缺少细粒度 U...