1. 点赞流量的残酷真相均值没有意义突刺才是生死线先说一个我亲手踩过的场景。某天下午运营临时推了一条活动内容数据在二十分钟内直接冲上了推荐榜我当时负责的内容系统里点赞写接口的耗时就从这个时间点开始飙升紧接着报警群刷了满屏的延迟告警。事后复盘时拉出监控曲线那二十分钟的点赞QPS大概是我们日常峰值的十二倍而这段流量来之前没有任何预兆因为普通的活动预告根本预测不到这种忽然爆发的内容会被推到多少人面前。这就是百万级点赞系统和普通后台管理系统最本质的区别你面对的流量不是一个平均速度而是一个又一个持续时间不长的尖峰。很多人在设计系统时习惯用日均请求量除以86400来估QPS这套算法放在点赞场景里基本是自欺欺人。假设某天有一百万次点赞操作平均下来每秒才11次这个数字会让任何有经验的程序员都觉得随便一台机器就扛得住但实际发生的情况是这些操作集中在一两个小时内涌入而且又叠在某个爆款内容上面真实峰值可能是平均值的几十上百倍。我后来跟团队内部做分享时经常用一句话概括点赞系统必须为最坏的一分钟设计而不是为平均的一天设计。为什么因为点赞这个动作天然是传染的一个人点了赞他的朋友看到又有更多人去点内容的热度会自我强化。尤其是当一条内容被投放到巨大流量池里的时候第一批点赞带来的数据反馈又会让系统加大推荐力度于是流量呈滚雪球式增长。这种场景下任何一个环节只要在峰值时出现了瓶颈造成的后果不是请求变慢而是整条链路的雪崩。所以在真正动手设计之前我们首先要做的是把流量模型拆明白。点赞场景有几个关键参数“读多写多但写操作极轻”“热点集中明显”“取消点赞与重复点击并存”“对实时性要求高但对强一致性要求低”。这最后一条是整个方案的命脉很多人放不下数据库里那张表必须实时准确的执念才导致后面每一步都走得很痛苦。我在这篇实战拆解里会带你重新审视这条链路从缓存、幂等、异步落库到容量评估把百万级点赞系统拆成一个可以在真实环境落地的方案。2. 一条点赞请求的完整旅程从接入层到缓存层的四道关卡2.1 接入层不是简单的转发而是第一道防线先理清一次点赞操作从客户端出发后要经历什么。用户的点击进入接入层后首先要做的是最基础的参数校验和身份识别这个环节不复杂但绝对不可省略。我们要确认请求里携带了合法的用户标识、目标内容标识并且这个用户有对该内容执行操作的权限。在实际项目中这个所谓的权限校验往往不是技术问题而是业务规则问题比如某些内容禁止点赞、某些用户被限制互动等等。接入层的另一个重要职责是限流。点赞接口在最极端的突发情况下接入层看到的请求量可能远远超过后端能处理的数量级这时候我们不能让所有请求都打到下游去而是要像一个漏斗一样在入口先把多余的部分挡掉。我用的方案是基于令牌桶或者滑动窗口做的分布式限流阈值会按照用户维度和内容维度分别配置。用户维度的限流是为了防止有人短时间内疯狂点击导致的服务资源耗尽内容维度的限流则是防止某条爆款内容把整个集群的资源都吸走。这里有一个容易犯的错很多团队觉得限流就是超了就抛异常但客户端拿到异常后大概率会重试重试又会产生新一轮流量。比较稳妥的做法是限流后直接返回一个友好的降级响应比如操作太频繁了请稍后再试同时配合客户端做本地退避从而避免限流值和实际冲击值之间形成恶性循环。2.2 写请求为什么不能先去查数据库再做判断这是点赞系统设计里最核心的一个判断。你去看很多初版代码逻辑都是这样的先查数据库里有没有这条点赞记录有就取消没有就插入顺便更新内容表里的点赞数字段。这在日活只有几千人的时候毫无问题但一旦并发上来问题就来了。首先是数据库行锁竞争。假设同一个内容瞬间涌入十万个点赞请求内容表里那一行的点赞数字段会成为所有请求争抢的目标数据库行锁会让这些请求排队执行吞吐量直接断崖式下跌。其次是连接数打满。每一个点赞请求如果在数据库里做完整的读改写就必须持有一个数据库连接而在高强度并发下应用层持有的连接池很容易被全部占满后续所有请求都卡在获取连接上整个业务都会被拖垮。正确的做法是把计数和关系记录放到缓存层处理。我这里说的缓存层通常指Redis。Redis是单线程执行命令意味着它天然没有锁竞争问题而且它在内存里的读写速度非常快一秒钟支撑几万次简单读写完全是量级内的事。我们要做的事情就是把点赞这个操作的原子性交给Redis的Lua脚本来保证。我在项目中使用的核心逻辑大致是这样的对每一条内容维护一个Redis集合集合里存储所有点赞用户的ID同时维护一个计数器键。用户执行点赞时通过Lua脚本完成判断集合中是否存在该用户、不存在则加入集合并增加计数这一系列操作整个流程在Redis内原子执行不需要跨网络调用也不需要多步操作之间的时间窗口。-- like_script.lua 核心思路 -- KEYS[1] 点赞用户集合 key -- KEYS[2] 内容点赞计数 key -- ARGV[1] 用户ID local member_exists redis.call(SISMEMBER, KEYS[1], ARGV[1]) if member_exists 1 then return 0 -- 已点赞幂等返回 end redis.call(SADD, KEYS[1], ARGV[1]) redis.call(EXPIRE, KEYS[1], 172800) local count redis.call(INCR, KEYS[2]) return count同样的道理适用于取消点赞区别在于把SADD换成SREM、INCR换成DECR。这里有一点需要特别注意取消赞也要判断用户是否真的在集合里如果在则移除并递减如果不在则直接返回避免计数出现负数。2.3 键设计里的hash tag是很多人踩过却不说破的坑使用Redis集群时一个隐藏问题就是key的哈希槽分布。集群模式下Redis会把key按照哈希槽分配到不同节点如果你把用户ID和内容ID直接用字符串拼接成key那同一个内容的点赞用户集合key和计数key很可能被分到不同节点上Lua脚本跨节点执行会直接报错。绕开这个问题的正统做法是使用hash tag就是让key里包含花括号包起来的同一个标识比如都用{target_id}开头的key。这样Redis计算哈希槽时只取花括号里的内容相关key就会落在同一个节点上Lua脚本才能保证原子性。我见过不止一个团队在压测到一半的时候突然报CROSSSLOT Keys in request dont hash to the same slot然后一脸迷茫。这个错误诞生于并发量波峰的时候原因就是当时设计key时完全没考虑哈希槽。所以在这里重点提醒一句不要用纯用户ID拼内容ID拼日期这种自由散漫的key命名法后面的坑会埋得很深。缓存层写完后整个点赞动作的理想吞吐可以做到单节点上万QPS而这一切是在毫秒级延迟内完成的。但写完了Redis不等于万事大吉因为点赞关系数据和最终的计数最终还是要落库这部分我们到第五节详细展开。3. 双层缓存与热点内容保护怎么扛住一场瞬间流量爆炸3.1 计数读取为什么要走两层缓存点赞系统除了写操作之外占比更大的是读操作。当一个内容被展示在信息流里时它需要展示点赞数用户点进详情页时也需要看到点赞数运营后台要展示近期热门内容时还要按点赞数排序。这些读请求的规模和写请求完全不是一个数量级一条爆款内容的浏览用户可能是点赞用户的几十倍你总不能让它每次都穿透到Redis去拿计数更不用说打到数据库。我采用的方式是两层缓存。第一层是应用本地缓存通常放在业务进程内用来承接同一台机器内部大量重复的计数查询。第二层才是Redis分布式缓存存的是内容ID到点赞计数的映射。查询时先查本地缓存本地没有再到RedisRedis没有再回源到数据库这就是经典的Cache Aside模式。很多人在这个环节会问本地缓存和Redis缓存的内容一样吗不一样。两者的过期时间要刻意拉开差距。本地缓存设置的TTL非常短我一般控制在10到30秒它的作用是抵挡绝大多数瞬时重复查询而不是保证数据的实时性。Redis层的TTL可以稍微长一些比如3到5分钟避免每个请求都穿透到数据库。但即便是Redis这一层也不可能做到百分百准确因为点赞操作是实时的而缓存刷新存在天然延迟。这里要摆正一个观念对于点赞数这个场景业务容忍的误差窗口通常在几秒甚至几十秒级别没有人会因为看到这篇内容有12.8万赞而另一台设备上显示12.7万赞就认为是系统故障。所以本地缓存和Redis之间的短暂不一致是完全可以接受的只要最终数据是收敛的。3.2 热点内容击穿单点压力怎么打散双层缓存解决了常规流量下的读压力但解决不了热点击穿。什么是热点击穿当一个内容在Redis里的缓存恰好过期而同时有海量用户来查它的点赞数时所有请求都会同时穿透到数据库。数据库瞬间被打满轻则延迟飙升重则直接拒绝连接这就是缓存击穿。解决击穿的核心思路是把集中的压力打散。我常用的手段有两个。第一个是逻辑过期。缓存中不只是存value还会额外存一个过期时间比如逻辑过期时间设为一分钟。查询时发现逻辑过期并不会直接删掉旧值去数据库重新加载而是先返回旧值同时只让一个请求去数据库加载新值回填缓存。这种异步刷新策略在极端并发下依然能保持可用性缺点是实现复杂度稍高需要处理并发回填的竞争。第二个是热点副本。同一个内容的计数key在Redis里保存多个副本比如like:count:hot:{target_id}:0和like:count:hot:{target_id}:1查询请求按照某种散列规则分布到不同副本上。这样一个热点key的压力就从一个哈希槽单点变成了多个副本分摊Redis集群里的瓶颈会被明显缓解。热点副本的代价是数据一致性需要多写一点心思因为点赞操作需要把计数同步到所有副本。好在点赞数这个场景数据量小我通常是写计数时直接循环更新两个副本同时用Lua脚本保证两个副本更新的原子性。3.3 缓存穿透与雪崩的处理预案缓存穿透是指查询一个根本不存在的数据比如有人恶意构造一个不存在的内容ID来请求点赞数缓存里没有、数据库里也没有这个请求会每次都打到数据库。对于点赞系统更好的处理方式是维护一个布隆过滤器在白名单里存所有有效内容ID查询前先过一遍过滤器不存在的ID直接返回默认值0不再逐层下探。缓存雪崩则是大量key在同一时间到期导致大量请求同时回源数据库。这个问题相对简单方案就是给缓存的过期时间加随机偏移量让过期时间分布在区间内而不是整齐划一。比如TTL设定为180秒加上一个0到60秒的随机数就能有效错开大量key同时失效的时间点。还有一件事容易被忽略DB回源接口本身必须限流。哪怕我们把击穿和穿透都处理了Redis因为某些原因整体挂掉时回源流量依然可能瞬间打爆数据库。回源接口上加一个信号量比如同一时间只允许20个查询线程进入数据库其余请求等待或走降级值这算是我经历过Redis故障后养成的习惯。4. 幂等与反刷设计重复点击、乱序请求和恶意调用怎么处理4.1 同一用户疯狂点击计数就是会被加错说完读写链路现在聊这个系统里最容易出问题的角落幂等。很多初版代码把幂等写成先查一下有没有记录再决定是否插入这在低并发下管用但一旦用户的两次点赞请求同时到达两个请求都查不到记录于是都执行了插入和计数加一操作结果就是一个人点了两下赞计数加了2。而且这种情况用测试脚本跑几十万次时错误会被翻倍放大非常难看。我的做法是在Redis里用Lua脚本原子地做SISMEMBER判断集合中是否存在用户也就是说判断和写入这两个动作必须在一个命令批次里完成中间不允许插入任何其他操作。上面贴的那段Lua脚本就是解决这个问题的方案。脚本返回0表示这次操作被判定为重复返回负数或正数表示点赞/取消成功同时带回最新计数。这里有一个细节判断集合里要不要给用户集合设置过期时间如果这是一个永久性的集合里面会积累海量的用户ID内存占用会非常大。但如果不设置过期时间我们又无法回答这个用户到底有没有点过赞的问题。我的方案是给用户集合设置一个相对较长的过期时间比如7天。对于活跃内容来说7天足够覆盖它绝大部分生命周期对于不活跃内容过期后该内容的点赞关系会从Redis消失但数据库里依然有完整记录如果后续又出现新的一次点赞请求再从数据库把关系加载回来。数据库里的关系表才是最终事实源Redis里的集合只是加速层。4.2 请求层幂等键防重不只是防数据重复除了业务层的幂等网络层的重复请求也要处理。客户端在弱网环境下经常会出现同一个点赞动作被HTTP层重试了两次或者用户顿了一下双击两个请求几乎同时发出。这两个请求以当前的技术手段完全无法互相感知对方必须有一个机制在入口就把重复挡住。我在接入层维护了一个请求幂等键规则是用户ID 内容ID 动作类型再拼接一个客户端生成的随机串。请求进来时先通过Redis的SET key value NX PX 5000命令尝试写入这个幂等键如果写入成功说明这个请求是首次到达业务正常执行如果写入失败说明短时间内已经有相同请求了直接返回当前计数作为响应。// 幂等键写入逻辑 SET like:idempotent:{userId}:{targetId}:{action} 1 NX PX 5000NX保证只有第一次能写进去PX指定5秒后自动过期也就是说5秒内同样的请求会被挡掉。这个方案实现成本极低却堵住了网络重试和用户快速双击这两个高频漏洞。要注意的是幂等键的过期时间不能太长否则会影响用户真实的连续操作比如用户点赞后立刻取消再点赞这些动作之间间隔如果超过5秒实际上就不应该被判定为重复请求了。4.3 恶意刷量的防御思路反刷是另一个绕不开的话题。总有攻击者或者业务黑产会用大量账号对特定内容集中刷赞从系统资源层面看和正常的流量突刺并无区别但从数据质量层面看它会污染内容热度排序让推荐系统失真。从工程角度我能做的是三层防线。第一层是接入层的行为风控根据IP、设备指纹、用户历史行为做一个简单的频率评分超阈值直接拒绝。第二层是用户集合维度的差异化限流比如同一用户在一分钟内最多只能产生几次点赞动作同一IP在不同内容上的点赞频率也有上限。第三层更隐蔽在异步落库时做身份聚类检测发现大量新注册用户在同一时段集中给同一内容点赞会把这条业务数据推送到人工审核队列。这三层都不是靠单一规则能搞定的但每一层都能挡掉一大半的异常流量。核心原则是风控不要拦正常用户只拦过渡到后台系统的极端请求所以阈值参数需要基于真实流量分布来配置而不是拍脑袋定死。5. 异步落库与最终一致缓存不丢数据是核心底线5.1 缓存里的数据必须能回到数据库点赞操作在Redis里执行得再快也不能一直只存在Redis里原因有两个一是Redis是内存型存储宕机有丢数据风险二是后续的推荐排序、用户中心、数据运营都要用到持久化的点赞关系。所以我们必须把点赞数据异步同步到数据库这个环节的核心就是消息队列加批量落库。流程是这样的点赞请求在Redis执行完Lua脚本后紧接着把一条点赞事件投递到消息队列消息内容包含用户ID、内容ID、动作类型、操作时间戳和数据版本号。消息队列是整个链路的缓冲层它的作用是在流量高峰时帮数据库挡住压力让消费端按照数据库能承受的速率慢慢地消费。消息队列的好处是天然支持削峰填谷生产者可以在瞬间产生海量消息消费者则可以以恒定速率处理。有人问那Redis到消息队列这一段会不会丢当然也可能丢。比如Redis执行成功之后还没投递消息进程就宕机了。为了解决这个极小概率问题我在实现时没有把投递消息和Redis写入做成同一个事务而是采用了一个折中的方案Redis里额外记录一个已投递标记同时启动一个定时扫描任务发现Redis中有新增点赞但消息队列中无对应投递记录的自动补偿投递。这种基于对账的补偿机制没办法做到百分百无延迟但对最终一致性的要求来说完全够用了。5.2 批量聚合消费避免数据库被小消息碎碎打如果消息队列里的每条消息都立刻触发一条数据库更新语句那数据库同样会被耗死。点赞操作本身太轻了一条消息只代表一个用户的单次操作高频低价值逐条落库是对数据库的折磨。我的做法是在消费端做窗口聚合。消费进程拉取最近几秒内的一批消息按内容ID聚合同一个内容ID下的用户ID合并成一个集合。聚合之后再去执行数据库写入写入分成两张表一张是内容点赞计数表保存目标内容ID和最新点赞数另一张是用户点赞关系表保存用户ID、内容ID、动作类型的明细记录。批量写入的效果非常明显。假设一秒钟涌入一万条点赞消息逐条写入要执行一万次SQL而聚合后可能只有几百个内容ID只需要执行几百条批量SQL对数据库的压力下降了一个数量级。聚合消费还有一个副产品它使得同一内容ID的多个操作可以在内存里预先做一次合并。比如用户在这几秒窗口内先点赞再取消再点赞最终可以直接落一条最终状态连数据库都省了一次操作。-- 聚合逻辑伪代码 while batch queue.poll(5000, 1000): map[targetId].addAll(userActions) for each target: batchUpsertCounter(targetId, avg/recent count) batchUpsertLikeRelations(users)5.3 消息重复消费与最终一致的兜底消息队列无法保证恰好一次投递最多只能保证至少一次。也就是说相同的事件可能被消费多次。我在消费端做幂等的方式是给每条点赞事件生成唯一流水号并在数据库的点赞关系表里对这个流水号建立唯一索引。重复消费时数据库会拒绝重复插入计数器则通过UPDATE ... WHERE version ?的方式来防止覆盖新的数据。还有一个很常见的问题是Redis里的计数和数据库里的计数对不上。这种情况大多来源于取消点赞时消息延迟、重复消费导致计数恢复、或者数据库写入失败被退回。我的处理方式是每天晚上有一个对账任务按照每个内容ID比对Redis里的实时计数和数据库里的持久计数发现差值超过阈值时以Redis里的一致性时长记录为准做修正。这种对账不是实时的但对于点赞业务来说一个晚上之内修正完毕完全在可接受范围内。从本质上看这套设计讲的是最终一致性用户看到的点赞数是Redis秒级更新的实时值数据库的持久化数据允许落后几秒甚至几十秒但任何一个时间点都不能丢失正确的状态。6. 上线前要算清楚的三笔账容量、延迟与降级6.1 第一笔账Redis内存和QPS怎么估很多系统上线后才出问题是当初就没算账。我在设计时习惯先做容量估算从业务预期反向推导出每个组件的资源需求。假设目标日活是五十万用户平均每人每天刷信息流时会看到两百条内容、其中点赞三次左右那单日点赞操作量大概是三百万次。日均QPS不到35但前面说过突刺才是关键按日常峰值的十倍到二十倍估算点赞写入的瞬时峰值大概在3500到7000 QPS之间而读请求包括展示点赞数通常是写请求的十到二十倍所以Redis整体峰值可能达到五万到十万次命令每秒。这个量级对Redis来说不难扛但内存得算清楚。每条内容在Redis里保存的点赞计数键值大概占用50字节用户集合里每个用户ID占用约20到30字节再加上集合本身的底层结构开销。如果平台上有十万条活跃内容、平均每篇有三百个点赞用户Redis中因点赞产生的内存占用大约在百兆级别完全在合理范围。但如果你的用户集合永不过期而且内存不断累加就必须要做冷热数据分层这也是我在第四节里强调集合要设置过期时间的原因。准备一个八节点Redis集群每个节点32GB内存用来承载上述量级绰绰有余。与此同时业务应用层至少要有二十个以上实例才能支撑请求洪峰这些数字是压测前可以提前算出来的。6.2 第二笔账数据库分表和消费速率持久化这层也有两笔账要提前想清楚。首先是点赞关系表的大表问题。三百万次点赞意味着三百万行明细数据看起来不多但如果连续运营一年这个表会膨胀到几亿行届时单表查询和更新都会变得非常吃力。所以我在设计初期就按内容ID做了分表比如按target_id % 16分成16张表将来增长速度超过预期时还可以继续翻倍扩展到32张。有人觉得用用户ID分表更合适因为用户视角查询自己的点赞列表更多但点赞系统的核心查询场景是某个内容有哪些人点赞过以及对内容做计数汇总按内容ID分表在日常查询路径上更顺。其次是消息队列消费速率的估算。数据库单条更新语句在批量模式下每秒能执行几百到上千次批量聚合后每秒能处理几十万条点赞操作。这意味着一个消费组加三四台机器就足够消化前面的写入峰值。如果队列出现积压就要检查是不是消费端变成了逐条执行这是最容易被忽视的瓶颈。6.3 第三笔账降级方案要提前想好所有容量规划都建立在正常负载的假设下真正的账号是万一这假设不成立怎么办。我在这里说的降级不是简单的熔断而是一整套分层次的降级策略。最低一级的降级是展示层降级。当点赞计数缓存整体不可用时前端优先展示后端返回的兜底数字比如展示上一次缓存的数值减少对实时数据接口的依赖。稍微高一级的降级是写操作降级。Redis它整体不可用的时候我们临时把点赞操作写入一个本地文件或者内存缓冲等Redis恢复后再补偿。这个方案有风险因为本地缓冲也有丢失风险但它至少能保住不直接打垮数据库的底线。最高一级的降级是容量自动扩容。现在的云上环境都支持弹性伸缩信息流业务可以在流量突刺前提前扩容或者根据监控指标自动增加Redis节点和消费者实例。但是扩容也不是瞬间完成的所以必须在监控阈值里预留出足够的提前量。我在实际配置中当单节点CPU达到65%时就触发扩容报警而不是等到80%报警了再手忙脚乱因为扩容动作从触发到新增实例真正生效还有几分钟的延迟。我始终觉得一个系统的上限不是由你估算的容量决定的而是由你在超出容量时怎么应对决定的。给出这套降级预案之后我们团队后来又专门做了一次混沌演练人为杀掉Redis集群中的一个节点、停止消息队列消费、并发拉高两倍观察系统的表现。结果发现有一个消费者线程池配置不合理导致回源线程被占满这问题平时根本不会暴露只有在这种人为制造故障的演练里才会现出原形。实际上进入生产环境之前你的系统永远不算真正完成。点赞这个动作看起来简单到不行但当你把它放到百万级、高并发这些词前面时它就变成了一个需要精心设计缓存、完善幂等、规划持久化、预设降级的系统工程。第三笔账不是算出来的是练出来的这也是我做完这套系统后最深刻的体会。