RabbitMQ-Go 性能分析

更多个人笔记见：
github个人笔记仓库
 gitee 个人笔记仓库

个人学习，学习过程中还会不断补充～（后续会更新在github和 gitee上）

文章目录

- 对比功能
- - - 没有rabbitMQ
    - 有rabbitMQ
    - [wrk 测试分析](#wrk 测试分析)

链接：项目连接,完整项目代码仓库下载
https://gitee.com/harryhack/it_note/tree/main/后端笔记/常用Web技术/RabbitMQ

对比功能

为了说明 RabbitMQ 的引入有什么好处！

下载wrk
brew install wrk
测试指令：
bash 复制代码
```
wrk -t 10 -c 100 -d 30s --latency http://localhost:8080/posts -s post.lua
```
-t：使用 10 个线程 并发发送请求。
-c：总共建立并保持 100 个 TCP 连接 （即并发数）。
-d 30s：测试持续 30 秒 。
--latency：在测试结束后，输出 延迟统计信息
-s post.lua：指定 lua 脚本
lua 脚本：

lua 复制代码

wrk.method = "POST"
wrk.body   = '{"title":"Test Post","content":"This is a test"}'
wrk.headers["Content-Type"] = "application/json"

没有rabbitMQ

图见仓库中

![[.../.../.../.../attachments/Pasted image 20250601114039.png]]

有rabbitMQ

![[.../.../.../.../attachments/Pasted image 20250601115515.png]]

wrk 测试分析

请求延迟
有 RabbMQ整体效果更好，平均值低了 9倍
有 RabbMQ 的里，50% 请求延迟：6.21ms，99% 请求延迟：74.02ms 都显著更好
吞吐量
显然有 RabbitMQ 的总吞吐量更大（总的 request 和每秒的 request）
稳定性
查看请求延迟百分比以及 stdev （越小越好）可以发现，有 RabbitMQ 更加稳定

补充：

RabbitMQ 支持多个消费者并行处理消息，通过增加消费者实例（--scale app=3）可进一步提高吞吐量和降低延迟。
- docker-compose up --scale app=3
同步版本受限于 MySQL 写入性能，扩展性较差（需优化数据库，如分片或读写分离）
停止消费者，发送 100 个请求然后查看 http://localhost:15672 可以检查数据的完整性（存在里面）

疑问：

问：为什么同样都是数据库读取，RabbitMQ 的话我的理解就是中间"多了一个管道"这样，但是数据库还是一个个读取的，理论上应该加了 rabbitMQ 的延迟更高么？
答：虽然 RabbitMQ 增加了一个中间层（消息队列），但它带来的异步处理和解耦效应显著降低了 API 端的延迟
- 没rabbitMQ 的同步版本流程：
  - 用户发送 POST /posts 请求。
  - Gin 服务接收请求，解析 JSON 数据。
  - Gin 直接调用 GORM 将帖子写入 MySQL（db.Create(&post)）。
  - 等待 MySQL 完成写入操作（包括磁盘 I/O、事务提交等）。
  - 返回响应给用户。
    延迟来自：MySQL 写入延迟：通常在 10-50ms 级别（取决于数据库负载、索引、锁等）。以及高并发下，MySQL 可能出现锁竞争或连接池瓶颈，进一步增加延迟
- 异步版本有 RabbitMQ 流程：
  - 用户发送 POST /posts 请求。
  - Gin 服务接收请求，解析 JSON 数据。
  - Gin 将帖子序列化为 JSON，推送至 RabbitMQ 队列（ch.Publish）。
  - 立即返回响应给用户（不等待数据库写入）。
  - 消费者（后台 goroutine）从 RabbitMQ 队列读取消息，调用 GORM 写入 MySQL。
    延迟来自：推送消息到 RabbitMQ：通常在 1-2ms 级别（RabbitMQ 是内存操作，速度很快）。API 响应时间仅包含推送消息的耗时，不包括数据库写入。
    结论：RabbitMQ 并没有增加 API 请求的延迟，而是将数据库写入的延迟"转移"到消费者端