分布式系统 on Tony老师的博客

Pulsar 与 Kafka 核心区别深度解析

Mon, 26 May 2025 00:00:00 +0000

Pulsar 是 Apache 旗下的分布式消息队列，由 Yahoo 开源，专为云原生时代设计；Kafka 是 LinkedIn 开源的老牌消息队列，以高吞吐量闻名。两者在架构、设计哲学和适用场景上有显著差异。

分布式事务：2PC、SAGA、TCC 的工程取舍

Sun, 18 Sep 2022 15:00:00 +0800

1987 年 Héctor García-Molina 与 Kenneth Salem 在 ACM SIGMOD Record 发表《Sagas》论文，提出将长事务拆分为多个子事务并通过补偿机制回滚的概念。这篇论文在 30 多年后成为微服务架构下分布式事务的核心方案之一。

但 Saga 不是银弹。在 Saga 之前，计算机科学界已经研究过 2PC（两阶段提交）几十年；在 Saga 之后，2007 年 Pat Helland 在《Life beyond Distributed Transactions: an Apostate’s Opinion》中明确宣告跨域分布式事务不可能存在。正是在这种矛盾中，国内电商场景孕育出了 TCC（Try-Confirm-Cancel）模式，并由阿里 DTP、ByteTCC、Seata 等开源框架落地。

OpenTelemetry 工程化：从 SDK 到 Collector 的全链路落地

Mon, 15 Aug 2022 16:00:00 +0800

2022 年初我们还在用 Jaeger SDK + Prometheus client + Loki SDK 三套独立可观测体系。每个语言栈要维护三套埋点，新人入职第一周基本都在学"哪段代码要插哪个探针"。那年 6 月我们启动 OpenTelemetry 迁移 —— 不是为了追新，而是因为"统一"已经压过"性能"和"习惯"。

OpenTelemetry（OTel）不是某个产品，而是一套 规范 + SDK + 协议 + 工具 的总和。它在 2021 年 2 月发布 Tracing 1.0 GA，2021 年 CNCF 进入 Incubating，已经成为云原生可观测的事实标准。本文从三大信号、SDK 设计、Collector 架构、采样策略四个维度，给出生产级落地的工程经验。

混沌工程实践：从 Chaos Monkey 到 Chaos Mesh 的演进

Fri, 08 Apr 2022 11:00:00 +0800

2021 年双十一凌晨 1 点，我们一个核心订单服务因为 Redis 抖动雪崩了 17 分钟。事后复盘：监控告警是有的，但"Redis 主从切换 + 客户端超时 + 下游线程池打满"这条故障链，从没在生产演练过。次年我们启动了混沌工程专项 —— 不是为了"搞破坏"，而是为了让"故障响应"变成肌肉记忆。

混沌工程不是故障注入工具的堆砌。它是一套围绕"假设 → 实验 → 学习 → 改进"的工程方法论，过去十年从 Netflix 的"野蛮猴子"演化为云原生的精细化平台。本文梳理这条演进线，并给出 K8s 时代落地 Chaos Mesh 的实战经验。

分布式锁：Redis / etcd / ZooKeeper 三种实现的全对比

Tue, 22 Feb 2022 11:00:00 +0800

2014 年 antirez 发表《Distributed locks with Redis》提出 Redlock；2016 年 Martin Kleppmann 在《How to do distributed locking》中公开反驳其正确性。这场争论留下的最重要结论是：分布式锁的正确性不能只靠锁本身。

理解分布式锁要先承认一个事实——没有完美的分布式锁。每种实现都有失效场景，工程师的任务是选一个"代价可接受"的方案，而不是找一个"绝对正确"的方案。

可观测性三大支柱：Metrics、Logs、Traces 的工程落地

Mon, 15 Mar 2021 10:00:00 +0800

2017 年 Pinterest 工程团队在 SREcon 上分享其监控平台 Bender 时展示过一组数字：单业务域的时序指标规模动辄上万，传统告警体系面对每天数百条告警已经疲于奔命，但工程师真正关心的"这个请求为什么慢"却往往无解。那个时刻暴露了一个被广泛忽视的事实——传统监控（Monitoring）解决的是"系统是否在运行"，而真正想回答"系统为什么这样运行"，需要的是可观测性（Observability）。

监控与可观测性不是同义词。监控是一组预定义的仪表盘和告警规则，依赖"已知未知"——你必须先想象故障形态。可观测性是一套能从系统外部行为反推内部状态的能力，依赖"未知未知"——即使面对从未发生过的故障，也能从足够丰富的遥测数据中推断根因。

Kubernetes 架构：控制平面与数据平面的协作

