消息隊列，消費者可以同時處理多條消息嗎？

z985342160 更新于2021-09-28

RabbmitMQ隊列里都是耗時任務(wù)：請求第三方的API(http)。

當(dāng)開啟一個消費worker時，能否在產(chǎn)生IO時繼續(xù)處理下一條消息。

場景：同步第三方平臺的產(chǎn)品數(shù)據(jù)，比如發(fā)起同步某個賬號的產(chǎn)品，一個賬號下面的產(chǎn)品可以最少也有幾千條，多達十幾萬的也有。

注：考慮第三方API是沒有批量查詢接口的。

將產(chǎn)品ID放在隊列里，開啟worker消費，消費者可以在遇到IO等待時繼續(xù)處理下一條消費嗎，需要對每條消息ACK（主要是當(dāng)請求失敗可以重試）。

如果不能實現(xiàn)，我就打算放到REDIS list里，用wokerman的定時器讀取redis來發(fā)送異步http請求，如果失敗就重新加到list里。

另外在這樣IO耗時的場景下，開啟進程數(shù)量怎么計算會合適些？

 2871  1 0

1個回答

six 2021-09-28

用workerman/http-client 可以異步請求，是非阻塞IO。用curl是阻塞IO，無法切換到處理下一個消息。

關(guān)于進程數(shù)的話，如果是用url阻塞方式，估算下消費一個消息需要耗時多長時間。估算下產(chǎn)生消息的頻率。進程數(shù)因該設(shè)置多少就出來了。比如一個消息耗時10秒，整個系統(tǒng)大概每秒產(chǎn)生10條消息。那么進程數(shù)就是100就可以剛好能夠處理。

如果是workerman/http-client方式處理，感覺配置成cpu的1-2倍就差不多了吧。