1. 项目概述千亿级点赞系统是支撑今日头条和抖音等超大规模内容平台的核心基础设施之一。这类系统需要处理每天数百亿次的点赞请求同时保证毫秒级的响应延迟和99.99%以上的服务可用性。作为内容互动的最基础功能点赞系统看似简单实则面临着高并发、低延迟、强一致性和高可用性等多重技术挑战。在抖音这样的平台上一个热门视频可能在几分钟内获得数百万次点赞而系统需要实时更新点赞数并确保所有用户看到一致的计数。这不仅需要精巧的系统架构设计还需要对存储、缓存、消息队列等基础设施进行深度优化。2. 核心需求解析2.1 功能性需求点赞系统的基础功能需求包括用户对内容视频/文章的点赞/取消点赞操作实时展示内容的点赞总数显示用户是否已点赞的状态支持点赞列表的查询谁点赞了这条内容2.2 非功能性需求更关键的是非功能性需求高并发处理能力单日处理千亿级请求低延迟95%的请求响应时间50ms强一致性用户看到的点赞数必须实时准确高可用性系统可用性99.99%可扩展性能够应对突发流量如明星发布内容3. 系统架构设计3.1 分层架构典型的千亿级点赞系统采用分层架构客户端 → API网关 → 业务逻辑层 → 缓存层 → 存储层 ↑ 消息队列 ↓ 异步处理层3.2 核心组件API网关请求路由和负载均衡限流和熔断保护协议转换业务逻辑层点赞业务处理计数逻辑用户状态管理缓存层点赞计数缓存用户点赞状态缓存热点数据缓存存储层点赞关系存储计数持久化操作日志消息队列异步处理队列削峰填谷事件通知4. 关键技术实现4.1 高性能计数方案采用内存计数异步持久化策略使用Redis的HINCRBY命令进行原子计数本地内存缓存热点内容的计数器定期将计数持久化到数据库使用Write-Ahead Log保证数据安全# 伪代码示例点赞计数实现 def like_content(user_id, content_id): # 1. 检查是否已点赞 if redis.sismember(fliked:{content_id}, user_id): return False # 2. 原子操作增加计数并记录用户 pipeline redis.pipeline() pipeline.hincrby(content_likes, content_id, 1) pipeline.sadd(fliked:{content_id}, user_id) pipeline.execute() # 3. 异步写入消息队列 mq.publish(like_events, {user_id: user_id, content_id: content_id}) return True4.2 缓存设计采用多级缓存策略本地缓存存储热点内容的点赞数Guava Cache分布式缓存Redis集群存储全量点赞数据使用Hash结构存储内容点赞数使用Set结构存储用户点赞关系缓存更新策略写操作直接更新缓存读失败时回源数据库设置合理的过期时间4.3 存储设计关系型数据库存储点赞关系用户ID内容ID时间戳分库分表策略按内容ID哈希分片使用时间序列分区处理历史数据NoSQL数据库存储聚合后的计数数据支持高吞吐写入数据同步基于binlog的数据同步最终一致性保证5. 高并发优化5.1 请求合并对短时间内同一内容的多次点赞请求进行合并在API网关层实现请求合并使用本地缓存记录最近操作合并窗口通常设置为100-500ms5.2 异步处理非核心路径异步化点赞通知排行榜更新数据分析5.3 热点处理针对热点内容的特殊优化本地缓存热点内容计数器动态分片将热点内容的计数器拆分到多个key限流保护防止热点内容被刷6. 一致性保障6.1 读写一致性写后读一致性用户自己的点赞操作立即可见其他用户的点赞操作最终一致全局一致性使用分布式锁保证关键操作原子性基于版本号的乐观并发控制6.2 数据一致性定期全量校对实时增量校对异常自动修复7. 监控与运维7.1 关键指标监控请求量/QPS响应时间分布缓存命中率存储延迟消息队列积压7.2 容灾设计多机房部署服务降级策略流量调度能力数据备份与恢复8. 实战经验分享在实际开发中我们遇到过几个典型问题缓存雪崩大量内容同时过期导致数据库压力激增解决方案设置随机过期时间永不过期基础数据热点Key问题明星发布内容导致单个Redis节点负载过高解决方案动态分片本地缓存计数不准确异步处理导致短暂不一致解决方案增加校对任务用户教育重要提示在点赞系统设计中不要过度追求强一致性。根据CAP理论在高并发场景下适当牺牲一致性换取可用性和分区容错性往往是更明智的选择。9. 性能优化技巧数据结构选择点赞关系使用Redis Set而不是List计数器使用Redis Hash而不是String批量操作使用Redis Pipeline减少网络往返批量写入数据库连接优化使用连接池管理数据库和Redis连接合理设置连接超时序列化优化使用Protobuf代替JSON压缩传输数据10. 扩展思考随着业务发展点赞系统可以进一步扩展分级点赞支持不同权重的点赞如超级点赞点赞原因收集用户点赞动机智能排序基于点赞模式的内容推荐社交互动点赞通知和互动提醒在实际项目中我们通过以下配置优化Redis性能# Redis配置示例 maxmemory 32gb maxmemory-policy allkeys-lru hash-max-ziplist-entries 512 hash-max-ziplist-value 64 activerehashing yes对于数据库我们采用如下分片策略-- 分表示例 CREATE TABLE user_likes_%d ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, content_id BIGINT NOT NULL, create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP, INDEX idx_content (content_id), INDEX idx_user (user_id) ) ENGINEInnoDB PARTITION BY HASH(content_id) PARTITIONS 32;最后需要强调的是任何架构设计都需要结合实际业务场景。抖音的点赞系统之所以能支撑千亿级流量是经过多年持续迭代优化的结果。初期完全可以从简单架构开始随着业务增长逐步引入更复杂的设计。