用 redis? 的 list 數(shù)據(jù)結(jié)構(gòu)作為輕量級的消息隊列譬胎，對于小系統(tǒng)確實(shí)是小而美，可控能力強(qiáng)具帮。
當(dāng)然與kafka 和 rabbitmq 相比它還有很多缺陷苟呐，在服務(wù)進(jìn)行生產(chǎn)和消費(fèi)的時候，還需要加上部分邏輯進(jìn)行處理坝撑。
自己寫了點(diǎn) golang 代碼静秆，壓力測試 redis 列表的性能粮揉。
機(jī)器配置：雙核，4G
測試數(shù)據(jù)：100w
壓力測試源碼（github）
?? 文章來源：《壓測 redis 消息隊列（golang）》
生產(chǎn)者抚笔，生產(chǎn) 100 w 條數(shù)據(jù)扶认， 并發(fā) 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
消費(fèi)者殊橙，消費(fèi) 100 w 條數(shù)據(jù)辐宾，并發(fā) 9433? 。
begin time: 2018-07-29 14:46:11.166
end time: 2018-07-29 14:47:58.038
custom message: 1000000
avg: 9433
總結(jié)：
以上生產(chǎn)和消費(fèi)測試都是獨(dú)立測試的膨蛮，生產(chǎn)數(shù)據(jù)和消費(fèi)數(shù)據(jù)叠纹，能達(dá)到 1w 左右的并發(fā)；如果生產(chǎn)者和消費(fèi)者同時進(jìn)行工作敞葛，各自并發(fā)能力還要下降 20%左右誉察。消費(fèi)者為了保證數(shù)據(jù)被消費(fèi)失敗后，能保重新消費(fèi)惹谐，還需要寫一部分邏輯冒窍，估計性能還會下降一部分，所以單實(shí)例的Redis消息隊列消費(fèi)并發(fā)應(yīng)該是5000 左右(根據(jù)業(yè)務(wù)多開幾條隊列豺鼻，通過性能疊加综液，解決更高的并發(fā)問題？Ｈ屐）
以上用的是golang 第三方庫 redigo做的壓測谬莹，如果換成 C++ 的 hiredis 異步特性（參考我的帖子《hiredis + libev 異步測試》），生產(chǎn)者單進(jìn)程并發(fā)輕松上 10w+桩了，原則上消費(fèi)能力也一樣附帽，但是消費(fèi)為了保證數(shù)據(jù)的時序性，一般是一條條取出來入庫處理井誉，入庫是同步操作蕉扮，速度顯然快不了多少。
更精彩內(nèi)容颗圣，請關(guān)注我的博客：https://wenfh2020.com
