Dai Wei

围绕“消息队列专题：异步处理、削峰填谷、可靠性、顺序性、Kafka、RocketMQ 与 RabbitMQ”，本文不按原目录复述，而是把内容整理为问题、机制、实践和取舍四层。阅读时可从“适合谁看、学习重点、建议阅读顺序、核心文章”几个切面建立自己的判断框架。 核心认识性能问题要同时观察吞吐、长尾延迟、错误率与资源饱和度。真正瓶颈可能位于入口分发、应用锁竞争、数据库访问、网络或异步消费，不能仅凭平均响应时间判断。 消息队列实现异步、解耦和削峰，也引入投递语义、重复、顺序与积压。可靠链路需要生产确认、Broker 持久化、消费幂等、死信和容量告警。 学习这类主题时，应先写清对象、边界和衡量指标，再讨论具体组件或技巧。同一方案放在不同流量、数据规模与团队能力下，结论可能相反；设计说明必须保留前提。 工程实践工程上先建立生产相近的负载与数据基线，再用执行计划、剖析和链路指标定位热点。每次只验证少量变量，复测收益并持续观察异常路径。 实施建议采用小步验证：记录变更前基线，一次只调整少量关键变量，通过日志、指标和测试判断收益。上线后继续观察长尾与异常路径，并把操作步骤沉淀成可执行预案。 ...

纸上 ZAB 不如动手起集群。本文整理 ZK 本地/容器部署、运维命令与 Curator 编码要点，帮助把概念验证落到可复现实验。 要解决什么问题概念学完需要可复现环境验证 Watcher、选举和锁行为。裸机安装繁琐，命令和监控接口不熟则故障排查只能重启试试。团队新人若只会 Curator 封装而不懂 zkCli，线上紧急排障会吃力。 核心原理Docker Compose 可快速起 ZK ensemble，注意 myid 与端口映射。zkCli 支持 create/get/set/watch/ls/delete；四字命令 ruok/stat/mntr/srvr 用于健康与指标。Curator 提供 ConnectionStateListener、PathChildrenCache、InterProcessMutex 等。连接串格式 host:port,chroot 可选。 方案权衡Docker 适合 dev/test，生产建议 StatefulSet 或裸机并持久化 dataD...

选型分布式锁实现时，要比较的不只是”能不能锁”，还有失效语义、故障模型与运维成本。本文对比 Redis、Redlock、ZK 等主流实现及适用边界。 要解决什么问题MySQL 锁表或 GET_LOCK 性能差且连接语义与业务线程生命周期耦合；Redis SET NX EX 看似简单但主从异步复制可能在 failover 后丢锁；Redlock 多节点方案在学术界仍有争议；ZK 临时顺序节点依赖 session 超时，临界区过长会丢锁。实现选型必须对齐 SLA 和可接受的极端情况。 核心原理Redis 单实例：SET key random NX EX，释放 Lua 比较再 DEL。Redisson 看门狗后台续约。Redlock 向 N 个独立 master 加锁，过半成功且总耗时小于 TTL 才算成功。ZK 创建 EPHEMERAL_SEQUENTIAL 节点，监听前序节点释放实现公平锁；Curator InterProcessMutex 封装重试与 session 监听。DB 唯一索引插入也可作互斥但吞吐低。 方案权衡Redis 适合高 QPS、短临界区、可配合幂等兜底；Z...

ZAB 是 ZooKeeper 的共识内核，与 Raft 目标相近但用 epoch+zxid 描述进度。理解 ZAB 有助于读懂 ZK 运维指标和客户端 sync 语义。 要解决什么问题ZK 需全序广播写请求，Leader 切换后已提交事务不丢，Follower 必须追平到一致点才能对外服务读（若要求 strong read）。崩溃恢复与广播两阶段切换若理解错误，会误判”ZK 挂了”其实是 election。 核心原理崩溃恢复：选举 max(zxid) 的 Leader，Follower DIFF/TRUNC/SNAP 同步。广播：Leader 提案，Follower ACK 过半 commit。zxid 高 32 epoch 低 32 counter。与 Raft 类似，ZK 4.x 文档也强调与 Raft 的对比阅读。写必须经 Leader；顺序保证来自 ZAB quorum commit。 方案权衡ZAB 面向协调小数据，不适合 Kafka 级吞吐 log。与 Multi-Paxos 目标相近实现不同。读 sync() 可绑 strong consi...

Raft 把共识拆成选举、复制、安全三块，是理解 etcd、Consul 的钥匙。本文整理 term、commit index 与 joint consensus 等面试高频点。 要解决什么问题复制状态机需要所有存活节点按相同顺序应用命令。Leader 宕机要快速 failover；网络分区不能选出双 Leader 写入；已提交 entry 不能在新区 term 被覆盖。成员变更若一步到位，可能同时存在两个多数派。 核心原理Follower 超时变 Candidate，term 递增拉票，过半成 Leader。Leader 复制 log，matchIndex 过半 commit。Election restriction：只投给 log 至少和自己一样新的 Candidate。成员变更用 joint consensus：先 C_old,new 双 majority，再 C_new，避免 split brain。Snapshot 压缩历史 log。 方案权衡Raft 写吞吐受 Leader 限制；读可用 lease read 或 Follower read（需 stale 语义）...

