Redis搞定流量分发其实没那么难，聊聊那些实用技巧和思路

综合自多个技术社区博客及开发者实践经验分享）

Redis搞定流量分发其实没那么难,聊聊那些实用技巧和思路

一想到流量分发,很多人脑子里可能立刻冒出Nginx、HAProxy这些专业的负载均衡器，确实，它们是这方面的专家，但有时候，我们的场景没那么复杂，或者我们希望用一种更灵活、更能和业务逻辑紧密结合的方式来实现分流，这时候，Redis就能派上大用场了，它就像一个超级快的“智能开关”，帮我们轻松搞定很多分发逻辑。

核心思路：把Redis当作一个“指挥中心”

你可以把Redis想象成一个所有服务器都能快速访问的公共小黑板,我们需要分发的规则、用户的身份信息、服务器的状态等等，都写在这块小黑板上，当有新的请求过来时，业务服务器不去问复杂的配置中心，而是直接快速地问Redis：“嘿，这个用户该去哪台服务器？” Redis瞬间给出答案，服务器就按照这个答案把流量导过去，整个过程非常快，因为Redis就擅长干这种高速读写的活儿。

几个接地气的实用技巧

1. 用简单的Key-Value做灰度发布 假设我们做了一个新功能，只想让部分用户先体验一下，怎么做呢？我们可以在Redis里设置一个Key，比如叫 new_feature_whitelist，它的Value就是一个用户ID的集合。 当一个用户请求过来时，我们的程序就去Redis里查一下：SISMEMBER new_feature_whitelist 当前用户ID，如果返回1，说明这个用户在名单里，就把他引导到有新功能的服务器集群；如果返回0，那就走老的流程。 这样做的好处是特别灵活，产品经理突然说“再给我加三个测试用户”，你根本不用重新发布代码，直接在Redis里往那个集合里塞三个ID就行了，立马生效。

2. 用Hash来管理服务器权重和状态 如果我们的流量分发不是简单的“是或否”，而是要根据服务器的处理能力来分配（比如A服务器性能好，承担60%的流量，B服务器承担40%），Redis的Hash结构就很好用。 我们可以建立一个Hash，Key叫 server_weights，里面的Field就是服务器编号（如server_1, server_2），Value就是它的当前权重。 分发的时候，程序从Redis取出所有的权重值，然后根据一定的算法（比如按权重随机）选出一台服务器，更重要的是，我们还可以实时更新这个Hash，比如运维同学发现server_2好像有点卡，可以手动把它的权重从40调低到20，流量就会自动减少，实现简单的熔断和降级。

3. 用自增计数器做轮询或限流 Redis的 INCR 命令能让一个Key的值自动加1，而且保证是原子性的（不会多人同时操作出错），这简直是做简单轮询和限流的神器。

   • 简单轮询：比如有三台服务器，我们设置一个Key叫 request_counter，每来一个请求，就执行 INCR request_counter，然后把这个计数器的值对3取余（%3），得到0、1或2，分别对应三台服务器，这样就实现了一个非常公平的轮询分发。
   • 简易限流：比如想限制某个API一分钟内只能被一个用户访问60次，Key可以设计成 rate_limit:user_id:当前分钟数，每次请求来了就对这个Key执行 INCR，如果返回的值大于60，就直接拒绝请求，同时给这个Key设置一个60秒的过期时间，这样下一分钟又是新的计数，这就实现了时间窗口内的流量控制。

4. 用有序集合（Sorted Set）实现优先级队列 有些请求有VIP待遇，需要优先处理，我们可以用一个有序集合来做优先级队列，每个请求进来，根据它的优先级（比如VIP用户是10，普通用户是1）作为分数（Score）存入Sorted Set，请求内容本身作为Member。 工作服务器从一个端口拉取任务时，不是简单地取最早的任务，而是用 ZRANGEBYSCORE 命令先取分数最高的（优先级最高的）任务来处理，这样就保证了重要的流量能被优先分发和处理。

需要注意的几个坑

虽然Redis很强大,但用它做流量分发也不是银弹，有几个地方得留心：

• Redis不能宕机：这个指挥中心一旦挂了，整个分发系统就乱套了，所以一定要做Redis的高可用方案，比如主从复制、哨兵模式或者集群模式，确保它足够可靠。
• 网络延迟：虽然Redis快，但如果你的业务服务器和Redis机房离得太远，网络延迟也会成为瓶颈，尽量保证它们在同一个内网里。
• 数据一致性：如果有多个人同时在修改Redis里的分发规则（比如同时调整权重），可能会产生冲突，对于非常重要的配置，要考虑用Redis的分布式锁（如Redlock）来保证同时只有一个人能改。

Redis在流量分发上最大的优势就是快和灵活，它特别适合那些业务逻辑复杂、需要频繁调整规则、或者不希望引入重型中间件的场景，下次当你遇到分流需求时，不妨先想想：用我熟悉的Redis，是不是就能优雅地解决了？很多时候，答案都是肯定的。