1. 从一次“点赞风暴”说起：为什么Redis是首选？
那天下午，系统监控突然报警，CPU和网络流量瞬间飙升。我一看，原来是我们运营策划的一个热门活动上线了，一条爆款内容在短短几分钟内涌入了海量的点赞请求。后台数据库的连接池瞬间被打满，响应时间从毫秒级飙升到十几秒，页面直接卡死。这场景，估计很多做内容社区或者社交产品的朋友都遇到过。用户点一下“赞”，看似简单的操作，背后却是一场对后端系统并发处理能力的极限考验。
为什么传统的数据库（比如MySQL）扛不住这种瞬间的“点赞风暴”呢？核心原因在于磁盘I/O和锁机制。每次点赞，你至少需要：1. 查询当前用户是否已点赞（避免重复）；2. 更新帖子的点赞计数；3. 记录点赞关系。在千万级并发下，大量的磁盘写入、行锁竞争会让数据库迅速成为瓶颈。这时候，Redis的优势就凸显出来了。它基于内存操作，速度极快，单机就能轻松达到每秒数万甚至十万级的QPS（每秒查询率）。更重要的是，它提供了丰富的数据结构，比如我们马上要详细聊的Set和Bitmap，天生就适合实现“点赞”这种需要快速判断“存在与否”和“计数”的场景。
所以，当面试官问你“如何设计高并发点赞系统”时，他其实是在考察你对高性能、高可用架构的理解，以及你是否能跳出CRUD的思维，利用合适的工具解决实际问题。接下来，我就结合自己踩过的坑和优化经验，带你从零开始，设计一个能扛住千万级瞬时点赞的Redis系统。
2. 基石：Redis点赞的两种核心数据结构与实战
选对了数据结构，就成功了一半。在Redis里，实现点赞主要有两大“神器”：Set集合和Bitmap位图。它们各有优劣，用对了场景，性能天差地别。
2.1 Set集合：简单直观的“大众选择”
Set是很多同学首先想到的方案，因为它太符合直觉了：一个帖子对应一个Set，里面存放所有点赞用户的ID。这就像是一个签到的花名册。
具体怎么操作呢？假设帖子ID是post:1001，用户ID是user:123。
- 点赞：
SADD like:post:1001 user:123 - 取消点赞：
SREM like:post:1001 user:123 - 检查是否点赞：
SISMEMBER like:post:1001 user:123 - 获取点赞总数：
SCARD like:post:1001 - 获取点赞列表：
SMEMBERS like:post:1001
代码写起来非常清爽。我在早期项目里用的就是这套方案，开发速度飞快。但是，当某个明星发帖，点赞量直奔百万而去时，问题来了。Redis的Set底层有两种实现：当元素全是整数且数量少（默认512个）时，用更省内存的“整数集合”；否则就用“哈希表”。一旦超过阈值转成哈希表，每个用户ID（即使我们存的数字）都会作为一个独立的键值对来存储，内存消耗就开始线性增长。一个百万级点赞的Set，占用内存可能达到几十MB，如果这样的热门帖子多了，Redis内存很快告急。
那么，Set方案就一无是处了吗？当然不是。它非常适合点赞量可控的中小型场景，或者需要精确获取点赞用户列表的功能。它的操作都是O(1)时间复杂度，在数据量不大时，性能非常稳定。我给你的建议是：如果你的产品预期不会有极端热帖，或者你能通过分库分表将热度分散，Set依然是首选，因为它简单、功能全面。
2.2 Bitmap位图：应对“顶流”的终极武器
当Set遇到内存瓶颈时，就该Bitmap闪亮登场了。它的思想非常巧妙：我们不存储具体的用户ID，而是用一个很长的二进制位数组来表示。数组的每一个“位”（bit）的下标，就代表一个用户ID。如果这个位是1，表示该用户点了赞；是0，则表示没点。
这听起来有点抽象，我们来看实战。假设我们的用户ID是纯数字，并且相对连续（如果不连续，可以用一层映射关系，这里先讲原理）。用户user:123456给帖子post:1001点赞，我们只需要执行：
SETBIT praise:post:1001 123456 1看，命令变成了SETBIT。这里的praise:post:1001是键名，123456是偏移量（offset），也就是用户ID的数字部分，1表示设置为赞。取消点赞呢？就是把这位设为0：SETBIT praise:post:1001 123456 0。检查用户是否点赞，使用GETBIT praise:post:1001 123456，返回1就是点了。统计总点赞数，使用BITCOUNT praise:post:1001，这个命令会高效地统计出所有为1的位的数量。
Bitmap的优势简直是碾压级的：
- 极致节省内存：这是最大的杀手锏。每个用户只占1个比特（bit）！8个比特才1个字节。理论上，记录1千万用户的点赞状态，只需要大约
10,000,000 / 8 / 1024 / 1024 ≈ 1.19 MB的内存。而用Set，可能早就上百MB了。 - 操作性能极高：
SETBIT、GETBIT、BITCOUNT都是O(1)操作，速度极快，而且这些位操作在CPU层面是原子性的，天然适合高并发。 - 支持复杂查询：Bitmap还支持
BITOP（位运算），可以轻松实现“共同点赞”等功能。例如，找出同时点赞了帖子A和帖子B的用户，只需要BITOP AND result_key praise:post:A praise:post:B，然后对result_key做BITCOUNT即可。
当然，Bitmap也有它的“坑”：
- 用户ID必须是数字或可映射为数字：如果你的用户ID是UUID字符串，就需要一个额外的字典来映射，会引入复杂度。
- 稀疏位图问题：如果用户ID范围很大（比如从1到10亿），但实际点赞用户只有1万个，Bitmap仍然会分配10亿位的空间，这就不划算了。不过Redis的Bitmap是动态扩展的，只有被设置的位才会实际占用内存，但键的偏移量设置得非常大时，可能会瞬间分配较大内存。
- 无法直接获取点赞用户列表：
BITCOUNT可以知道总数，但想知道具体是谁点了赞，就需要遍历所有位，这在数据量大时是不可行的。所以Bitmap方案通常只关心“总数”和“某人是否点赞”。
我的经验是：对于点赞量可能突破百万、千万的“热点内容”，必须使用Bitmap。这是用空间换时间和稳定性的经典案例。在实际架构中，我们甚至可以“双轨制”：普通内容用Set，系统检测到某个内容点赞增速异常，达到阈值后，后台任务自动将其数据从Set迁移到Bitmap，实现平滑过渡。
3. 架构演进：从单点到高可用集群的设计之路
理解了核心数据结构，我们来看看系统整体怎么搭。架构不是一蹴而就的，它随着业务压力增长而不断演进。
3.1 第一阶段：单机Redis与数据持久化
项目初期，流量不大，一台Redis服务器足够了。但千万别忘了，Redis是内存数据库，机器宕机数据就没了。所以，持久化是生命线。
- RDB（快照）：定时（比如每小时）把内存数据全量备份到磁盘。恢复快，但可能会丢失最后一次快照之后的数据。
- AOF（追加日志）：记录每一个写操作命令，重启时重新执行一遍。数据完整性高，但文件会越来越大，恢复速度慢。
我个人的配置习惯是：两者同时开启。用AOF来保证数据安全，每秒同步一次（appendfsync everysec），在性能和安全性间取得平衡。同时，定期（比如每天）用RDB做一次冷备份，便于历史归档和快速恢复。这样即使Redis进程挂掉，重启后也能从AOF文件中恢复出几乎所有的点赞数据。
3.2 第二阶段：主从复制与读写分离
当读请求开始增多（比如频繁查询点赞总数），单机CPU有点吃紧时，就该上主从复制了。部署一台或多台从库（Slave），主库（Master）负责写（点赞/取消赞），从库负责读（查总数、查是否点赞）。这样就把读写压力分开了。
这里有个细节要注意：Redis复制是异步的。用户点赞后，立刻去从库查，可能会查不到刚点的赞，这就是“主从延迟”。对于点赞这种场景，通常采用“写主读主”的一致性策略，即用户给自己点赞后，查询自己是否点赞的请求也走主库，确保立刻可见。而对于其他用户查看点赞总数这种对实时性要求稍低的请求，可以走从库。这需要在业务代码里做简单的路由。
3.3 第三阶段：Redis Cluster应对千万级风暴
真正的挑战是“千万级瞬时点赞”。这意味着一秒钟内可能有几十万甚至上百万的写请求涌向同一个帖子。单机Redis的网卡、CPU、内存都会是瓶颈。这时，必须祭出Redis Cluster（集群模式）。
Redis Cluster的核心思想是分片（Sharding）。它将整个数据集自动划分到16384个哈希槽（slot）中，每个节点负责一部分槽。对于我们的点赞系统，关键问题在于：如何让同一个热点帖子的海量请求，不要全打到一个节点上？
这里就需要智慧了。如果我们用帖子ID作为键，比如praise:post:1001，Cluster会根据这个键计算槽位，那么所有对这个帖子的请求都会落到同一个节点，这就成了“热点键”，那个节点可能被打爆。
解决方案是：对热点键进行人工分片。例如，我们可以不直接用帖子ID，而是构造一个复合键：praise:post:1001:shard_{N}。其中N可以是0到7（假设我们分8片）。当用户点赞时，我们根据用户ID的哈希值对8取模，决定写到哪个分片键里。查询总点赞数时，我们需要对praise:post:1001:shard_0到praise:post:1001:shard_7这8个键分别执行BITCOUNT，然后把结果相加。虽然读操作变复杂了，但成功地将一个热点帖子的写压力分散到了集群的多个节点上，实现了水平扩展。
这个方案我在一个短视频点赞场景中实际用过。当时一个热门视频的点赞QPS峰值超过了50万，通过分成16个分片，平稳地扛住了流量，集群的各个节点负载非常均衡。
4. 实战优化：除了Redis，我们还需要什么？
有了强大的Redis集群，是不是就高枕无忧了？还不行。系统设计要有纵深，不能把所有鸡蛋放在一个篮子里。我们需要一套组合拳来保证万无一失。
4.1 第一道防线：异步化与消息队列削峰
瞬时流量可能超过Redis集群本身的设计容量。我们的思路是：绝不把实时流量直接打满数据库或缓存。在业务层和Redis之间，引入一个消息队列（如Kafka、RocketMQ）。
当用户点击点赞按钮时，前端立刻返回“点赞成功”，给用户即时反馈。同时，后端只是将这个点赞事件（用户ID、帖子ID、操作时间）作为一个消息，快速写入消息队列就返回。然后，由一组独立的消费者服务，以可控的速度（比如每秒处理1万条）从队列中取出消息，再去执行真正的RedisSETBIT操作。
这样做的好处是：削峰填谷。无论前端洪峰多高，都被消息队列这个“蓄水池”接住了，下游的Redis集群按照自己的处理能力匀速消费，永远不会被冲垮。即使Redis短暂抖动或扩容，消息也会堆积在队列里，不会丢失。这是应对“千万级瞬时涌入”最核心的架构思想之一。
4.2 第二道防线：缓存与数据库的最终一致性
Redis是缓存，数据可能丢失（尽管我们做了持久化和集群）。我们需要一个最终落地的“真相源”，通常是MySQL。但绝不能直接写MySQL，否则又会回到磁盘I/O的瓶颈。
我们的数据流应该是：用户 -> 消息队列 -> Redis（缓存+实时计数） -> 异步同步到MySQL。 消费者服务在更新Redis后，可以将同一条消息再写入另一个“数据同步队列”。另一个同步服务消费这个队列，将点赞关系批量写入MySQL。这里的关键是批量插入，比如攒够1000条点赞记录，用一个INSERT ... VALUES (...), (...), ...语句写入，这比单条插入效率高出几个数量级。
这就带来了缓存与数据库的一致性问题。对于点赞这种场景，我们通常采用“最终一致性”策略。允许在极端情况下（如同步服务延迟），用户从MySQL查询的历史点赞列表有短暂滞后，但通过Redis查询的实时状态总是准确的。这个权衡在绝大多数社交产品中都是可以接受的。
4.3 第三道防线：降级、限流与熔断
即使做了这么多，我们还要为最坏情况做准备。
- 降级：在监控到Redis集群响应时间飙升或不可用时，可以暂时将点赞功能降级。比如，点击点赞后，提示“服务繁忙，已收到您的爱心”，并将请求记录到本地文件或另一个降级存储，待服务恢复后补偿。这总比整个页面卡死要好。
- 限流：在接入层（如Nginx）或应用层，对点赞接口进行限流。例如，同一个IP每秒最多只能点10个赞，或者对帖子ID进行频率限制，防止恶意刷赞。这能挡住一部分异常流量。
- 熔断：当调用Redis连续失败多次后，自动熔断，快速失败，避免线程被长时间占用，拖垮整个应用。
这些措施共同构成了系统的弹性，让它能在风暴中存活下来。
5. 避坑指南：那些年我踩过的“雷”
理论说再多，不如踩一次坑。分享几个让我记忆犹新的真实问题。
第一个坑：BITCOUNT的性能陷阱。早期我们有一个榜单功能，需要实时计算上百个热门帖子的点赞数。代码里写了个循环，对每个帖子键执行一次BITCOUNT。平时没问题，但在晚高峰时，这个循环耗时突然变长，导致接口超时。原因是，BITCOUNT在计数时，如果位图很大，它需要遍历所有被设置为1的位，虽然算法高效，但计算一个百万级点赞的位图，仍需要毫秒级时间。连续计算上百个，总时间就不可忽视了。优化方案是：对于需要频繁读取的点赞总数，不要每次都实时计算。可以在点赞/取消时，用一个单独的计数器（使用Redis的INCR/DECR命令）来维护总数，BITCOUNT仅用于定期校准（比如每天一次）。这就是典型的“用空间换时间”，一个帖子多存一个计数器键，换来的是O(1)的查询性能。
第二个坑：热点Key的缓存击穿。这不是点赞独有的，但点赞场景很典型。当某个帖子第一次被大量访问，查询其点赞数的请求会同时到达Redis。如果这个键刚好过期或不存在，这些请求就会全部穿透到数据库。虽然我们用Bitmap后不太可能查数据库，但如果是查询帖子详情（包含点赞数）的复合接口，就可能发生。解决方案是使用互斥锁（分布式锁）。第一个发现缓存为空的请求，去加锁，然后负责加载数据到缓存；其他请求等待或返回默认值。在Java中，可以用Redisson客户端方便地实现。
第三个坑：内存碎片与BigKey。即使使用Bitmap，如果管理不当也会产生大Key。比如，我们错误地用一个Bitmap键来记录全平台所有用户的全局点赞状态（偏移量设得极大），这个键就会巨大无比，在Redis内存分配和迁移时非常麻烦。一定要避免产生BigKey。坚持我们的分片原则，一个键只负责一个帖子，甚至一个帖子的一个分片。同时，定期检查Redis内存碎片率（info memory），如果过高，可以考虑在业务低峰期重启实例或使用MEMORY PURGE（Redis 4.0+）来清理。
设计一个高并发点赞系统，就像在搭建一座水利工程。Redis是你的超级水库和高速水渠，数据结构是不同规格的管道，消息队列是调节流量的闸门，数据库是最终的蓄水湖泊，而降级限流则是泄洪道。每一个环节都需要精心设计和联动测试。没有一劳永逸的银弹，只有对业务流量深刻理解后，不断迭代演进的架构。希望这些从实战中总结的经验，能让你在下一次“点赞风暴”来临前，胸有成竹。
