高并发点赞系统架构设计与优化实践

1. 百万级点赞系统的核心挑战

每天处理百万级点赞请求的系统，远不是简单地在数据库里做UPDATE table SET likes=likes+1这么简单。去年我们团队接手一个直播平台的点赞系统重构，峰值时期每秒要处理超过2万次点赞请求，这个过程中踩过的坑让我深刻理解了高并发场景下的技术博弈。

最核心的矛盾在于：用户需要实时看到点赞数变化（强一致性），而系统又必须承受突发流量（高可用性）。这就像在早高峰的地铁站，既要保证每个乘客都能快速通过闸机（低延迟），又要避免人群在入口处堆积（防崩溃）。传统方案往往顾此失彼——用缓存可能导致计数不准，直接写数据库又扛不住流量。

2. 系统架构设计演进

2.1 第一代架构：数据库直写模式

初期采用最朴素的方案：

sql复制START TRANSACTION;
SELECT likes FROM items WHERE item_id=123;
UPDATE items SET likes=likes+1 WHERE item_id=123;
COMMIT;

这个方案在测试环境表现良好，但上线后立即暴露三个致命问题：

1. 热门直播间的点赞操作导致数据库CPU飙升至100%
2. 事务锁竞争造成大量请求超时（TP99超过3秒）
3. 主从同步延迟导致用户看到的数据不一致

关键教训：关系型数据库的ACID特性在高并发场景反而成为瓶颈，特别是X锁的排他性会导致大量线程阻塞。

2.2 第二代架构：缓存计数+异步落库

引入Redis作为缓冲层，典型代码如下：

python复制def like(item_id, user_id):
    redis.incr(f"counter:{item_id}")
    redis.sadd(f"users:{item_id}", user_id)
    async_task(commit_to_db, item_id)  # 异步任务

优化效果立竿见影：

• 吞吐量从200QPS提升到15000QPS
• 响应时间从秒级降到毫秒级

但新问题随之而来：

1. 突发流量导致Redis内存暴涨（每个item需要存储点赞用户ID）
2. 异步任务堆积时可能丢失数据
3. 缓存宕机导致计数完全不可用

2.3 第三代架构：