Tue, 20 Oct 2020 16:00:00 +0800

2014 年 Google 开源 Kubernetes 时，Docker 已经独霸容器市场，但"容器编排"领域还是群雄割据：Mesos、Swarm、Nomad 各占山头。六年后，Kubernetes 几乎统一了整个云原生版图，成为容器时代的事实标准。

理解 Kubernetes 的关键，是把它的架构切成两个平面来看：控制平面（Control Plane）做决策，数据平面（Data Plane）执行决策。这两个平面通过声明式 API 和 list-watch 机制协作，构成一个典型的"分布式控制系统"——本质上和 Borg 的设计哲学一脉相承。

消息队列选型：Redis Stream、RabbitMQ、Kafka 的语义差异

Tue, 10 Dec 2019 10:00:00 +0800

新团队第一次接入消息队列，几乎都会问同一个问题：Redis Stream、RabbitMQ、Kafka 选哪个？三种方案在 benchmark 文章里都能跑到几十万 QPS，单看吞吐根本分不出胜负。但真正上线之后踩到的坑——消息被消费了两次、消费者卡住之后整个队列堆积、镜像队列脑裂后丢消息——都跟性能数字毫无关系。

分歧的根源不是性能，而是三者对"一条消息属于谁、什么时候算处理完"这个问题的回答完全不同。性能只是表面，语义模型才是选型的核心。

限流四算法：从计数器到令牌桶的工程取舍

Wed, 16 Oct 2019 10:00:00 +0800

凌晨三点，监控系统告警：下单服务的 P99 延迟从 80ms 跳到 4s，CPU 跑满，数据库连接池打满，线程全部阻塞在等锁。重启服务、扩容数据库、加机器,十分钟后雪崩回来。问题根源不是代码 bug，是上游推荐服务在做一次全量重算，把下单接口的 QPS 从 2k 顶到 12k——所有资源都被拖垮，正常的请求也跟着排队超时。

这就是典型的"过载崩":服务不是慢慢变慢,而是像多米诺骨牌一样整体失能。排队论早就告诉我们，当系统利用率接近 100% 时，等待时间会呈指数级上升，客户端等不到响应就会重试，重试又叠加到已经过载的系统上，正反馈循环,雪崩。限流是在过载边缘切一刀,把多余的请求挡在外面,保护自己,也保护共享资源的所有调用方。

这篇文章想回答几个问题:主流的限流算法有哪几种、各自的取舍是什么?从单机限流到分布式限流,真正难的是哪一步?线上落地时应该选 Nginx、OpenResty 还是应用层自己实现?

库存扣减与超卖：一个需求逼出的四种并发方案

Mon, 20 May 2019 10:00:00 +0800

2019 年初做秒杀系统复盘时翻过十几起线上事故，超卖几乎占了一半。表面看是"库存扣成了负数"，往里追都是同一类问题：多个请求同时读到同一个库存数，各自减 1 后写回去，结果卖了 10 件只扣了 1 次。

这种 bug 在开发环境复现不出来，单线程测试一切正常；上了几千 QPS 立刻原形毕露。这篇文章想回答几个问题：为什么"先 SELECT 再 UPDATE"必然超卖？悲观锁、Redis 预扣、分段库存各自解决什么又引入什么？面对真实的库存扣减需求，怎么在四种方案里挑一个？

微服务架构演进：从单体到分布式的路径

Mon, 08 Apr 2019 10:00:00 +0800

2014 年 Martin Fowler 发表那篇著名的《Microservices》时，整个 Java 社区还在为 Spring Boot 的"约定优于配置"而兴奋。五年过去，单体（Monolith）依然是大多数团队的首选结构——不是因为它好，而是因为拆分的代价足够大，没人愿意轻易付账。

我们见过太多团队把"微服务"当成万能膏药：在还没有遇到单体痛点的时候强行拆服务，结果既享受不到单体的开发效率，又背上了分布式系统的运维负担。

这篇文章想回答一个朴素的问题：什么时候应该拆？怎么拆？拆完又该如何收尾？

Redis 分布式锁与 Redlock 争议：Martin Kleppmann 的拷问

Sun, 25 Nov 2018 10:00:00 +0800

分布式锁是分布式系统的常见组件——秒杀、限流、任务调度都依赖它。Redis 因为性能好、部署简单，常被用来实现分布式锁。但是 Redis 单实例的锁正确吗？Redlock 多实例锁的算法真的安全吗？本文从 SETNX 出发，逐步剖析 Martin Kleppmann 在著名文章《How to do distributed locking》中对 Redlock 的拷问。

最简单的锁：SETNX + 过期

SETNX lock:order 1
EXPIRE lock:order 30

