大家好，我是你们31岁爱折腾、爱总结、爱踩坑也爱分享的小米。这周我被一个刚跳槽成功的粉丝私信戳到：

小米哥，面试官连问我三轮 Redis 集群，我啥都答对了，结果最后被他一句：

“你们有没有用过客户端分片？讲讲你们的 Redis Sharding 怎么设计的？”

我当场破防……

说实话，这题要是放在三年前，我也得沉默良久。但现在，谁问我 Redis Sharding，我心里只有四个字：稳如老狗。

来，今天咱们就用讲故事 + 面试拆解的方式，聊透：

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

时间回到我刚入职第二年的某个凌晨 2 点。我们有个活动系统，全网发优惠券，流量直接爆了。开发的时候图省事，直接搞了一个 Redis 单点：

活动用户 -> Redis -> MySQL

结果活动开始 5 分钟：

Redis CPU 直冲 100%

连接数爆满

QPS 下降

接口延迟飙升

老板在群里吼：“你们活动要凉了？”

从那天开始，我第一次正视一个问题：

Redis 单机，再猛也有天花板。

于是我们开始搞 —— Redis Sharding，分片。

很多人一被问到 Redis 分片。第一反应就是：

我们直接上 Redis Cluster 啊，槽位分片不香吗？

没错，Redis Cluster 是官方方案，很牛，但现实世界里，并不是所有项目都适合它。那我们当时为什么选了：客户端分片（Client Side Sharding）？

三个原因：

第一，历史包袱：老系统大量用的是 Jedis + Redis Standalone，改动成本高。

第二，架构演进期：我们当时上云架构还没完全迁完，不适合大动干戈改成 Cluster。

第三，灵活性更高：客户端控制 KEY 到节点的映射规则，迁移成本可控。

所以，最终我们选了一个经典但很社招题的方案：

基于客户端配置的 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 台，你直接重来一场“数据大迁移地狱”。

面试官追问你：“那你们怎么解决扩容问题？”这时候别慌，我们接着说升级版。

这个在社招里非常加分。

核心优点：

新增/移除节点时，只影响少部分数据

大量 Key 不需要迁移

实现方式一般是：

构建一个 Hash Ring

每个 Redis 实例对应多个虚拟节点

key 映射到最近的顺时针节点

这时候你可以淡定说一句：

我们线上用的是带虚拟节点的一致性哈希，减少数据迁移成本。

面试官一般到这里已经开始点头了。

比如你是按用户 ID：

0 ~ 1千万 -> Redis 1

1千万 ~ 2千万 -> Redis 2

优点：规则清晰

缺点：数据容易倾斜，新用户可能都挤在一个节点。

所以你可以加一句：

Range 分片不太适合写多读多的热点业务，我们后来还是迁移到一致性哈希。

这就是标准优秀社招回答。

光会说还不够，我给你讲讲我们当时在项目中的设计。

1、配置驱动的 Sharding

我们没有把节点写死在代码里，而是走配置：

然后在启动时加载进一个 Sharding Router。

以后要扩容？改配置，重启服务即可。

2、自己实现路由器 RedisRouter

伪逻辑类似这样（你面试不需要写代码，但要会讲）：

对 key 进行 hash

根据 hash 计算 shardIndex

从 Redis 客户端池中选择对应节点

执行 GET / SET

面试官听完，基本会问一句：

那你们怎么处理扩容数据迁移？

这个问题是关键。

我们当时是这么搞的：

1、双写策略

新规则上线时：

同时写入新节点 + 老节点

读优先从新节点读

2、后台迁移脚本同步数据

通过扫描老 Redis 分片数据，重新写入新规则的分片。

3、观察一段时间后切流

确认新节点数据完整，再停掉老节点。

这套设计你可以浓缩成一句话：

我们采用双写 + 后台迁移 + 灰度切流的方式完成分片扩容。

这句话，社招面试非常给力。

你答题时可以这样总结：

优点：

灵活可控

可按业务自定义规则

不依赖 Redis Cluster

缺点：

业务侵入大

运维复杂

一旦算法变更，迁移成本高

然后再补一句：

所以后期如果业务复杂度上升，我们也会评估是否迁移到 Redis Cluster 或云厂商托管方案。

面试官听到这里，基本不会再为难你了。

最后分享一个真人案例。去年我跳槽，一位阿里出来的面试官问我：

“你们做 Redis Sharding，是怎么设计扩容方案的？”

我当时就把：

客户端分片

一致性哈希

双写迁移

灰度切流

配置中心控制

一套说完。他说了一句让我记了一年：

“这一块，你们是真的踩过坑，有线上实战。”

没错，很多技术问题，只有流过血，面试才讲得有底气。

如果你看到这里，说明你对 Redis 不是只想应付面试，而是真想学通。记住一句话：

Redis Sharding 不是理论题，是“踩坑题”。你可以背出它所有概念，但真上生产，才知道什么叫数据迁移像搬家，热 Key 像春运。

希望这篇文章，能成为你社招路上的一盏小灯，欢迎留言~