在移动互联网应用生态中，“点赞”看似是一个微不足道的交互动作，实则是支撑内容社区活跃度、推荐算法权重以及用户情感反馈的核心基石。从微博的转发点赞到抖音的双击心形，再到知乎的专业认可，点赞系统的设计复杂度随着用户量级的增长呈指数级上升。在日活用户（DAU）仅几千的初创期，简单的数据库UPDATE语句即可应付；但当系统面临百万级并发、海量内容存储以及严苛的数据一致性要求时，传统的单体架构将瞬间崩塌。本文将深入剖析点赞系统从0到1的架构演进路径，重点探讨在高并发场景下如何利用缓存策略、消息队列及分布式锁机制，解决超卖、重复计数及数据丢失等核心难题，为构建稳健的内容互动平台提供可落地的技术参考。
一、基础模型设计与数据库层面的瓶颈突破
设计点赞系统的起点是数据模型的定义。最直观的思维是建立一张关联表likes，包含user_id、target_id（内容ID）、target_type（内容类型，如文章、视频、评论）以及create_time。每当用户点击点赞，后端执行一条INSERT语句；取消点赞则执行DELETE。为了快速获取某内容的总点赞数，通常会在内容表contents中增加一个like_count字段，每次变动时同步更新。
这种“行锁+实时计数”的模式在低并发下运行良好，但在高并发场景下会遭遇严重的性能瓶颈。当一篇热门文章瞬间涌入数万次浏览和点赞请求时，数据库会对contents表中该行的like_count字段施加排他锁（X锁）。大量的写请求排队等待锁释放，导致数据库连接池迅速耗尽，响应时间（RT）急剧飙升，甚至引发雪崩效应。此外，频繁的INSERT/DELETE操作会产生大量碎片，导致索引膨胀，查询效率下降。更致命的是，网络抖动或应用层异常可能导致“点赞成功但计数未加”或“计数加了但记录未生成”的数据不一致问题。
为了解决数据库写压力，第一阶段的优化通常是引入“延迟写入”策略。不再直接操作数据库，而是将点赞请求先写入内存队列或本地缓存，积累到一定数量或时间间隔后，再批量合并更新数据库。然而，单机内存存在容量限制且不具备高可用性，一旦服务重启，未持久化的点赞数据将永久丢失。因此，必须将视线转向分布式缓存系统，利用其高性能读写特性作为抗压的第一道防线。
二、基于Redis的缓存架构与原子性保障
引入Redis是构建高并发点赞系统的关键转折点。利用Redis丰富的数据结构，可以设计出多种高效的存储方案。最常用的是Set结构，以like:target_id为Key，将user_id作为成员存入。这种设计的优势在于天然去重：无论用户点击多少次，SADD操作都能确保同一个user_id在集合中只存在一次，完美解决了“重复点赞”的逻辑校验问题。同时，使用SCARD命令获取集合元素个数即可得到实时点赞总数，时间复杂度仅为O(1)。
针对海量数据场景，若单个热门内容的点赞用户数千万，单个Set可能占用过大内存或影响集群分片均衡，此时可采用Bitmap或HyperLogLog。Bitmap通过位图映射用户ID，极度节省空间（1亿用户仅需约12MB），且支持高效的位运算（如判断是否点赞、统计总数），但前提是用户ID必须是连续整数或经过特殊映射。HyperLogLog则适用于对精度要求不高（允许万分之一的误差）的超大基数统计场景，能以极小的内存占用统计亿级点赞数，但在需要精确列出点赞用户列表时显得力不从心。
在缓存与数据库的一致性维护上，单纯依赖“先更缓存后更库”或“先更库后更缓存”均存在风险。业界通用的最佳实践是“缓存抗读写，异步刷库”。具体流程为：用户点赞时，先在Redis中执行SADD，若返回成功则直接向前端返回成功响应，无需等待数据库操作。随后，通过监听Redis的Keyspace通知或应用层定时任务，将新增的点赞记录异步写入消息队列（如Kafka/RocketMQ）。后端消费者从队列中拉取消息，进行批量入库操作，并定期（如每分钟）将Redis中的SCARD结果回写到MySQL的like_count字段。这种架构将同步的数据库写操作转化为异步流处理，极大地削峰填谷，保障了核心链路的低延迟。
三、极端场景下的数据一致性与防刷策略
即便引入了缓存和消息队列，分布式环境下的数据一致性依然是挑战。例如，在缓存宕机重启或主从切换期间，部分点赞数据可能丢失。为此，需设计补偿机制：利用消息队列的持久化特性，确保所有点赞行为都有迹可循；同时，部署定期的对账任务，比对Redis集合大小、数据库计数值与消息队列消费进度，发现差异自动触发修复脚本。对于极其重要的业务场景，可采用“双写+版本号”机制，在数据库记录中增加版本号字段，更新时校验版本号，防止旧数据覆盖新数据。
除了技术架构，业务层面的防刷与安全同样重要。恶意用户或脚本可能通过高频接口调用刷高点赞数，干扰推荐算法甚至进行欺诈。系统需构建多层防御体系：首先在网关层实施限流，针对同一IP或设备指纹在短时间内对同一内容的点赞请求进行拦截；其次在业务层引入行为分析，检测非人类的操作频率（如毫秒级连续点击），对可疑账号进行临时封禁或强制验证码校验。此外，针对“取消点赞”后的重新点赞逻辑，需确保状态机的严谨性，避免出现状态跳变导致的计数错误。
在用户体验层面，点赞操作的响应速度直接影响用户留存。通过上述架构优化，可将接口响应时间控制在50ms以内，实现“秒赞”体验。同时，前端应采用乐观更新策略：用户点击后立即在界面展示点赞效果，后台异步处理实际逻辑。若后台处理失败（如被风控拦截），再通过静默回调或下次刷新时修正状态，既保证了流畅性，又维护了数据的最终一致性。
综上所述，设计一个高可用的点赞系统，绝非简单的数据库增删改查，而是一场涉及缓存策略、异步解耦、数据一致性校验及安全风控的系统工程。只有根据业务规模选择合适的存储结构，构建稳健的异步处理链路，并辅以严密的监控与补偿机制，才能在海量并发冲击下保持系统的稳定与数据的准确。