这是 Redis 分布式锁的最朴素实现。但有一个致命问题：如果 SETNX 后客户端崩溃，EXPIRE 永远不会执行——锁永久不释放。

正确做法是用一条原子命令：

SET lock:order 1 NX EX 30

NX 仅当 key 不存在时设置；EX 30 设置 30 秒过期。原子操作。

单实例 Redis 锁的局限

sequenceDiagram
 participant C as Client A
 participant R as Redis
 participant C2 as Client B

 C->>R: SET lock foo NX EX 30
 R->>C: OK (获得锁)

 Note over R: 主从切换！<br/>从节点晋升<br/>丢失锁记录

 C2->>R: SET lock bar NX EX 30
 R->>C2: OK (也获得锁)

主从切换是单实例 Redis 锁的最大风险：

消息队列：Kafka 与 RabbitMQ 的设计哲学对比

Thu, 15 Nov 2018 09:00:00 +0800

面试常被问"消息队列用哪个"——但 Kafka 和 RabbitMQ 不是"谁替代谁"的关系，它们是两种完全不同的设计哲学：Kafka 是分布式日志，RabbitMQ 是智能交换机。

把 Kafka 当成"消息队列"用，就像把 Git 当成 SVN 用——能跑，但不是它擅长的方式。本文从设计哲学出发，彻底理解两者的差异。

etcd Raft 一致性协议：从理论到工程实现

Mon, 15 Oct 2018 10:00:00 +0800

在分布式系统中，让多个节点对一组操作达成一致（Consensus）是难题。Diego Ongaro 在 2014 年的博士论文《Consensus: Bridging Theory and Practice》中提出 Raft 算法，专门为了可理解性而设计。相比 Paxos 的晦涩，Raft 用工程化的方式描述了 leader 选举、日志复制等机制。本文从原理到 etcd 的实现，逐步拆解 Raft。

为什么需要一致性协议

分布式 KV 存储（如 etcd、Consul）需要在多副本之间复制写操作：

单 leader 强一致性：写必须等大多数副本确认，延迟高但强一致
多 leader 最终一致性：写入本地即返回，后台异步复制，吞吐高但不保证顺序
无 leader：Dynamo 风格 quorum 读写

Raft 是单 leader 强一致性算法的代表，目标是让 3/5 个副本的集群能容忍 1/2 个节点故障。

Raft 三种角色

stateDiagram-v2
 [*] --> Follower

 Follower --> Candidate: 超时无心跳<br/>开始选举
 Candidate --> Leader: 获得多数票
 Candidate --> Follower: 发现更高 term
 Leader --> Follower: 发现更高 term

 Follower --> Follower: 收到合法心跳
 Leader --> Follower: 主动 step down

每个节点在任意时刻处于三种状态之一

一致性哈希原理与应用

Thu, 01 Mar 2018 11:03:26 +0800

一致性哈希（Consistent Hashing）是分布式系统中的核心技术，本文介绍其原理和应用场景。

一致性哈希算法：动态扩容的优雅解法

Wed, 30 Aug 2017 14:00:00 +0800

2018 年初写过一篇一致性哈希的简短介绍（consistent-hashing-analysis.md），但实际工程里仅靠"环 + 顺时针找节点"是远远不够的——会遇到数据倾斜、扩容迁移量、节点权重、热点等真实问题。本文深入剖析一致性哈希在工程落地中的取舍。

想象一个简单的场景：你的缓存集群有 3 台 Redis，10 万个商品 key 均匀分布。突然业务高峰来了，扩到 5 台——几乎所有 key 都需要重新映射，缓存命中率瞬间掉到零，DB 直接被打挂。

这就是一致性哈希要解决的问题。

Bigtable 论文中英对照全文翻译（A Distributed Storage System for Structured Data）

Sun, 22 Jun 2014 10:00:00 +0800

这是 Bigtable 论文的完整中英对照翻译。原文 14 页，正文 11 节，参考文献 38 条。

体例：每段先列英文原文（引用块），紧接中文译文。图与表格按原文内容重绘；专业术语保留英文并附中文，原文的引用编号 [n] 对应文末参考文献。

MapReduce 论文中英对照全文翻译（Simplified Data Processing on Large Clusters）

Sun, 18 May 2014 10:00:00 +0800

这是 MapReduce 论文的完整中英对照翻译。原文 13 页，正文 8 节加附录 A，参考文献 18 条。

GFS 论文中英对照全文翻译（The Google File System）

Sat, 12 Apr 2014 10:00:00 +0800

这是 Google File System 论文的完整中英对照翻译。原文 15 页，正文 9 节，参考文献 12 条。