AI 大模型 概念 一种超大规模参数的深度学习模型。显著特征是参数量巨大(数亿至数万亿)，海量训练数据(TB 级别文本图形)，依赖高性能的 GPU/TPU 集群，训练耗时长。 GPU：图形处理器，最初设计用来图形渲染，现在广泛用于并行计算，尤其是深度学习和 AI 领

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

前期回顾 项目源码地址：https://github.com/ruogu-coder/ruogu-like 在前面的内容中，我们完善了后端系统的引入 Redis、 消息队列、分布式数据库 TiDB，对系统进行压力测试和可观测性优化，但是这个系统最后要呈现出来还是需要通过前端页面。 本期目标 利用 Cursor 生成前端项目，对接后端接口，将博客和点赞展示在页面当中。 代码实现 3.1. 创建前端目

前期回顾 前面的几章实现了一个高性能的点赞系统，除了性能外，系统的可用性 弹性和可扩展性也很重要 核心问题：现有系统存在单点故障风险（Redis/Pulsar/TiDB），缺乏有效降级机制 优化方向：在保证性能的基础上，增强可用性、弹性和容灾能力 实现特点：侧重架构设计思路，非具体实现（企业级运维管理） 可优化方案 2.1. 数据库高可用 多中心部署 跨区域容灾架构（两地三中心：主中心+同城/异地

前期回顾 项目源码地址：https://github.com/ruogu-coder/ruogu-like 在上一期进行压力测试，但是目前的系统难以实时检测系统的状态，比如点赞的请求量，响应时间等 本期目标 通过 Prometheus + Grafana 构建可观测性解决方案 开发实现 3.1. 重启 TiDB 禁用 TiDB 默认启动的 Prometheus 和 Grafana。 3.2. 添加

使用 Jmeter 进行各个接口的压力测试

引入分布式数据库 TiDB。既能保持关系型数据库的 ACID 特性，又能实现水平扩展的分布式数据库

引入Pulsar消息队列优化系统架构，提升削峰填谷的能力和系统可用性

超级热点优化，使用 HeavyKeeper 算法检测热点key，并且使用本地缓存 Caffeine 存储热点 key, 减轻 Redis 的压力

上期回顾 项目源码地址：https://github.com/ruogu-coder/ruogu-like 在项目的第二期点赞优化中，优化了查询点赞的功能，从 Mysql 查询修改为了 Redis 查询，使用 satoken 实现了分布式登录。 本期目标 优化点赞功能的写操作，针对点赞和取消点赞功能的高并发场景下出现的性能瓶颈。 实现思路 上期我们设计的用户点赞的数据结构为： key 为博客 id