distributed 分类归档

共 65 篇文章 · 返回首页

【分布式系统百科】物理时钟的谎言:NTP、PTP 与时钟漂移的工程现实

分布式系统的物理时钟从来不精确:石英振荡器每天最多漂移 8.6 秒,NTP 校准依赖对称网络假设,闰秒可以在凌晨击垮 Linux 内核。本文拆解石英漂移的物理根源、NTP/PTP 协议的校准机制、时钟跳变对超时逻辑的破坏、Spanner TrueTime 和 AWS Clockbound 的工程方案,以及工程师应该遵守的墙上时钟与单调时钟使用规范。

【分布式系统百科】共识问题的精确定义:Agreement、Validity、Termination

共识到底在解决什么问题?Agreement、Validity、Termination 三个性质的精确含义是什么?Safety 和 Liveness 的区分为什么如此关键?FLP 不可能定理对工程实践意味着什么?本文从形式化定义出发,逐步展开共识的变体、原子广播的等价性,以及状态机复制这个最重要的应用。

【分布式系统百科】Viewstamped Replication 与 PBFT:从 CFT 到 BFT

从 Oki 和 Liskov 1988 年提出的 Viewstamped Replication,到 Castro 和 Liskov 1999 年的 PBFT,共识协议经历了从崩溃容错到拜占庭容错的质变。本文深入拆解 VR 的正常操作、视图切换与恢复协议,对比 PBFT 的三阶段提交、O(n²) 消息复杂度与水位机制,分析从 CFT 到 BFT 的本质代价。

【分布式系统百科】HotStuff 与现代 BFT:从三轮到两轮的优化之路

PBFT 的 O(n²) 视图切换是 BFT 共识的性能瓶颈。HotStuff 用门限签名将消息复杂度压到 O(n),用三轮投票统一正常路径和视图切换。Chained HotStuff 进一步把三轮流水线化为每个视图只需一轮 Generic 投票。本文从 PBFT 瓶颈出发,拆解 HotStuff 的核心设计,追踪 DiemBFT、Tendermint、Narwhal-Bullshark 等现代 BFT 的演化脉络,并讨论 BFT 在非区块链场景的实际价值。

【分布式系统百科】主从复制:同步、异步与半同步的工程权衡

一份数据写到一个节点,怎么安全地复制到其它节点?同步复制保证强一致但拖慢写入;异步复制延迟低但 Leader 崩溃可能丢数据;半同步在两者之间找平衡。本文拆解 PostgreSQL Streaming Replication、MySQL Semi-Sync / Group Replication、Galera Cluster 的工程实现,深入分析复制延迟的三类一致性陷阱和故障转移中的脑裂与数据丢失问题。

【分布式系统百科】多主复制:冲突检测与解决策略的深水区

单主复制只有一个节点能写入,跨数据中心延迟高、写入吞吐有上限。多主复制(Multi-Leader Replication)让每个数据中心都有自己的 Leader,写入延迟降到本地网络级别——但代价是并发写入可能产生冲突。本文深入拆解向量时钟的冲突检测机制、五种主流冲突解决策略(LWW、自定义合并函数、CRDT、OT、无冲突 Schema 设计)以及 CouchDB 的多主实战案例,帮你判断什么场景值得趟这趟浑水。

【分布式系统百科】无主复制:Dynamo 风格的读写 Quorum

主从复制依赖 Leader 串行化写入,Leader 挂了就得等故障转移;多主复制解决了跨数据中心延迟,但冲突解决极其复杂。无主复制(Leaderless Replication)走了第三条路:去掉 Leader,任何节点都能接受读写,用 Quorum 机制保证读到最新值。本文从 Amazon Dynamo 论文出发,深入拆解 R+W>N 公式的数学本质、Sloppy Quorum 与 Hinted Handoff 的可用性权衡、Read Repair 与 Anti-Entropy 的收敛机制,并结合 Cassandra 和 DynamoDB 的工程实现给出生产级调优建议。

