更多個人筆記見：
（注意點擊“繼續”，而不是“發現新項目”）
github個人筆記倉庫 https://github.com/ZHLOVEYY/IT_note
gitee 個人筆記倉庫 https://gitee.com/harryhack/it_note
個人學習，學習過程中還會不斷補充～ （后續會更新在github上）

鏈接： 項目連接,完整項目代碼倉庫下載
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 請求的延遲，而是將數據庫寫入的延遲“轉移”到消費者端