当前位置: 首页 > news >正文

RabbitMQ-Go 性能分析

更多个人笔记见:
github个人笔记仓库
gitee 个人笔记仓库
个人学习,学习过程中还会不断补充~ (后续会更新在github和 gitee上)

文章目录

    • 对比功能
        • 没有rabbitMQ
        • 有rabbitMQ
        • wrk 测试分析

链接: 项目连接,完整项目代码仓库下载
https://gitee.com/harryhack/it_note/tree/main/%E5%90%8E%E7%AB%AF%E7%AC%94%E8%AE%B0/%E5%B8%B8%E7%94%A8Web%E6%8A%80%E6%9C%AF/RabbitMQ

对比功能

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

  • 下载wrk
    brew install wrk
  • 测试指令:
    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 脚本:
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 请求的延迟,而是将数据库写入的延迟“转移”到消费者端

相关文章:

  • 【irregular swap】An Examination of Fairness of AI Models for Deepfake Detection
  • Textacy:Python 中的文本数据清理和规范化简介
  • java Map双列集合
  • 【HarmonyOS Next之旅】DevEco Studio使用指南(二十九) -> 开发云数据库
  • Spring MVC参数绑定终极手册:单多参/对象/集合/JSON/文件上传精讲
  • 【Linux】Linux文件系统详解
  • 包管理后续部分
  • Window系统程序加入白名单
  • unix/linux source 命令,在当前的 Shell 会话中读取并执行指定文件中的命令
  • 【GPT入门】第40课 vllm与ollama特性对比,与模型部署
  • Leetcode 3568. Minimum Moves to Clean the Classroom
  • 【云安全】以Aliyun为例聊云厂商服务常见利用手段
  • Java大厂后端技术栈故障排查实战:Spring Boot、Redis、Kafka、JVM典型问题与解决方案
  • Vue3.5 企业级管理系统实战(二十一):菜单权限
  • flask pyinstaller打包exe,出现module not found问题
  • 用mediamtx搭建简易rtmp,rtsp视频服务器
  • FFmpeg学习笔记
  • SDL_CreateRendererWithProperties报错Parameter ‘window‘ is invalid
  • Linux 第三阶段课程:数据库基础与 SQL 应用
  • Domain Adaptation in Vision-Language Models (2023–2025): A Comprehensive Review
  • 遵义网站建设1w1h/怎样优化网站排名
  • 广州微网站建设效果/淘宝美工培训推荐
  • 长治网站设计/网络营销学院
  • 晋城做网站的公司/品牌宣传策略
  • 怎样进入网站的后台/西安seo服务培训
  • 微信上浏览自己做的网站吗/一站式媒体发布平台