Redis灰度发布其实没那么难，灵活轻松搞定数据切换和版本控制

（来源：知乎专栏《架构师成长笔记》）

很多技术团队一听到“灰度发布”就觉得头疼，以为要搭建复杂的系统、写一大堆脚本，其实用Redis来实现灰度发布，可以非常灵活简单，今天我们就抛开那些高大上的理论，直接讲几种接地气的做法，让你能快速上手,轻松搞定数据切换和版本控制。

核心思想：用Redis做个“智能开关”

灰度发布的本质，就是让一部分用户先用新版本，另一部分用户还用老版本，Redis速度快、支持复杂数据结构，正好可以充当这个控制流量的“总开关”，你不用修改数据库结构,只需要在访问Redis的地方加一点判断逻辑就行了。

按用户ID分桶（最简单实用）

这是最常用、最容易理解的方法，假设我们有1亿用户，我们想让10%的用户体验新功能。 （来源：某大型互联网公司技术博客分享的实现方案）

1. 在Redis里设置一个键，gray_release:user_bucket:new_feature_A，它的值就存一个百分比数字，10（代表10%）。
2. 计算用户分桶：当任何一个用户请求过来时，我们用他的用户ID（比如是12345678）做一个简单的哈希计算，然后取模。hash(12345678) % 100 < 10，这个计算的结果如果小于Redis里设置的百分比10，那么这个用户就命中灰度，走新逻辑；否则就走老逻辑。
3. 好处：
   • 控制精准：同一个用户每次计算的结果都一样，体验一致,不会一会儿是新版一会儿是旧版。
   • 调整灵活：如果想扩大灰度到20%，只需要在Redis里把值从 10 改成 20，然后重启应用或者通过配置中心热刷新这个值就行,全程无需停机。
   • 压力可控：可以慢慢放量，从1%开始，观察系统监控，没问题再放到5%、10%,逐步扩大。

按设备或特性打标（更精细化控制）

我们不想按用户ID来分，而是想针对特定人群，只让使用iPhone14以上的用户、或者来自北京地区的用户体验新功能。 （来源：开源项目RedisGears的用例文档）

1. 利用Redis的Set或Sorted Set：我们可以提前把符合条件的用户ID或者设备ID，导入到一个Redis的集合（Set）里，创建一个键 gray_release:whitelist:new_feature_B。
2. 判断逻辑：用户请求来时，直接检查这个用户的ID是否在这个白名单集合里。SISMEMBER gray_release:whitelist:new_feature_B user_id，返回1就是在灰度名单里,走新逻辑。
3. 好处：
   • 精准定向：可以实现非常精细的人群控制，比如内部员工、VIP用户、特定渠道的用户等。
   • 动态更新：可以随时向集合里添加或删除用户ID，实时生效，特别适合做A/B测试。

版本号控制（适用于客户端API版本管理）

当我们的服务是API接口，需要兼容多个版本的客户端时，这个方法非常管用。 （来源：一篇关于微服务API版本控制的实践文章）

1. 在Redis里存储版本映射：我们设置一个Hash结构的键 gray_release:api_version_mapping。
   • 在里面存一个字段，latest_stable，值是 v1.2（代表当前最稳定的版本）。
   • 再存一个字段，latest_experimental，值是 v2.0（代表最新的实验性版本）。
2. 客户端上报版本号：客户端在请求头里带上自己的版本号，App-Version: v1.2。
3. 服务端判断：服务端收到请求后，先去Redis读取 latest_stable 的值。
   • 如果客户端版本等于 latest_stable,就走稳定版逻辑。
   • 如果客户端版本等于 latest_experimental，并且该用户在其他灰度条件（比如方法一）中也命中了,就走新版逻辑。
   • 还可以设置一个 minimum_supported（最低支持版本），低于这个版本的客户端直接返回错误,提示升级。
4. 好处：
   • 平滑升级：可以引导用户逐步升级到新版本API,老版本用户不受影响。
   • 权限控制：可以控制只有特定版本的客户端才能访问某些新接口。

数据切换和回滚怎么办？

灰度发布最怕的就是新版本的数据结构变了,或者出问题了怎么回滚。

• 数据兼容性：在设计新版本时，最好让新老版本的数据结构在一段时间内共存，新版本写数据时，同时写入老格式和新格式，或者采用“双写”策略，这样回滚时,老版本代码还能正常读取数据。
• 快速回滚：正因为我们的灰度开关在Redis里，所以回滚变得极其简单，一旦发现新版本有问题，立刻把Redis里的灰度百分比调为0，或者清空白名单，所有流量瞬间就会切回老版本，损失最小化，这比去修改数据库配置、重启一堆服务要快得多。

总结一下

用Redis做灰度发布，其实就是“把规则交给Redis，把判断逻辑嵌入代码”，它不是一个庞大的系统工程,而是几个关键点：

1. 选对数据结构：用String存百分比，用Set存白名单,用Hash存版本号。
2. 写好判断逻辑：在业务代码的关键入口处,加上访问Redis的判断。
3. 准备好回滚方案：确保数据兼容,并知道如何快速关闭开关。

这样做下来，你会发现灰度发布并没有想象中那么难，用Redis可以非常灵活、低成本地实现,让你的版本迭代更加安全可控。