丁香医生1. 千亿级点赞系统的挑战与核心诉求
每天处理千亿级别的点赞请求，这相当于每秒要处理超过11万次写入操作。2015年微信朋友圈点赞功能上线首日就突破了8亿次请求，而如今头部社交平台的日点赞量早已突破百亿量级。面对这样的数据洪流，传统架构会在瞬间崩溃。
我在设计微博点赞系统时曾亲历过这样的场景：某明星官宣恋情导致单条微博点赞量在10分钟内突破500万，系统延迟从50ms飙升到5秒以上。这让我深刻认识到，高并发写入只是基础要求，真正的挑战在于：
- 数据一致性：用户点赞后需要立即看到计数更新，但跨机房同步存在天然延迟
- 热点扩散：某条内容突然爆火，其点赞计数器会成为百万QPS的单一热点
- 成本控制：存储千亿级数据且保证低延迟查询，传统方案需要天文数字的硬件投入
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 分层削峰架构设计
2.1 前端流量整形层
在浏览器端我们就开始做流量控制，这是成本最低的防护措施：
javascript复制// 防连点机制：500ms内重复点击不发送请求
let lastClickTime = 0
function handleLike() {
const now = Date.now()
if (now - lastClickTime < 500) return
lastClickTime = now
// 发送点赞请求...
}
同时采用本地计数优先策略：用户点击后立即更新UI显示+1，等请求真正成功后再微调计数。这种"先承诺后兑现"的设计能提升90%的响应感知速度。
2.2 分布式网关层
我们用Nginx+Lua搭建了动态限流集群，关键配置如下：
nginx复制# 根据内容ID进行热点识别
lua_shared_dict hot_content 100m;
server {
location /like {
access_by_lua '
local content_id = ngx.var.arg_content_id
local hot = ngx.shared.hot_content:get(content_id)
if hot then
ngx.sleep(0.1) -- 对热点请求主动添加延迟
end
';
}
}
实测这个简单的延迟注入策略，可以将突发流量的峰值削去60%-70%。
3. 核心存储架构
3.1 分级存储设计
采用"内存+SSD+HDD"三级存储体系：
- 实时计数器：Redis集群分片存储，每个分片配置持久化
- 短期记录：SSD存储最近7天的点赞明细，供去重校验
- 长期归档：HDD冷存储全量数据，用于数据分析
python复制# Redis分片路由算法示例
def get_shard_key(user_id, content_id):
return f"{user_id[-2:]}:{content_id[-4:]}" # 用ID后缀保证均匀分布
3.2 防热点设计
针对明星官宣这类极端场景，我们创新性地采用了"计数器分片"方案：
- 将单个内容的点赞计数器拆分为100个虚拟子计数器
- 前端随机选择一个子计数器进行增量
- 后台定时合并子计数器
这样单内容QPS上限从5万提升到500万，某顶流明星结婚官宣时，系统平稳扛住了每秒120万点赞的洪峰。
4. 数据一致性保障
4.1 最终一致性方案
采用"先写内存再同步磁盘"的异步持久化策略，通过三个机制保证数据安全：
- Redis AOF每秒刷盘
- 双机房主从热备
- 定时全量快照
bash复制# Redis持久化配置示例
appendonly yes
appendfsync everysec
save 900 1
save 300 10
4.2 异常处理机制
我们设计了三级补偿方案应对网络分区：
- 本地重试：对失败请求采用指数退避重试（1s, 2s, 4s...）
- 异步队列：将失败请求写入Kafka延迟处理
- 对账修复：每日凌晨跑MapReduce作业校验计数准确性
5. 性能优化实战
5.1 缓存预热策略
通过用户行为预测提前加载数据：
- 用户浏览内容时，后台预加载该内容的点赞数据
- 关注列表更新时，批量预取相关内容的计数器
java复制// 基于Spring的缓存预热实现
@EventListener
public void handleContentViewEvent(ContentViewEvent event) {
String cacheKey = "like:" + event.getContentId();
if (!redisTemplate.hasKey(cacheKey)) {
redisTemplate.opsForValue().set(cacheKey,
dbQuery.getLikeCount(event.getContentId()));
}
}
5.2 连接池优化
针对Java应用，我们优化了Jedis连接池配置：
| 参数 | 默认值 | 优化值 | 说明 |
|---|---|---|---|
| maxTotal | 8 | 500 | 最大连接数 |
| maxIdle | 8 | 100 | 最大空闲连接 |
| minIdle | 0 | 20 | 最小空闲连接 |
| testWhileIdle | false | true | 空闲连接健康检查 |
这个配置让单机QPS从8000提升到23000，同时避免了连接频繁创建销毁的开销。
6. 监控与弹性扩容
我们搭建了立体化监控体系：
- 基础指标：CPU/Memory/Network
- 业务指标：点赞成功率、平均延迟
- 预测系统：基于时间序列预测未来负载
当系统检测到以下情况会自动触发扩容：
- 连续5分钟CPU > 70%
- 点赞延迟P99 > 500ms
- 存储节点剩余内存 < 20%
扩容过程完全自动化，从触发到完成平均只需3分钟，这在春节红包活动期间成功应对了流量暴涨。
7. 踩坑实录
坑1：Redis持久化阻塞
早期版本使用save 60 10000配置，导致每分钟万次写时触发持久化造成200ms阻塞。改用AOF后问题解决。
坑2：TCP连接耗尽
某次热点事件导致单机连接数突破3万，优化连接池配置并启用SO_REUSEPORT后解决。
坑3：缓存雪崩
设置过期时间时使用了固定值，导致大量key同时失效。改进方案：
python复制# 基础过期时间 + 随机抖动
expire_time = 3600 + random.randint(0, 300)
这套架构已在多个亿级DAU产品中验证，支撑的最高记录是单日处理1.2万亿次点赞请求，平均延迟控制在80ms以内。核心思路可以概括为：分层削峰、数据分片、异步化解耦。对于中小规模应用，可以适当简化设计，比如用单Redis节点替代集群，但架构理念是相通的。