社区信息流高并发压测优化笔记

1. 使用 wrk 构建极限压力测试

在高并发场景下，单凭脑补很难发现底层死锁和传输网络 RTT 损耗 [cite: 81, 135, 602]。我们在 echo-server/scripts/ 下新建压测脚本 bench_posts.sh [cite: 505, 506]：

#!/bin/bash
BASE_URL="http://127.0.0.1:8080"
echo "压测最新帖子列表..."
wrk -t4 -c100 -d30s -L "$BASE_URL/api/posts/latest?page=1&page_size=20"
echo "压测用户主页..."
wrk -t4 -c100 -d30s -L "$BASE_URL/api/users/home?user_id=1&page=1&page_size=10"
echo "压测帖子详情..."
wrk -t4 -c100 -d30s -L "$BASE_URL/api/posts/detail?post_id=1"

赋予可执行权限并运行 [cite: 518]：

chmod +x scripts/bench_posts.sh
./scripts/bench_posts.sh

2. 暴露出的严重性能瓶颈

在 WSL2 环境下维持 100 个并发连接，进行 30 秒的测试后，wrk 返回的统计回执暴露出明显的吞吐分化 [cite: 512, 522, 523]：

测试接口	QPS (每秒请求数)	平均响应时间	P99 响应时间	瓶颈状态
最新帖子列表	1834.44	54.82ms	508.12ms	中等 [cite: 525, 528]
用户主页	1044.63	99.58ms	1.45s	严重瓶颈 [cite: 534, 538]
帖子详情	5902.59	17.40ms	373.13ms	优秀 [cite: 543, 546]

3. 剖析 N+1 级联同步查库隐患

致命成因：当获取一页 10 条帖子列表时，传统的 C++ 代码首先执行 1 次主查询获取帖子基本内容 [cite: 549, 550]。紧接着在内存循环中，由于要拼装作者头像、总点赞数、总评论数、当前登录用户是否点赞，又级联产生 10 次（N次）独立的数据库查询 [cite: 549, 550]！导致阻塞当前 Drogon 工作线程，引发响应剧烈抖动 [cite: 344]。

同样，在用户主页接口中，传统的拼装策略如下 [cite: 599]：

// 致命的循环同步查库（N+1）隐患代码示范
auto postCountRows = g_db->execSqlSync("SELECT COUNT(*) FROM posts WHERE user_id = ?", userId);
auto mediaCountRows = g_db->execSqlSync("SELECT COUNT(*) FROM posts WHERE user_id = ? AND image_url IS NOT NULL", userId);
auto followerCountRows = g_db->execSqlSync("SELECT COUNT(*) FROM user_follows WHERE following_id = ?", userId);
// 产生了 4 次独立网络往返 (RTT)，极限压测下瞬间被拖垮！

4. 集合级高级 SQL 聚合重构

为了消灭 RTT 损耗，我们将业务层循环转交为数据库内核的集合级操作（Set-based Operation），利用预编译占位符一次性拉取 [cite: 551, 590]：

SELECT 
    p.id, p.user_id, u.username,
    COALESCE(u.nickname, '') AS nickname,
    COALESCE(u.avatar_url, '') AS avatar_url,
    p.content, COALESCE(p.image_url, '') AS image_url,
    DATE_FORMAT(p.created_at, '%Y-%m-%d %H:%i:%s') AS created_at,
    COALESCE(lc.like_count, 0) AS like_count,
    COALESCE(cc.comment_count, 0) AS comment_count,
    CASE WHEN pl_me.user_id IS NULL THEN 0 ELSE 1 END AS liked
FROM posts p
JOIN users u ON u.id = p.user_id
LEFT JOIN post_likes pl_me ON pl_me.post_id = p.id AND pl_me.user_id = ?
LEFT JOIN (
    SELECT post_id, COUNT(*) AS like_count FROM post_likes GROUP BY post_id
) lc ON lc.post_id = p.id
LEFT JOIN (
    SELECT post_id, COUNT(*) AS comment_count FROM comments GROUP BY post_id
) cc ON cc.post_id = p.id
ORDER BY p.id DESC LIMIT ? OFFSET ?;

重构精髓：通过 JOIN users u 批量解决作者档案探测，直接干掉了 N 次重复开销 [cite: 595]。利用 GROUP BY 派生表子查询一次性将全量点赞/评论统计打成平面快照挂载在左连接侧，完美消灭 N+1 [cite: 596]！

5. 用户主页 4合1 多重聚合优化

针对主页计数器被高频刷爆的问题，我们将其重构为单次发送的 4合1 多重聚合查询 [cite: 603]：

SELECT
    (SELECT COUNT(*) FROM posts WHERE user_id = ?) AS post_count,
    (SELECT COUNT(*) FROM posts WHERE user_id = ? AND image_url IS NOT NULL) AS media_count,
    (SELECT COUNT(*) FROM user_follows WHERE following_id = ?) AS follower_count,
    (SELECT COUNT(*) FROM user_follows WHERE follower_id = ?) AS following_count;

优化回执：重构之后，数据库内核只需执行 1 次解析和编译 [cite: 610]，没有多次网络往返阻碍 [cite: 611]。用户主页 QPS 直接由原来的 1044 冲高跃升，彻底扫清了阻碍社区高并发底座的顽疾 [cite: 538, 547]。

← 返回我的主页