亿级流量点赞系统-最终篇

1. 🌈 项目全景概述

项目源码地址：https://github.com/ruogu-coder/ruogu-like

这个项目构建了一个支持亿级流量的点赞系统，从前端交互到后端架构，从基础功能到高可用设计，覆盖了高性能、高并发、高可用、可观测性、弹性扩展等核心架构要素。通过十个章节的实践，涉及Redis、Lua 脚本、HeavyKeeper算法、Pulsar、TiDB、Prometheus等核心技术组件。

2. 🔥 核心模块与技术亮点

2.1. 1️⃣ 基础架构搭建

• 技术栈：SpringBoot3 + MyBatis-Plus + SaToken + JDK21
• 核心问题：解决SpringDoc与ControllerAdvice兼容性问题（@Hidden注解规避异常），冷热数据分离设计（Redis Hash结构存储用户点赞状态）
• 性能优化：

▼
lua
复制代码
-- 示例：点赞Lua脚本实现原子操作
if redis.call('HEXISTS', KEYS[2], ARGV[2]) == 1 then return -1 end
redis.call('HSET', KEYS[1], hashKey, newValue)
redis.call('HSET', KEYS[2], blogId, 1)

• 冷热分离策略：按时间片（如thumb:temp:{HH:mm:ss}）分片存储，异步批量同步MySQL
• Lua脚本原子性：保证点赞→Redis更新→定时任务的事务一致性

2.2. 2️⃣ 性能跃升

• 二级缓存架构：

▼
java
复制代码
// HeavyKeeper实现热点检测
AddResult result = hotKeyDetector.add(key, 1);
if (result.hotKey()) localCache.put(key, value);

• 本地缓存：Caffeine + HeavyKeeper热点探测算法（自实现TopK检测）

• 算法核心：衰减因子（0.92）+ 哈希分桶，精准识别高频Key

• 异步削峰：

• Pulsar消息队列：批量消费（1000条/批次），死信队列+补偿任务保证最终一致性

• 对账机制：每日凌晨扫描Redis与数据库的差异，自动触发补偿

2.3. 3️⃣ 高可用设计方案

• 数据库层：

• TiDB分布式架构：水平分片+自动故障转移，替代单点MySQL

• 降级策略：Redis缓存兜底，DB不可用时返回历史数据

• 缓存层：

• Redis三种模式：哨兵模式 主从复制 集群模式

• 消息队列：

• Pulsar地理复制：跨机房容灾，消息重试策略（指数退避）

• 熔断限流：

• Sentinel熔断：异常比例>50%时触发熔断，保护下游服务

• 混沌工程：模拟节点宕机/网络延迟，验证RTO<30s

2.4. 4️⃣ 可观测优化

• 监控体系：

▼
plain
复制代码
sum(rate(http_server_requests_seconds_count{uri="/api/thumb/do"}[1m])) # 点赞QPS

• Prometheus：采集Redis/TiDB/Pulsar等指标

• Grafana看板：自定义QPS/缓存命中率/错误率等核心仪表盘

• 告警联动：钉钉/邮件告警，自动触发扩容脚本

2.5. 5️⃣ 压测验证

• Jmeter压测：

• 模拟5010 个用户：CSV参数化+分布式线程组

• 性能对比：

• 瓶颈分析：TiDB虚拟机部署导致延迟，生产环境需专用集群
• 我的 TiDB+消息队列可能是在虚拟机的原因，实际测试还没有本地的单机redis + mysql 的TPS高

2.6. 6️⃣ 前端 AI 生成

• Cursor生成前端：

• 技术栈：Vue3 + Vite + Ant Design Vue

• 核心功能：用户管理/博客展示/点赞交互

3. 🚀 项目收获与适用场景

1️⃣ 技术深度：

• 熟练使用HeavyKeeper/Pulsar/TiDB等前沿技术解决实际问题

2️⃣ 思维提升：

• 从功能实现→性能优化→高可用设计→全链路监控的系统工程思维
• 混沌工程思想：通过故障注入验证系统健壮性

3️⃣ 适用人群：

• 开发者群体：中高级后端工程师、架构师、全栈开发者