【分布式系统百科】线性一致性的实现:从理论定义到工程验证

在分布式系统中,一致性模型定义了并发操作的行为边界。线性一致性(Linearizability)作为最强的一致性保证,为分布式对象提供了与单机原子操作相同的语义。它让程序员可以像推理本地变量一样推理分布式系统,但实现代价高昂。本文深入探讨线性一致性的形式化定义、实现方法、优化技术以及验证手段。

【分布式系统百科】复制日志的设计:物理复制 vs 逻辑复制 vs 状态机复制

分布式系统中的复制机制离不开日志。无论是数据库的主从复制、消息队列的分区副本,还是共识算法中的状态同步,背后都依赖某种形式的复制日志(Replication Log)。但并非所有日志设计都是相同的——根据复制的粒度和抽象层次,我们可以将复制日志分为三大类:物理复制(Physical Replication)、逻辑复制(…

【分布式系统百科】哈希分区:一致性哈希、Jump Hash 与虚拟节点

当单台机器无法容纳全部数据时,我们需要将数据分散到多台机器上,这就是分区(Partitioning)。哈希分区是最常见的分区策略之一,通过哈希函数将数据均匀分布到各个节点。本文将深入探讨哈希分区的演进历程:从最朴素的取模哈希,到解决扩容问题的一致性哈希(Consistent Hashing),再到 Google 提出的…

【分布式系统百科】数据再平衡:固定分区、动态分区与 TiKV 的调度策略

在上一篇文章中,我们讨论了分布式系统中的二级索引问题。本文将深入探讨数据再平衡(Rebalancing)的核心策略和实现细节。当分布式系统运行一段时间后,数据分布可能会变得不均匀,节点可能会加入或离开集群,这时就需要再平衡机制来重新分配数据,保证系统的负载均衡和高可用性。

【分布式系统百科】3PC 的理论改进与 Saga 的工程妥协

2PC 阻塞时协调者宕机怎么办?3PC 试图用额外一轮消息解决,却撞上网络分区。Saga 放弃全局锁,用补偿事务换取可用性。本文从 Skeen 论文推导 3PC 的非阻塞证明,分析其分区缺陷,再到 Saga 编排/协同、补偿陷阱、Temporal 工程实践和 TCC 资源预留——把分布式事务的理论与工程讲清楚。

【分布式系统百科】Percolator 模型:Google 的乐观事务方案

Percolator 在 Bigtable 之上用三列设计实现了跨行分布式事务,其核心思路是把事务协调状态编码进数据本身,从而消除了对专用协调者节点的依赖。本文拆解其两阶段提交流程、冲突检测与锁清理机制,并分析 TiDB 对该模型的工程改进。

【分布式系统百科】Spanner 与 TrueTime:用硬件解决分布式时间问题

在分布式系统中,时间一直是一个令人头疼的问题。不同机器的时钟会产生漂移,网络延迟让时间同步变得困难,而许多一致性协议又严重依赖时间排序。Google 的 Spanner 系统通过一个大胆的想法打破了这个困境:既然软件无法完美解决时间问题,为什么不用硬件来解决?TrueTime API 就是这个思路的产物——通过 GPS…

【分布式系统百科】分布式快照隔离:从 Write Skew 到 Serializable SI

在分布式数据库的事务处理领域,快照隔离(Snapshot Isolation,SI)已经成为工业界最主流的隔离级别实现。从 Oracle 到 PostgreSQL,从 CockroachDB 到 TiDB,SI 凭借其优秀的并发性能和相对简单的实现复杂度,在理论的严格性与工程的实用性之间找到了一个绝佳的平衡点。然而,S…

【分布式系统百科】分布式事务实战对比:TiDB vs CockroachDB vs YugabyteDB

自 Google 在 2012 年发表 Spanner 论文以来,分布式数据库领域掀起了一场深刻的变革。Spanner 向世界证明了一个长期被认为不可能的命题:在分布式系统中,我们可以同时获得水平扩展能力、强一致性和 SQL 语义。这打破了传统 NoSQL 系统"为了扩展性而牺牲一致性"的惯例,开启了所谓的 NewSQ…

【分布式系统百科】Dynamo 论文精读:最终一致性的工业级范本

2007 年,Amazon 在 SOSP 会议上发表了《Dynamo: Amazon's Highly Available Key-value Store》论文,这篇论文彻底改变了分布式存储系统的设计思路。与追求强一致性的传统数据库不同,Dynamo 选择了一条完全不同的道路:牺牲一致性,换取可用性和分区容错性。这个设…

【分布式系统百科】从 GFS 到 HDFS:分布式文件系统的设计空间

Google 在 2003 年 SOSP 上发表的 GFS 论文,定义了现代分布式文件系统的基本架构模式。十几年过去,GFS 的设计思想深刻影响了开源世界的 HDFS、工业界的后继者 Colossus,以及我们对分布式存储的理解。本文深入分析 GFS 的核心设计决策,特别是单 Master 架构的利弊权衡;探讨 HDF…

【分布式系统百科】分布式 KV 存储对比:etcd、TiKV 与 FoundationDB

一个典型的架构评审场景:团队需要一个分布式键值存储来承载新系统的元数据。候选方案三个——etcd、TiKV、FoundationDB。三者都提供强一致性保证,都经过大规模生产验证,但设计目标截然不同。选错了,轻则性能不达标,重则数据丢失后无法恢复。这篇文章从架构、实现、性能和局限四个维度,把三个系统拆开来看。

【分布式系统百科】NewSQL 架构拆解:Spanner、CockroachDB 与 TiDB

某电商团队的订单库跑在 MySQL 上,单表 12 亿行,64 个分片散布在 16 台物理机。每到大促,DBA 手动执行扩容脚本:新建分片、配置路由、灰度迁移、双写校验——一整套流程需要 72 小时。更麻烦的是跨分片的事务:用户下单时需要同时扣减库存和写入订单,中间件层勉强用 XA 两阶段提交撑着,但超时重试导致的数据…

【分布式系统百科】CRDT 理论:从半格代数到强最终一致性

两个用户同时在协作文档的同一段落各自插入了一句话。没有中心服务器协调,两台设备在断网状态下各自完成编辑,重新上线后需要合并。如果简单地用"后写入者胜出"策略,必然丢弃一方的修改;如果走共识协议,断网期间就无法写入。有没有一种数据结构,能让每个副本独立更新,在任意顺序收到对方的更新后自动收敛到同一状态,且不丢失任何修改?

【分布式系统百科】CRDT 类型目录:从计数器到序列的完整图谱

三个节点同时对同一个购物车执行"添加商品"操作,网络恢复后购物车里应该有几件商品?如果两个用户在协同文档里同时输入文字,合并后的文本是否会出现乱序或丢字?这些问题看似简单,但背后对应的数据结构设计空间却异常庞大。CRDT(Conflict-free Replicated Data Type,无冲突复制数据类型)正是为了…

【分布式系统百科】MapReduce:大规模数据处理的工程原点

你有 20TB 的网页爬虫数据,需要统计每个词出现了多少次。一台机器,内存 64GB,磁盘吞吐 200MB/s——光读一遍数据就要将近 28 小时。你可以把数据切成 2000 份,分到 2000 台机器上并行处理,理论上几分钟就能跑完。但问题马上变了:哪台机器处理哪一份?中间结果怎么汇总?其中 50 台机器跑到一半挂了…

【分布式系统百科】Flink 深度拆解:流计算引擎的工程实现

一个支付系统每秒接收数万笔交易事件,需要按 5 分钟窗口统计每个商户的交易总额。问题来了:网络延迟导致一笔 14:59:58 产生的交易在 15:00:03 才到达系统。如果按数据到达时间(处理时间)划分窗口,这笔交易会被错误地归入 15:00-15:05 的窗口,导致 14:55-15:00 窗口少算了一笔,15:0…

【分布式系统百科】Dataflow 模型与流批一体:统一数据处理的理论基础

某电商平台的数据团队维护着两套代码:一套 MapReduce 任务每天凌晨跑全量订单统计,另一套 Storm 拓扑实时计算 GMV 大屏指标。两套系统使用不同的编程模型,实现同一份业务逻辑——按区域统计销售额、按品类计算转化率。问题从第一天就存在:批处理代码更新了折扣计算规则,流处理代码忘了同步,导致实时大屏与 T+1…

【分布式系统百科】ZooKeeper 内核:从 ZAB 协议到分布式协调实践

深入拆解 ZooKeeper 的核心机制:ZAB 协议的三阶段流程、ZNode 数据模型、Watch 一次性通知、会话管理,以及分布式锁、Leader 选举、配置管理等典型用法。分析惊群效应等已知问题,并梳理 ZooKeeper 在 Kafka、HBase、Hadoop 生态中的角色。

【分布式系统百科】分布式锁的真相:从 Redlock 争论到 Fencing Token

完整还原 Kleppmann 与 Antirez 关于 Redlock 的技术争论,拆解 Fencing Token 方案的原理与实现,对比基于 etcd 和 ZooKeeper 的分布式锁正确实现,讨论锁粒度、Advisory Lock 与 Mandatory Lock 的区别,以及用版本号代替锁的替代思路。

【分布式系统百科】RPC 框架内核:从透明调用幻觉到工程实战

2020 年 11 月 25 日,Google 全球范围的服务连锁故障。根因是内部 RPC 框架的一个默认超时配置:当身份认证服务响应变慢时,数十万个 RPC 调用阻塞在等待认证结果上,连接池耗尽,请求堆积如山,最终拖垮了包括 Gmail、YouTube、Google Cloud 在内的几乎所有面向用户的服务。一个看起…

【分布式系统百科】可靠广播:从尽力而为到全序的五层抽象

三个副本需要以相同顺序执行同一批写操作。节点 A 先广播 x1,再广播 x2;节点 B 收到的顺序却是 x2 然后 x1。副本状态分叉了——A 认为 x2,B 认为 x1。更糟糕的是,如果 A 在发完第一条消息后崩溃,某些节点收到了 x1,另一些没收到。此时系统中存在两类节点:知道 x1 的和不知道的。后续所有基于 x…

【分布式系统百科】新硬件对分布式系统的冲击

一个 RPC 调用耗时 500 微秒,其中网络往返占了 490 微秒。一次分布式事务需要两轮 RPC,总耗时超过 1 毫秒。为了掩盖这个延迟,工程师不得不引入批处理、异步流水线、预取缓存——系统复杂度因此翻了好几倍。过去三十年,几乎所有分布式系统的设计都建立在一个核心假设之上:网络比本地内存慢三到四个数量级。Share…

【分布式系统百科】存算分离架构

一个电商平台的核心交易数据库运行在三节点集群上,每个节点配备 64 核 CPU、512 GB 内存和 8 TB NVMe SSD。年底大促结束后,数据量从 5 TB 膨胀到 18 TB,存储空间告急。但 CPU 利用率在非促销期长期低于 15%。运维团队提交了扩容工单:要么给每个节点挂载更大的磁盘——但这要求停机迁移数…

【分布式系统百科】Serverless 的分布式系统挑战

一个后端工程师写了一段 50 行的 Node.js 函数:接收 HTTP 请求,从数据库查一条记录,做一次格式转换,返回 JSON。他把这段代码上传到 AWS Lambda,配好 API Gateway,五分钟后就拿到了一个能承受每秒数万请求的线上接口。不需要配置服务器,不需要操心容量规划,不需要写自动伸缩策略,甚至不…

【分布式系统百科】可验证分布式系统的未来

2013 年,一组研究人员对 Raft 协议的多个开源实现进行了系统性审查。其中一个实现通过了开发者编写的全部 3000 余条单元测试和数十个集成测试,在长达六个月的生产环境运行中未出现任何可观测的故障。然而,当研究人员用一个精心构造的网络分区序列去测试它时,系统在 47 秒内就违反了线性一致性(Linearizabi…

【分布式系统百科】一致性模型全景:从线性一致性到最终一致性的光谱

分布式系统中一致性模型不是二选一,而是一条光谱。本文从线性一致性、顺序一致性讲到因果一致性、最终一致性及其变体,用反例区分每一级的差异,用 Go 代码实现操作历史的一致性检测,并把 ZooKeeper、Spanner、DynamoDB、Cassandra 映射到这条光谱上。

【分布式系统百科】会话保证与因果一致性:用户视角的一致性

最终一致性承诺'最终'收敛,但没说收敛之前用户会看到什么。你改了头像刷新后消失、余额先涨后跌、回复比原帖先出现——这些都是缺少会话保证的症状。Terry 等人在 1994 年定义了四种会话保证,COPS 和 Eiger 把因果一致性做到了跨数据中心,Bailis 的 Bolt-on 方案让老系统也能补上因果语义。

【分布式系统百科】分布式系统模型:你的假设决定你的命运

分布式系统的正确性证明和协议设计都建立在系统模型之上。同步还是异步?崩溃还是拜占庭?这些看似学术的分类,直接决定了你能用什么协议、不能用什么协议。本文拆解通信模型、故障模型和进程模型三个维度,把 Paxos、Raft、PBFT、Bitcoin 放回它们各自的模型空间。

【分布式系统百科】FLP、CAP 与不可能性结果:被误读的三座里程碑

FLP 说异步系统中共识不可能,但 Raft 跑得好好的。CAP 说三选二,但 Spanner 声称兼得。矛盾不在定理本身,在于读定理时跳过了精确条件。本文回到 FLP、CAP、共识数和收割/产出四篇原始论文,逐一拆解它们的真实陈述、证明思路与工程边界。

【分布式系统百科】Raft 深度重写:从论文的 18 页到 etcd 的 15000 行

Raft 论文 18 页就能读完,但 etcd/raft 用了 15000 行 Go 才把它变成能在生产环境跑的代码。这篇文章从论文的每一个核心机制出发,逐一拆解工程实现中论文没说的东西:PreVote、ReadIndex、LeaderTransfer、ConfChange V2、流水线复制、Async Apply,以及 TiKV 的 Multi-Raft 实践。最后做一次精确的 Paxos 对比,并坦诚讨论 Raft 的已知缺陷。

【分布式系统百科】故障的分类学:从 fail-stop 到 Byzantine

教科书把故障分成 crash 和 Byzantine 两种,但生产环境里最常见、最难处理的故障恰恰是两者之间的灰色地带:静默数据损坏、时钟跳变、GC 停顿、慢磁盘。本文从故障层级模型出发,逐层拆解五种故障类型,结合真实事故案例分析检测手段与工程应对策略。

【分布式系统百科】05 · 分布式系统的复杂性度量:消息复杂度、轮次复杂度与空间下界

顺序算法用时间复杂度和空间复杂度就能衡量好坏。分布式算法多了消息复杂度、轮次复杂度和容错数量三个维度,三者之间存在不可调和的 trade-off。本文从选主、共识、广播三个典型问题出发,梳理这些度量指标的定义、下界和工程影响。

【分布式系统百科】混合逻辑时钟与 TrueTime:在物理和逻辑之间找到平衡

物理时钟对不齐,逻辑时钟丢物理信息,向量时钟太重。HLC 用物理时间 + 逻辑计数器找到了平衡。但 Google 选了另一条路:用原子钟和 GPS 把物理误差压到几毫秒。这篇文章从 HLC 的算法正确性证明、CockroachDB 源码实现、TrueTime 工程架构,一直讲到 AWS Clockbound 的开源方案——在物理和逻辑之间,每种选择都是一笔工程账。