業(yè)務(wù)邏輯:
多個(gè)探頭通過柜子和服務(wù)器連接并通訊,一個(gè)柜子對(duì)應(yīng)一個(gè)tcp鏈接,上線時(shí)初始化數(shù)據(jù)把索要數(shù)據(jù)的命令存在session里面,然后第一次調(diào)用函數(shù)后,會(huì)進(jìn)入調(diào)用閉環(huán)一直同步數(shù)據(jù)
測試情況:
gateway和businessworker都開一個(gè)進(jìn)程,python模擬20個(gè)柜子,每個(gè)柜子下10個(gè)探頭(傳感器),每輪同步間隔為15秒,每個(gè)探頭同步間隔為1.5秒,模擬測試5分鐘,會(huì)出現(xiàn)失敗情況,用tcpdump抓包對(duì)比,發(fā)現(xiàn)柜子發(fā)送給gateway接收沒問題,但是gateway到businessworker出現(xiàn)丟包,查看狀態(tài)為busy
問題及分析:
負(fù)載和預(yù)期相差甚遠(yuǎn),之前的預(yù)期是一個(gè)進(jìn)程起碼保證1000臺(tái)柜子100%成功率的數(shù)據(jù)同步,開10個(gè)進(jìn)程負(fù)擔(dān)差不多10000臺(tái)柜子[實(shí)際可能不是這樣簡單的數(shù)學(xué)計(jì)算,大概思路這樣],但目前相差甚遠(yuǎn),才20臺(tái)柜子,5分鐘成功率就開始掉了
已采取的優(yōu)化措施:
1,因?yàn)闃I(yè)務(wù)負(fù)擔(dān)比較重,之前剝離過業(yè)務(wù)邏輯部分,效果很差,等于把壓力集中到一個(gè)地方,直接就壓垮了,完全沒法兒用,現(xiàn)在放回主進(jìn)程了,后期多開進(jìn)程,大家平均負(fù)擔(dān)[業(yè)務(wù)剝離,試過,否定]
2,目前注釋掉了觸發(fā)報(bào)警和報(bào)警恢復(fù)相關(guān)的數(shù)據(jù)庫全部操作
3,redis限制了0.5秒上線一個(gè)柜子,避免扎堆上線
4,給每輪定時(shí)器及每個(gè)探頭的定時(shí)器增加一個(gè)隨機(jī)因素,避免全部一樣的參數(shù)產(chǎn)生類似軍隊(duì)齊踏步一樣的壓力峰值
5,重試,單個(gè)探頭如失敗有3次重試機(jī)會(huì),失敗則跳過
目前已經(jīng)做了上述工作,在定時(shí)器調(diào)用方面,寫了三個(gè)版本,分別是
1,一次生成全部定時(shí)器[不是一次性的],沒有周期定時(shí)器,控制好時(shí)間差,等于一個(gè)探頭一個(gè)定時(shí)器
2,只生成周期定時(shí)器[不是一次性的],觸發(fā)后循環(huán)生成探頭定時(shí)器[一次性]
3,生成周期定時(shí)器[一次性的],觸發(fā)后循環(huán)生成探頭定時(shí)器[一次性],一個(gè)執(zhí)行完調(diào)用下一個(gè),形成調(diào)用閉環(huán),類似遞歸
經(jīng)測試第三個(gè)思路目前表現(xiàn)最好,可只是這樣,求各路大神指點(diǎn)下思路,還有哪些地方,我可以嘗試解決負(fù)載問題
“會(huì)進(jìn)入死循環(huán)一直同步數(shù)據(jù)”
業(yè)務(wù)代碼里不要有死循環(huán)
抱歉,描述不太準(zhǔn)確,應(yīng)該是調(diào)用閉環(huán),即一個(gè)定時(shí)器執(zhí)行完調(diào)起下一個(gè)
問題已解決,在老大walkor的指導(dǎo)下,定位到問題出在寫文件那里,因?yàn)橛昧税⒗镌茣r(shí)序數(shù)據(jù)庫influxDB,為了效率是以文本形式批量定時(shí)提交的,因?yàn)楹芏喙褡犹筋^的情況下頻繁的寫操作會(huì)出現(xiàn)IO阻塞導(dǎo)致busy狀態(tài),進(jìn)而導(dǎo)致gateway到businessworker的丟包問題,注釋該部分代碼達(dá)到預(yù)期效果,感謝