golang 壓測redis 訊息佇列

用 redis  的 list 資料結構作為輕量級的訊息佇列，對於小系統確實是小而美，可控能力強。

當然與kafka 和 rabbitmq 相比它還有很多缺陷，在服務進行生產和消費的時候，還需要加上部分邏輯進行處理。

自己寫了點 golang 代碼，壓力測試 redis 列表的效能。

機器配置：雙核，4G

測試資料：100w

壓力測試源碼（github）

生產者，生產 100 w 條資料，平均，每秒能寫 13817 條資料。

begin time: 2018-07-29 14:03:55.606

end    time: 2018-07-29 14:05:07.976

Produce message: 1000000

avg: 13817.860879118389

負載
程式碼片段

消費者，消費 100 w 條資料，平均每秒能讀 9433  條資料左右。

begin time: 2018-07-29 14:46:11.166

end time: 2018-07-29 14:47:58.038

custom message: 1000000

avg: 9433

負載程式碼片段

總結：

以上生產和消費測試都是獨立測試的，生產資料和消費資料，能達到 1w 左右的並發；如果生產者和消費者同時進行工作，各自並發能力還要下降 20% 左右。

講真，一般的小企業業務系統，真正核心的業務資料（非流水，行為記錄等日誌型資料），寫並發能達到 1 w 的已經很厲害了，某些金融公司，幾百萬註冊使用者（活躍度不夠），峰值寫並發也只有幾千而已。一般系統都應該是讀操作多於寫操作，當然具體情況應該具體分析^_^。