北京
你有没有经历过这种情况：一场大促带来海量流量，后台API瞬间压力暴增，数据库被锤得喘不过气。团队的第一反应是给每个服务加一个进程内缓存，单机命中率看起来还挺漂亮。可一旦水平扩展节点，两个症状冒了出来——
第一，数据过时。每个节点都维护着自己那份数据，一个实例上更新了某个商品信息，其他实例完全看不到，用户一会儿看到新价格，一会儿看到旧价格。第二，热点熔断。少数热门键集中落在某几个节点上，流量稍大就把这几台机器打满，别的节点却闲得抠脚。那种感觉，就像在走廊里挥着扫帚躲避史密斯探员，能招架却永远夺不回控制权。
问题不在缓存本身，而在于我们把一个分布式难题当做单机问题来处理。后来我们把目光投向了一致性哈希，它在Dynamo、Cassandra这类系统里早已落地，背后的思路简洁有力：把数据放在哪和如何复制彻底分开。用一个哈希环来决定每个键归属哪个节点，新增或摘除节点只引起环上一小段数据的迁移，缓存池整体保持温热，不会出现全局重调导致的缓存雪崩。
在复制策略上，每个分片设置一个主节点负责接受写入，副本以异步方式拉取更新。这样，任何副本都能服务读请求，读负载可以水平扩展，无需每次GET都走共识；而写操作只由单个主节点串行化执行，避开了脑裂，也省去了每次操作都做仲裁的高昂成本。对比纯模N分布，一增一减节点就带来全量重塑；对比单实例主备或纯共识方案，要么遇到单点瓶颈，要么延迟高到损伤体验——这种混合设计让我们看到了既均匀加载又能灵活伸缩的可能。
为了看清差距，不妨看一段最朴素的取模路由代码：用hash(key) % len(nodes)决定落点。当节点从3台变成4台，len(nodes)从3跳到4，几乎所有键都落到了不同的节点上，缓存命中率瞬间跌到20%，整个集群被迫从数据库重建缓存，压力大到不敢回想。而采用一致性哈希和主从异步复制的方案后，扩容抖动被压缩到最低，读写路径也清晰可控。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
