7.4项目一简历问题
1.问题一：峰值请求承载提升3倍是怎么得出的？Redis是怎么异步处理点赞的？
我在项目初期使用的是同步写数据库的方式处理用户点赞操作，在并发压测时发现当并发量达到 3000+ 时接口响应变慢，数据库出现锁竞争，QPS 峰值大约在 1200/s 左右。
后来我将点赞操作改成了基于 Redis 的异步计数方式，具体做法是：
点赞行为先写入 Redis 的 Hash（post_like:{post_id}）中；
后台定时任务每隔5秒异步批量落盘到 MySQL；
同时使用 Redis 的 HyperLogLog 做防刷控制。
经过重新压测，接口最大承载 QPS 达到了 3600/s 左右，并发下响应明显更快，所以我在简历中写“提升了 3 倍”是基于实际压测对比数据得出的。
📌 关键词记忆：
对比测试前后 QPS 数据：1200 ➜ 3600
Redis Hash 暂存点赞，定时落库
异步提升并发吞吐 + 降低 DB 压力
2.问题二：热度排名算法怎么改的？怎么抑制马太效应？
我研究了 Reddit 官方热度算法，它的大致形式是：
ini
复制
编辑
score = log10(点赞数 - 踩数) + (发布时间 - 基准时间) / 时间因子
这个算法在帖子初期点赞量高的情况下增长非常快，容易导致“强者恒强”（即马太效应）。
我的改进如下：
引入了一个点赞增长速率因子，对增长速度过快的帖子做衰减；
设置了时间权重衰减函数，让早期热帖热度随时间自然降低；
加入了用户活跃度权重，活跃用户的行为权重略低，降低刷帖干扰。
这样一来，既能保证新帖有被看到的机会，又不会让早期爆红的帖子长期霸榜，能实现“热度动态平衡”。
📌 关键词记忆：
Reddit 热度算法公式
改进点 = 点赞速率 + 时间衰减 + 用户活跃度惩罚
目标 = 热度可持续流动，防止“一帖定天下”
3.可用性>99.9% 怎么算出来的？JWT 双 token 机制是怎样的？
项目部署期间我使用 Prometheus + Grafana 监控了服务的状态，包括接口错误率、Redis连接状态、响应时间等指标。
在为期一周的压测和线上模拟测试中，整体接口错误率低于 0.1%，成功率达到 99.92%，所以我写“可用性 >99.9%”是有监控数据支撑的。
鉴权机制方面，我采用了JWT 双 token策略：
AccessToken：短效（15分钟），每次请求必须携带；
RefreshToken：长效（7天），在 AccessToken 过期后自动刷新；
所有请求在 Gin 的中间件中校验 AccessToken 的合法性；
若过期则使用 RefreshToken 换取新 token，降低频繁登录带来的用户体验问题。
📌 关键词记忆：
Prometheus + Grafana 监控错误率 → 计算可用性
双 token 模式（短效 + 刷新）防止频繁登录
鉴权中间件 + token 自动续期
4.核心接口响应 <100ms 是如何测试的？具体是哪些接口？
我使用了 wrk 和 ab (ApacheBench) 工具进行压测，同时配合 Gin 的中间件对接口链路进行打点记录，监控请求全程耗时。
其中几个关键接口（如“发帖”、“获取帖子列表”、“点赞接口”）在模拟 1000 并发用户情况下：
平均响应时间在 80ms 左右；
P95 响应时间在 120ms 左右；
所以我保守写了“核心接口响应 <100ms”。
优化点包括：
Redis 缓存命中率提升（帖子列表使用缓存）；
GORM 查询预加载（避免N+1）；
日志异步写入、Gin Recovery 降低异常影响。
📌 关键词记忆：
使用 wrk / ab 工具 + 自定义中间件记录
核心接口：发帖 / 点赞 / 帖子列表
P95 控制在 120ms，平均在 80ms 左右