贵阳能做网站的公司有哪些软文价格

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 左右