Paxos 是共识算法的理论基石，术语密集但思想精炼。本文用 Proposer/Acceptor/Learner 流程视角重新组织，便于与 Raft 对照。 要解决什么问题多节点对同一槽位提案，在异步网络、丢包、节点故障下仍要达成一致，且已 chosen 的值不可被覆盖。无共识则 replicated log 顺序分裂，状态机应用 diverge。Paxos 给出在 crash 模型下的可行性，但工程落地曾长期被认为困难。 核心原理Basic Paxos：Prepare 阶段 Acceptor 承诺不接受更小 proposal number；Accept 阶段多数派 accept 则 value chosen。Learner 学习结果。Multi-Paxos 选 stable Leader 串行 propose，减少活锁。角色可合并；实际系统常用简化 Multi-Paxos。与 Raft 相比，Paxos 更泛化，Raft 用 strong Leader 约束换取可理解性。 方案权衡Paxos 论文 elegant 但 corner case 多，工程实现...

微服务不是”拆越小越好”。本文整理拆分、通信与治理相关的面试要点，突出边界划分与运维复杂度之间的平衡。 要解决什么问题团队常面临：如何拆服务、RPC 还是 MQ、数据如何归属、跨服务事务怎么办、如何灰度和观测。面试考察能否把架构决策与团队规模、发布频率、业务边界联系起来，而非背诵 Netflix 组件列表。 核心原理拆分按 bounded context 和数据归属，每个服务拥有自己的数据库，通过 API 暴露能力。同步 RPC 适合查询链路和低延迟协作；异步 MQ 适合解耦、削峰和最终一致。可观测性靠日志、指标、链路追踪；容错靠超时、熔断、限流、舱壁和幂等。康威定律意味着组织架构会影响服务边界。 方案权衡微服务换独立部署和弹性，换分布式测试、链路排障和基础设施成本。小团队慎拆；大团队需平台化网关、注册、CI/CD。Service Mesh 适合大规模多语言，小项目引入 Istio 可能 overkill。单体 modular monolith 有时是更优起点。 落地要点拆分前事件风暴画上下文；禁止跨服务直连 DB；契约测试+Consumer Driven Cont...

面试复习需要”问题清单 + 答题结构”。本文归纳分布式方向的高频考点与回答框架，帮助把分散知识点串成面试官听得懂的两分钟叙述。 要解决什么问题分布式面试覆盖面广，从 CAP 到 Redis 锁到 Seata，考生易答散、缺场景、缺对比。面试官常追问”你们线上怎么选的、出过什么问题”，只背定义缺少项目映射会被认为没落地经验。 核心原理高频块：CAP/BASE 与 PACELC；Paxos/Raft/ZAB 定位；RPC vs HTTP；ID 方案对比；Redis 锁 owner/TTL/Redlock 争议；2PC/TCC/Saga/事务消息；ZK/etcd 协调语义。答题模板：一句话定义→核心流程→业务场景→方案对比→踩坑经验。每题准备 60 秒版和 3 分钟版。 方案权衡面试不必手推 Paxos 全程，但要讲清 Leader 选举和日志复制直觉。事务题强调业务可接受的一致性级别，而非罗列名词。微服务题要体现”拆分边界”和”数据归属”，避免只谈 Spring Cloud 组件名单。 落地...

Spring Cloud Gateway 是 Spring 栈网关首选。本文归纳路由匹配、过滤器链、限流熔断与 Reactive 模型等面试考点及生产注意事项。 要解决什么问题面试问 Gateway 与 Zuul 差异、Route 组成、GlobalFilter 顺序、如何实现鉴权限流、为何不要阻塞 Netty event loop。生产上还遇到路由动态刷新失败、CORS 重复、StripPrefix 配置错误导致 404 等实际问题。 核心原理Route=Id+URI+Predicate+Filter。Predicate 组合 match；GatewayFilter 作用于 route，GlobalFilter 全局。基于 WebFlux+Netty 事件驱动。RequestRateLimiter 结合 Redis；Resilience4j 做 circuit breaker。LoadBalancerClientFilter 把 lb://service 解析为真实 host。Order 决定 filter 链顺序。 方案权衡Reactive ...

Dubbo 是国内 Java RPC 代表框架之一。本文整理调用链、SPI 扩展点与负载/容错策略，便于面试和排查线上 RPC 异常。 要解决什么问题面试常问 Dubbo 一次调用经过哪些层、SPI 如何加载扩展、random 和 leastactive 区别、failfast 和 failsafe 适用场景。只会 xml/yml 配置而不懂 Invoker 链，排查超时和串包会很被动。 核心原理分层：business→rpc→remoting→cluster→registry。Export 打开 server port 注册；Refer 订阅 Directory 得 Invoker 列表。Cluster 合并 Invoker，LB 选 one，Filter 链拦截。SPI：META-INF/dubbo 下 key→impl，Adaptive 注解生成代理。Dubbo 3 推应用级服务发现和 Triple 协议。 方案权衡Dubbo 治理能力强，跨语言弱于 gRPC。注册中心 ZK vs Nacos 影响 metadata 推送模型。Generi...