
大家好，我是晚安code。
关注功能高并发有多难扛？（2026 年 8 月实测，适用于 Redis 6.0+ / RocketMQ 4.9+）这次我把整套「Redis 缓冲 + ZSet 存关系 + Lua 保原子 + MQ 异步落库 + 令牌桶削峰」的方案完整写出来，你照着这套思路做高并发设计，能少走我踩过的弯路。
## 一、直接写库，关注接口为什么扛不住

先说结论：**关注功能的高并发瓶颈，从来不在功能本身，而在你把高频写操作直接怼给了数据库。**
关注这个动作拆开看，一次请求至少要干三件事：往关系表插入一条记录、给对方的粉丝数 +1、给自己维护的关注列表加一个成员。很多项目第一版就是这么干的——一个事务里同步写完这三步。用户量一上来，问题全暴露了：
1. 1. 关系表频繁 insert，索引不断膨胀，写入越来越慢；
2. 2. 高并发下「插入 + 计数」不是原子的，粉丝数可能对不上账；
3. 3. 数据库 IO 是有上限的，瞬时洪峰一来直接打穿。

我在见到的经典事故，就是「关注接口双写 Redis + DB」：请求来了先写 MySQL 再写 Redis，并发一上来，两边数据就开始打架——有人取关成功了，Redis 里关系还在；有人关注重复提交，计数翻倍。![image](https://developer.qcloudimg.com/http-save/yehe-12591818/250b780e5e5c2bed0f5988cf77322cc8.webp)说白了，**关系数据本身不难存，难的是让数据库别被高频写压垮**。所以整套方案的核心思路只有一个：把「高频写」前置到 Redis，用 MQ 把落库这件事切成异步，数据库只吃它扛得住的量。
## 二、Redis 缓冲层：把关系放进 ZSet

**Redis ZSet（Sorted Set，有序集合）**：Redis 的一种数据结构，每个成员带一个 score 分值，成员按 score 自动排序。你可以理解为「带时间戳的收藏夹」——既能去重判断存没存过，又能按时间倒序翻页。
关注关系选 ZSet 而不是 Set，就一个原因：**关注列表天然需要按时间排序**。「最近关注了谁」是社交产品里最常见的查询，Set 只能存成员、排不了序，ZSet 用关注时间当 score，`ZRANGE` 一查就是按时间排好的列表。
我这里的存储模型是双向两份：
```

    
    
    
  following:{用户ID}&nbsp;&nbsp;&nbsp;&nbsp;member=被关注人ID，score=关注时间戳
follower:{用户ID}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;member=粉丝ID，score=关注时间戳
```关注时间做 score，取出来天然就是一条时间线，就像朋友圈按发布时间排。注意看这张概念图里的时间圆点——score 就是那条看不见的排序轨道：
![ZSet 里 score 是排序轨道，时间戳当 score 就能按时间查](https://developer.qcloudimg.com/http-save/yehe-12591818/5ce0458381b59b2aad30c74cf7be11a0.png)ZSet 里 score 是排序轨道，时间戳当 score 就能按时间查这样设计的好处是：
- • **插入高效**：`ZADD` 复杂度 O(log N)，时间戳做 score，天然有序；
- • **查询高效**：`ZRANGE` 分页查关注/粉丝列表、`ZSCORE` 判断是否已关注，都是毫秒级；
- • **取关干净**：`ZREM` 一条命令删掉关系，两个 key 一起维护。

![关注功能高并发架构图：请求进入 Redis 缓冲层，Lua 原子更新 ZSet，异步发送 MQ 由消费端令牌桶限流后落库](https://developer.qcloudimg.com/http-save/yehe-12591818/2f99e98852accc2b198a3efc7fd02dbe.png)关注功能高并发架构图：请求进入 Redis 缓冲层，Lua 原子更新 ZSet，异步发送 MQ 由消费端令牌桶限流后落库上面这张图就是完整链路：关注接口收到请求 → Lua 脚本原子更新 Redis → 发 MQ → 消费者令牌桶限流 → 异步落库。下面逐个环节拆。
## 三、Lua 脚本：高并发下 Redis 更新也要原子

**Lua 脚本**：Redis 内置的脚本语言，脚本会整段在 Redis 服务端原子执行——执行期间不会被其他命令插入。你可以理解为「Redis 内的一次性原子事务」。
很多人以为写了 Redis 就万事大吉，其实**高并发下 Redis 的「检查 + 更新」也必须用 Lua 串成一步**。看这段伪代码，是不是很眼熟：
```

    
    
    
  --&nbsp;关注：判断&nbsp;+&nbsp;插入&nbsp;+&nbsp;计数，三条命令
local&nbsp;exists&nbsp;=&nbsp;redis.call('zscore',&nbsp;KEYS[1],&nbsp;ARGV[1])
if&nbsp;exists&nbsp;then&nbsp;return&nbsp;1&nbsp;end&nbsp;&nbsp;--&nbsp;已关注
redis.call('zadd',&nbsp;KEYS[1],&nbsp;ARGV[2],&nbsp;ARGV[1])
redis.call('hincrby',&nbsp;'follow:count',&nbsp;ARGV[1],&nbsp;1)
return&nbsp;0
```如果这三步分开执行，并发下就会出问题：两个请求同时判断「没关注」，然后各插一次、计数加两次。我在生产环境就踩过这个坑——上线当天关注数虚高，排查半天发现就是计数器被并发叠加了。![image](https://developer.qcloudimg.com/http-save/yehe-12591818/0d8c5914c42e3bf8b22400a0024dcad2.webp)用 Lua 把「判断是否已关注 → 插入 ZSet → 更新计数」合并成一步，Redis 单线程保证整段脚本不会被打断，**原子性天然解决**。关注和取关各写一个脚本，`eval` 一次调用就完成，性能比拆分命令还好。
这个「合并成一步」就是 Lua 原子性的精髓——三条散落的命令，被串成一把钥匙上的三个齿，要么一起动，要么都不动：
![Lua 脚本 = 把「判断、更新、计数」锁进一把钥匙，原子完成](https://developer.qcloudimg.com/http-save/yehe-12591818/e6fcda2a9c69680fc33e06de4a8bfa35.png)Lua 脚本 = 把「判断、更新、计数」锁进一把钥匙，原子完成## 四、发 MQ 异步落库：打 Tag 精确消费

**MQ（Message Queue，消息队列）**：一个中转消息的中间件，生产者发消息、消费者异步取消息，两边解耦。你可以理解为「业务之间递纸条的收发室」——不是当面交接，而是放进信箱异步处理。
Redis 只是缓冲层，不是持久层。**关系最终要落到数据库，但绝不能同步落**。正确做法是：Redis 更新成功后，立即发一条消息到 MQ，接口直接返回「关注成功」，剩下的落库交给消费者慢慢做。
这里有个细节值得展开——**发消息要打 Tag**。以 RocketMQ 为例，同一个 Topic 下按业务场景打不同标签：
```

    
    
    
  //&nbsp;生产端：关注/取关打不同&nbsp;Tag
Message&nbsp;msg&nbsp;=&nbsp;new&nbsp;Message(
&nbsp;&nbsp;&nbsp;&nbsp;"FOLLOW_TOPIC",&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;Topic
&nbsp;&nbsp;&nbsp;&nbsp;isFollow&nbsp;?&nbsp;"FOLLOW"&nbsp;:&nbsp;"UNFOLLOW",&nbsp;&nbsp;//&nbsp;Tag&nbsp;标签
&nbsp;&nbsp;&nbsp;&nbsp;userId&nbsp;+&nbsp;":"&nbsp;+&nbsp;targetId&nbsp;&nbsp;&nbsp;//&nbsp;业务数据
);
producer.send(msg);
```消费者订阅时按 Tag 过滤，只处理自己关心的消息：
```

    
    
    
  consumer.subscribe("FOLLOW_TOPIC",&nbsp;MessageSelector.byTag("FOLLOW&nbsp;||&nbsp;UNFOLLOW"));
```为什么要打 Tag？三个理由：**消费端能精确过滤**，不用消费全部消息再业务层判断；**方便分场景限流**，关注和取关可以配置不同的处理速率；**排查问题时定位快**，一看 Tag 就知道这条消息是什么业务。
**消息队列削峰**的核心价值就在这：接口侧把瞬时洪峰甩给 MQ，MQ 像一个水库，把洪峰的水蓄住，再按下游能承受的流速放出去。这就是常说的削峰填谷。
你看这张图就明白了——上面是劈头盖脸的暴雨（洪峰），下面是稳稳的一条小溪（落库速率），中间的 MQ 就是那个水库闸门：
![MQ 是水库，接口是暴雨，数据库是小溪——削峰填谷全靠这个闸门](https://developer.qcloudimg.com/http-save/yehe-12591818/0069b36365b096f82656b368d7104587.png)MQ 是水库，接口是暴雨，数据库是小溪——削峰填谷全靠这个闸门>**可能有人会问：Redis 更新成功了，MQ 消息发了，万一落库失败，数据不就对不上了？**
放心，这正是异步方案必须配的兜底。消费者落库用「主键幂等」——`follow` 表用 (user_id, target_id) 建唯一索引，重复消息 insert 时冲突直接跳过；再加一层死信队列，重试几次还失败的进 DLQ 人工排查。Redis 作为读缓存，可以接受偶尔重建，数据库这一层最终一致就行。

## 五、消费端令牌桶：数据库只吃它吃得下的量

**令牌桶（Token Bucket）**：一种限流算法，系统按固定速率往桶里放令牌，请求要先拿到令牌才能处理，桶满了就丢弃新令牌。你可以理解为「景区按固定频率放人进门的闸机」——人再多，进场的速率是定死的。
到消费端这一步，MQ 里已经堆了一大堆落库消息。如果消费者一股脑全拉出来写库，等于把洪峰从接口侧平移到了数据库侧，前面白干了。**所以消费端必须限速，这就是令牌桶上场的地方**。
我用的是 Redis 实现的分布式令牌桶：消费者每处理一条消息前，先 `eval` 一个 Lua 脚本拿令牌，拿到才继续，拿不到就稍等重试。核心脚本长这样：
```

    
    
    
  local&nbsp;bucket&nbsp;=&nbsp;'token:'&nbsp;..&nbsp;KEYS[1]&nbsp;&nbsp;&nbsp;--&nbsp;桶名
local&nbsp;tokens&nbsp;=&nbsp;tonumber(redis.call('get',&nbsp;bucket)&nbsp;or&nbsp;'0')
local&nbsp;capacity&nbsp;=&nbsp;tonumber(ARGV[1])&nbsp;&nbsp;&nbsp;--&nbsp;桶容量
if&nbsp;tokens&nbsp;>=&nbsp;1&nbsp;then
&nbsp;&nbsp;&nbsp;&nbsp;redis.call('decr',&nbsp;bucket)
&nbsp;&nbsp;&nbsp;&nbsp;return&nbsp;1&nbsp;&nbsp;&nbsp;--&nbsp;拿到令牌
end
return&nbsp;0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;--&nbsp;桶空，稍后再试
```配合一个定时任务按固定速率补令牌，消费速率就被稳稳控住了。数据库的写入 TPS 从「不可控的洪峰」变成「恒定的 500」，压力直接可量化。

        
          
|限流方案|是否支持突发|实现复杂度|适用场景|
|:-:|:-:|:-:|:-:|
|固定窗口|否，瞬间可能双倍|低|粗粒度限流|
|滑动窗口|部分|中|要求平滑|
|令牌桶|是，桶存突发量|中|削峰填谷、消费端限速|
|漏桶|否，恒定速率|低|强制匀速|

        
      对比下来，**消费端削峰选令牌桶最合适**：平时流量平稳时桶是满的、不排队；活动洪峰时桶蓄不住的部分直接丢弃或排队，数据库永远只看到固定速率。我实际调参时，桶容量按「数据库能承受的最大 TPS × 3」设置，既给了突发余量，又不至于把库打爆。
## FAQ

>**可能有人会问：为什么关注功能不能先写数据库再删缓存？**
顺序反过来会带来缓存与数据库的短暂不一致：删缓存和写库之间一旦有并发读，读到的就是旧缓存。异步落库 + Redis 兜底的方案里，Redis 是读的主来源，写库是后台补账，只要幂等键兜底，最终一致就够用。

## 六、总结：这套方案的核心思路

回顾一下整套链路：**关注功能高并发设计，核心就一句话——Redis 当缓冲层挡住高频写，ZSet 存关系保排序，Lua 脚本把判断和更新合成原子一步，MQ 异步承接落库并打 Tag 分场景，消费端令牌桶把数据库压在恒定速率**。五个环节各司其职，缺一个都容易在洪峰时出岔子。
以我踩过坑的经验，新手最容易漏的是第二环——以为 Redis 天然原子，结果计数器被并发打爆。**原子性不会因为数据进了 Redis 就自动有，该用 Lua 还得用**。
关注接口高并发设计自查清单：
1. 1. **Redis 缓冲**：关系写入全部前置 Redis；
2. 2. **ZSet 双向存储**：following / follower 各一份；
3. 3. **Lua 原子**：判断 + 插入 + 计数合并一个脚本；
4. 4. **MQ 异步**：发消息打 Tag，接口立即返回；
5. 5. **令牌桶限流**：消费端限速落库，保护数据库。

这套方案同样适用于点赞、收藏、订阅这类「高频写关系」功能——把场景换一下，思路是通的。这套关注功能高并发方案在你那边落地时，建议先把量级估清楚：预估并发 1 万以内，简化到「Redis + 定时任务」也能扛；真正到了活动级洪峰，再上 MQ + 令牌桶不迟。如果想深入，推荐看 Redis 官方文档的 Lua 脚本章节，和 RocketMQ 的消息过滤文档（搜：Redis eval 文档、RocketMQ Tag 过滤）。


----
我是晚安code，持续分享编程干货。觉得有用的话记得点赞收藏和关注~也欢迎在评论区聊聊：你在做关注、点赞这类高并发功能时，遇到过哪些「数据对不上账」的坑？

大家好，我是晚安code。关注功能高并发有多难扛？（2026 年 8 月实测，适用于 Redis 6.0+ / RocketMQ 4.9+）这次我把整套「Redis 缓冲 + ZSet 存关系 + Lua 保原子 + MQ 异步落库 + 令牌桶削峰」的方案完整写出来，你照着这套思路做高并发设计，能少走我踩过的弯路。

关注功能高并发怎么扛？Redis ZSet + Lua + MQ 异步落库一整套

关注功能高并发怎么设计？本文拆解 Redis ZSet 存关系、Lua 保原子性、MQ 异步落库、消费端令牌桶削峰四环，抗住瞬间洪峰。

架构设计

Redis缓冲+ZSet存关系+Lua保原子+MQ异步落库+令牌桶削峰，这套高并发关注功能方案有效解决数据库写入瓶颈。通过Redis ZSet存储双向关系，Lua脚本保证原子操作，MQ异步削峰，令牌桶限流保护数据库，实现高性能关注功能设计。适用于社交平台关注、点赞等高并发场景。

消息队列

数据结构

代码解释

中间件

数据库

MySQL

Redis

腾讯云数据库特惠，新用户首单0.5折起


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

关注功能高并发怎么扛？Redis ZSet + Lua + MQ 异步落库一整套-腾讯云开发者社区-腾讯云

关注功能高并发怎么扛？Redis ZSet + Lua + MQ 异步落库一整套

关注功能高并发怎么扛？Redis ZSet + Lua + MQ 异步落库一整套

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