大家好，我是你們31歲愛折騰、愛總結、愛踩坑也愛分享的小米。這周我被一個剛跳槽成功的粉絲私信戳到：

小米哥，面試官連問我三輪 Redis 集羣，我啥都答對了，結果最後被他一句：

“你們有沒有用過客户端分片？講講你們的 Redis Sharding 怎麼設計的？”

我當場破防……

説實話，這題要是放在三年前，我也得沉默良久。但現在，誰問我 Redis Sharding，我心裏只有四個字：穩如老狗。

來，今天咱們就用講故事 + 面試拆解的方式，聊透：

「基於客户端配置的 Redis Sharding」。

從一次“血崩”的線上事故説起

時間回到我剛入職第二年的某個凌晨 2 點。我們有個活動系統，全網發優惠券，流量直接爆了。開發的時候圖省事，直接搞了一個 Redis 單點：

活動用户 -> Redis -> MySQL

結果活動開始 5 分鐘：

• Redis CPU 直衝 100%
• 連接數爆滿
• QPS 下降
• 接口延遲飆升
• 老闆在羣裏吼：“你們活動要涼了？”

從那天開始，我第一次正視一個問題：

Redis 單機，再猛也有天花板。

於是我們開始搞 —— Redis Sharding，分片。

面試官最愛問的問題：你們為什麼不用 Redis Cluster？

很多人一被問到 Redis 分片。第一反應就是：

我們直接上 Redis Cluster 啊，槽位分片不香嗎？

沒錯，Redis Cluster 是官方方案，很牛，但現實世界裏，並不是所有項目都適合它。那我們當時為什麼選了：客户端分片（Client Side Sharding）？

三個原因：

• 第一，歷史包袱：老系統大量用的是 Jedis + Redis Standalone，改動成本高。
• 第二，架構演進期：我們當時上雲架構還沒完全遷完，不適合大動干戈改成 Cluster。
• 第三，靈活性更高：客户端控制 KEY 到節點的映射規則，遷移成本可控。

所以，最終我們選了一個經典但很社招題的方案：

基於客户端配置的 Redis Sharding。

什麼是“基於客户端配置的 Redis Sharding”？

給你一個面試官滿意版解釋：

客户端分片，是由業務服務在寫入或讀取時，通過特定分片算法，將不同的 Key 路由到不同 Redis 實例，而不是由 Redis Server 或 Cluster 負責分佈數據。

再人話一點：

Redis 自己不分片，是我們客户端主動決定數據放哪台 Redis 上。

你可以想象成：

一個快遞分揀站，快遞不是自己跑，而是快遞員看地址，送往不同倉庫。

典型結構長這樣：

問題來了：

你怎麼決定一個 Key 落到 Redis-2 還是 Redis-3？

這就得講分片算法了。這是社招面試必考點，可以直接默背：

取模分片：最簡單，但也最容易翻車

最經典：

shard = hash(key) % N

比如：

• user:1001 → hash後 % 4 → 落在 redis-1
• user:1002 → hash後 % 4 → 落在 redis-3
• 優點：簡單，性能高
• 缺點：擴容就是災難（所有 Key 都要重新計算）

一旦從 4 台機器擴到 6 台，你直接重來一場“數據大遷移地獄”。

面試官追問你：“那你們怎麼解決擴容問題？”這時候別慌，我們接着説升級版。

一致性 Hash（Consistent Hash）

這個在社招裏非常加分。

核心優點：

• 新增/移除節點時，隻影響少部分數據
• 大量 Key 不需要遷移

實現方式一般是：

• 構建一個 Hash Ring
• 每個 Redis 實例對應多個虛擬節點
• key 映射到最近的順時針節點

這時候你可以淡定説一句：

我們線上用的是帶虛擬節點的一致性哈希，減少數據遷移成本。

面試官一般到這裏已經開始點頭了。

Range 分片（按範圍）

比如你是按用户 ID：

• 0 ~ 1千萬 -> Redis 1
• 1千萬 ~ 2千萬 -> Redis 2
• 優點：規則清晰
• 缺點：數據容易傾斜，新用户可能都擠在一個節點。

所以你可以加一句：

Range 分片不太適合寫多讀多的熱點業務，我們後來還是遷移到一致性哈希。

這就是標準優秀社招回答。

客户端分片在工程中的真實實現

光會説還不夠，我給你講講我們當時在項目中的設計。

1、配置驅動的 Sharding

我們沒有把節點寫死在代碼裏，而是走配置：

然後在啓動時加載進一個 Sharding Router。

以後要擴容？改配置，重啓服務即可。

2、自己實現路由器 RedisRouter

偽邏輯類似這樣（你面試不需要寫代碼，但要會講）：

1. 對 key 進行 hash
2. 根據 hash 計算 shardIndex
3. 從 Redis 客户端池中選擇對應節點
4. 執行 GET / SET

面試官聽完，基本會問一句：

那你們怎麼處理擴容數據遷移？

這個問題是關鍵。

數據遷移你怎麼做？這題92%的人答不上來

我們當時是這麼搞的：

1、雙寫策略

新規則上線時：

• 同時寫入新節點 + 老節點
• 讀優先從新節點讀

2、後台遷移腳本同步數據

• 通過掃描老 Redis 分片數據，重新寫入新規則的分片。

3、觀察一段時間後切流

• 確認新節點數據完整，再停掉老節點。

這套設計你可以濃縮成一句話：

我們採用雙寫 + 後台遷移 + 灰度切流的方式完成分片擴容。

這句話，社招面試非常給力。

客户端 Sharding 的優缺點總結

你答題時可以這樣總結：

優點：

• 靈活可控
• 可按業務自定義規則
• 不依賴 Redis Cluster

缺點：

• 業務侵入大
• 運維複雜
• 一旦算法變更，遷移成本高

然後再補一句：

所以後期如果業務複雜度上升，我們也會評估是否遷移到 Redis Cluster 或雲廠商託管方案。

面試官聽到這裏，基本不會再為難你了。

真實面試覆盤：我是怎麼征服面試官的？

最後分享一個真人案例。去年我跳槽，一位阿里出來的面試官問我：

“你們做 Redis Sharding，是怎麼設計擴容方案的？”

我當時就把：

• 客户端分片
• 一致性哈希
• 雙寫遷移
• 灰度切流
• 配置中心控制

一套説完。他説了一句讓我記了一年：

“這一塊，你們是真的踩過坑，有線上實戰。”

沒錯，很多技術問題，只有流過血，面試才講得有底氣。

結語：技術不是背出來的，是摔出來的

如果你看到這裏，説明你對 Redis 不是隻想應付面試，而是真想學通。記住一句話：

Redis Sharding 不是理論題，是“踩坑題”。你可以背出它所有概念，但真上生產，才知道什麼叫數據遷移像搬家，熱 Key 像春運。

END

希望這篇文章，能成為你社招路上的一盞小燈，歡迎留言~

我是小米，一個喜歡分享技術的31歲程序員。如果你喜歡我的文章，歡迎關注我的微信公眾號“軟件求生”，獲取更多技術乾貨！