分布式系统

2019年，某支付平台因消息重复处理导致同一笔订单被扣款两次。工程师排查后发现，消费者在处理完消息后、发送确认前崩溃，消息队列在超时后重新投递，而业务代码没有实现幂等性。这不是个例——在分布式系统中，消息的重复投递几乎是不可避免的。 ...

2008年8月，Netflix的数据库损坏导致DVD配送业务完全停滞了三天。这次事故的直接原因是数据库系统没有正确处理硬件故障，但更深层的原因是工程师们对系统在真实故障场景下的行为缺乏信心。Netflix当时的工程总监发问：“我们怎样才能确保这种事不再发生？“团队给出的答案是：让故障更频繁地发生。 ...

title: “一致性哈希的三十年演进：从MIT论文到全球基础设施的算法传奇” date: “2026-03-07T01:06:51+08:00” description: “深入解析一致性哈希算法从1997年MIT论文到现代分布式系统的演进历程。从Karger等人的原始论文出发，探讨环哈希原理、虚拟节点设计、Amazon Dynamo的生产实践、Google的Jump Hash与Maglev算法，以及Anchor/Dx等新一代算法的技术权衡。通过数学分析与工程实践的双重视角，揭示这一算法为何能统治分布式系统三十年。” draft: false categories: [“分布式系统”, “算法”] tags: [“一致性哈希”, “分布式系统”, “负载均衡”, “Dynamo”, “算法演进”] 2007年，Amazon的购物车服务面临一个看似无解的问题：数千万用户同时在线，购物车数据需要在数百台服务器间分布存储。传统方案是简单的取模哈希——server_id = hash(user_id) % N，但当任何一台服务器宕机或扩容时，N值变化导致几乎所有用户的购物车数据都需要迁移。这不仅是性能问题，更是可用性灾难。 ...

监控大屏上，API的平均响应时间稳定在50毫秒左右，一切看起来运行良好。直到用户投诉开始涌入——“页面加载好慢”、“请求经常超时”。你打开日志，发现大量请求耗时超过2秒，有些甚至超过5秒。平均值没有撒谎，但它也没有告诉你完整的故事。 ...

一个拥有10台服务器的集群，负载均衡器配置为最简单的轮询策略。每台服务器每秒处理100个请求，看起来完美均衡。直到某天凌晨，其中一台服务器因为硬件故障开始变慢——响应时间从10毫秒飙升到2秒。轮询算法依然忠实地将十分之一的流量发送给它。 ...

一个电商平台的订单系统收到两条消息：先是"订单已付款"，紧接着是"订单已发货"。但消费者处理时，先处理了"已发货"，再处理"已付款"。数据库里的订单状态变成了一个诡异的组合——用户明明已经付款，系统却显示发货在付款之前。 ...

2010年9月，Google Docs团队发布了一篇博客文章，宣布新版Google Docs采用了全新的协作架构。他们提到，旧版本需要约1秒钟来显示其他用户的编辑，而新版本将延迟降低到了毫秒级。这背后的技术——Operational Transformation（操作转换）——在之后的十几年里成为了实时协作的行业标准。 ...