Gateway/Workman模式下的消息"插隊(duì)"情況
我使用Gateway/worker模式搭建了一個(gè)應(yīng)用.其中g(shù)atway->count=4,worker->count=1.在實(shí)際使用中發(fā)現(xiàn),在極少的情況下會(huì)發(fā)生消息(message)插隊(duì)的情況.即clientA發(fā)送給服務(wù)器數(shù)據(jù)123456789,同時(shí)clientB發(fā)送給服務(wù)器987654321.但是服務(wù)器收到的數(shù)據(jù)是123459876543216789,即clientB的數(shù)據(jù)包插入在clientA數(shù)據(jù)包內(nèi).導(dǎo)致解析出錯(cuò).
請(qǐng)問下此情況是不是跟gateway非阻塞模式有關(guān)?
如果我將gateway->count調(diào)整至1是不是可以解決這個(gè)問題?
另外,如果gateway非阻塞模型在多進(jìn)程高并發(fā)數(shù)據(jù)通訊的情況下會(huì)有消息插隊(duì)問題,怎樣才能有一個(gè)相對(duì)完備的方案?
謝謝!
8個(gè)回答
gateway使用的tcp協(xié)議,socket數(shù)據(jù)"粘包"我已經(jīng)通過程序處理,但是這種插隊(duì)問題感覺無法通過程序代碼解決
- 暫無評(píng)論
打賞
我在event.php中的onMessage函數(shù)里面每個(gè)$message記錄了下來,之前所說的數(shù)據(jù)包"插隊(duì)"問題的場(chǎng)景是這樣的:
有兩個(gè)客戶端同時(shí)向服務(wù)器不停的發(fā)送數(shù)據(jù),架設(shè)兩個(gè)客戶端在一段時(shí)間內(nèi)都向服務(wù)器發(fā)送了3個(gè)數(shù)據(jù)包.在一些情況下客戶端A會(huì)將數(shù)據(jù)以2.5+0.5的方式發(fā)送,即$message中現(xiàn)接受到A的2.5個(gè)數(shù)據(jù)包,然后接收0.5個(gè)剩余數(shù)據(jù)包.但同時(shí)客戶端B向服務(wù)器連續(xù)發(fā)送了3個(gè)數(shù)據(jù)包(按照1+1+1)方式.
最終在onMessage函數(shù)里面每個(gè)$message的順序?yàn)? 2.5(A) 1(B) 1(B) 1(B) 0.5(A).就是我說的插隊(duì)現(xiàn)象.
- 暫無評(píng)論
原先我在每個(gè)數(shù)據(jù)包頭中增加了長(zhǎng)度來處理粘包問題.現(xiàn)在想來那只是針對(duì)單個(gè)sock_id才有用,對(duì)于現(xiàn)在多個(gè)客戶端同時(shí)推送服務(wù)器信息的情景.可能需要對(duì)每個(gè)sock_id設(shè)置獨(dú)立的緩沖區(qū).
假如我按照你的建議寫一個(gè)協(xié)議,是否可以解決我說的問題?
- 暫無評(píng)論
補(bǔ)充一下,不知道我表達(dá)的是否明確
架設(shè)網(wǎng)關(guān)收到的數(shù)據(jù)包順序: 2.5(A) 1(B) 1(B) 1(B) 0.5(A)
使用多連接共用緩沖區(qū)在解析第三個(gè)數(shù)據(jù)報(bào)文時(shí),會(huì)將A客戶端的0.5個(gè)報(bào)文合并到B客戶端報(bào)文上,導(dǎo)致整體出錯(cuò).
使用自定義協(xié)議的話,能否避免這個(gè)問題?
- 暫無評(píng)論
問題已經(jīng)解決,重新寫了一個(gè)協(xié)議.
原來對(duì)gateway/worker的運(yùn)行方式理解有誤導(dǎo)致,多謝指導(dǎo)哈
- 暫無評(píng)論
