北京
你有沒有經歷過這種情況：一場大促帶來海量流量，后臺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.
