1. 项目概述

千亿级点赞系统是支撑今日头条和抖音等超大规模内容平台的核心基础设施之一。这类系统需要处理每天数百亿次的点赞请求，同时保证毫秒级的响应延迟和99.99%以上的服务可用性。作为内容互动的最基础功能，点赞系统看似简单，实则面临着高并发、低延迟、强一致性和高可用性等多重技术挑战。

在抖音这样的平台上，一个热门视频可能在几分钟内获得数百万次点赞，而系统需要实时更新点赞数并确保所有用户看到一致的计数。这不仅需要精巧的系统架构设计，还需要对存储、缓存、消息队列等基础设施进行深度优化。

2. 核心需求解析

2.1 功能性需求

点赞系统的基础功能需求包括：

• 用户对内容（视频/文章）的点赞/取消点赞操作
• 实时展示内容的点赞总数
• 显示用户是否已点赞的状态
• 支持点赞列表的查询（谁点赞了这条内容）

2.2 非功能性需求

更关键的是非功能性需求：

• 高并发处理能力：单日处理千亿级请求
• 低延迟：95%的请求响应时间<50ms
• 强一致性：用户看到的点赞数必须实时准确
• 高可用性：系统可用性>99.99%
• 可扩展性：能够应对突发流量（如明星发布内容）

3. 系统架构设计

3.1 分层架构

典型的千亿级点赞系统采用分层架构：

客户端 → API网关 → 业务逻辑层 → 缓存层 → 存储层 ↑ 消息队列 ↓ 异步处理层

3.2 核心组件

1. API网关：

   • 请求路由和负载均衡
   • 限流和熔断保护
   • 协议转换

2. 业务逻辑层：

   • 点赞业务处理
   • 计数逻辑
   • 用户状态管理

3. 缓存层：

   • 点赞计数缓存
   • 用户点赞状态缓存
   • 热点数据缓存

4. 存储层：

   • 点赞关系存储
   • 计数持久化
   • 操作日志

5. 消息队列：

   • 异步处理队列
   • 削峰填谷
   • 事件通知

4. 关键技术实现

4.1 高性能计数方案

采用"内存计数+异步持久化"策略：

1. 使用Redis的HINCRBY命令进行原子计数
2. 本地内存缓存热点内容的计数器
3. 定期将计数持久化到数据库
4. 使用Write-Ahead Log保证数据安全

# 伪代码示例：点赞计数实现 def like_content(user_id, content_id): # 1. 检查是否已点赞 if redis.sismember(f"liked:{content_id}", user_id): return False # 2. 原子操作：增加计数并记录用户 pipeline = redis.pipeline() pipeline.hincrby("content_likes", content_id, 1) pipeline.sadd(f"liked:{content_id}", user_id) pipeline.execute() # 3. 异步写入消息队列 mq.publish("like_events", {"user_id": user_id, "content_id": content_id}) return True

4.2 缓存设计

采用多级缓存策略：

1. 本地缓存：存储热点内容的点赞数（Guava Cache）
2. 分布式缓存：Redis集群存储全量点赞数据
   • 使用Hash结构存储内容点赞数
   • 使用Set结构存储用户点赞关系
3. 缓存更新策略：
   • 写操作直接更新缓存
   • 读失败时回源数据库
   • 设置合理的过期时间

4.3 存储设计

1. 关系型数据库：

   • 存储点赞关系（用户ID，内容ID，时间戳）
   • 分库分表策略：按内容ID哈希分片
   • 使用时间序列分区处理历史数据

2. NoSQL数据库：

   • 存储聚合后的计数数据
   • 支持高吞吐写入

3. 数据同步：

   • 基于binlog的数据同步
   • 最终一致性保证

5. 高并发优化

5.1 请求合并

对短时间内同一内容的多次点赞请求进行合并：

1. 在API网关层实现请求合并
2. 使用本地缓存记录最近操作
3. 合并窗口通常设置为100-500ms

5.2 异步处理

非核心路径异步化：

1. 点赞通知
2. 排行榜更新
3. 数据分析

5.3 热点处理

针对热点内容的特殊优化：

1. 本地缓存热点内容计数器
2. 动态分片：将热点内容的计数器拆分到多个key
3. 限流保护：防止热点内容被刷

6. 一致性保障

6.1 读写一致性

1. 写后读一致性：

   • 用户自己的点赞操作立即可见
   • 其他用户的点赞操作最终一致

2. 全局一致性：

   • 使用分布式锁保证关键操作原子性
   • 基于版本号的乐观并发控制

6.2 数据一致性

1. 定期全量校对
2. 实时增量校对
3. 异常自动修复

7. 监控与运维

7.1 关键指标监控

1. 请求量/QPS
2. 响应时间分布
3. 缓存命中率
4. 存储延迟
5. 消息队列积压

7.2 容灾设计

1. 多机房部署
2. 服务降级策略
3. 流量调度能力
4. 数据备份与恢复

8. 实战经验分享

在实际开发中，我们遇到过几个典型问题：

1. 缓存雪崩：大量内容同时过期导致数据库压力激增

   • 解决方案：设置随机过期时间+永不过期基础数据

2. 热点Key问题：明星发布内容导致单个Redis节点负载过高

   • 解决方案：动态分片+本地缓存

3. 计数不准确：异步处理导致短暂不一致

   • 解决方案：增加校对任务+用户教育

重要提示：在点赞系统设计中，不要过度追求强一致性。根据CAP理论，在高并发场景下，适当牺牲一致性换取可用性和分区容错性往往是更明智的选择。

9. 性能优化技巧

1. 数据结构选择：

   • 点赞关系使用Redis Set而不是List
   • 计数器使用Redis Hash而不是String

2. 批量操作：

   • 使用Redis Pipeline减少网络往返
   • 批量写入数据库

3. 连接优化：

   • 使用连接池管理数据库和Redis连接
   • 合理设置连接超时

4. 序列化优化：

   • 使用Protobuf代替JSON
   • 压缩传输数据

10. 扩展思考

随着业务发展，点赞系统可以进一步扩展：

1. 分级点赞：支持不同权重的点赞（如超级点赞）
2. 点赞原因：收集用户点赞动机
3. 智能排序：基于点赞模式的内容推荐
4. 社交互动：点赞通知和互动提醒

在实际项目中，我们通过以下配置优化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) ) ENGINE=InnoDB PARTITION BY HASH(content_id) PARTITIONS 32;

最后需要强调的是，任何架构设计都需要结合实际业务场景。抖音的点赞系统之所以能支撑千亿级流量，是经过多年持续迭代优化的结果。初期完全可以从简单架构开始，随着业务增长逐步引入更复杂的设计。