關(guān)于斷線重連的問題
想請教一個(gè)斷線重連的問題 //項(xiàng)目模擬代碼 ws = new WebSocket('ws://127.0.0.1:8282'); ws.onmessage = function(e){ .... } //心跳 function ping(ws) { time = 3000; setInterval(function () { ws.send('{"type":"ping"}')...
用workerman代替redis
redis優(yōu)點(diǎn)主要是內(nèi)存讀取和本地持久化，但提供的數(shù)據(jù)類型太簡單，只能字符串和一維key的操作。所以做做簡單的存儲和并發(fā)檢索還是可以的，但是要想更復(fù)雜的功能，我們就要基于redis做封裝。 那么，如果用workerman來開發(fā)仿造一個(gè)redis，php-frm直接連接worker進(jìn)程中的內(nèi)存變量，兩者都是常駐內(nèi)存，數(shù)據(jù)也都是在內(nèi)存中的，就像Gateway::bindUid一樣的原理，豈不是更爽。 暫且不管redis的...
Events判斷從哪個(gè)協(xié)議進(jìn)來的
一個(gè)BusinessWorker對應(yīng)多個(gè)geteway時(shí)，如何在Events.php中知道geteway是什么協(xié)議方式？...
求助，多進(jìn)程定時(shí)器+多進(jìn)程異步，邏輯亂套了
進(jìn)程A和B都設(shè)置了5個(gè)子進(jìn)程，進(jìn)程A里放了一個(gè)定時(shí)器，同一時(shí)間去redis中查詢5條數(shù)據(jù)并立刻批量刪除，然后調(diào)用AsyncTcpConnection執(zhí)行進(jìn)程B，redis是用的zset類型。 問題： 1、redis雖然是單進(jìn)程，但是因?yàn)?個(gè)定時(shí)器同時(shí)執(zhí)行了進(jìn)程A，導(dǎo)致redis還沒刪除之前，就被其他子進(jìn)程也查詢到了值，導(dǎo)致進(jìn)程A有幾率會(huì)執(zhí)行2~3次，但我只想讓進(jìn)程A執(zhí)行一次。我知道可以設(shè)置$worker->id...
在websocket的onWorkerStart方法中，能否發(fā)送send到客戶端？
需求是這樣的，在onWorkerStart中，定時(shí)檢測并異步執(zhí)行耗時(shí)任務(wù)，當(dāng)有客戶端連接ws時(shí)，可以實(shí)時(shí)獲取該進(jìn)程任務(wù)的執(zhí)行日志。 目前我采用的方案是文件和redis這樣的中間件。我在想，既然timer和websocket同屬于一個(gè)進(jìn)程，那么能否不用中間件，直接在onWorkerStart里發(fā)送send給客戶端呢？...
跪求，郵件群發(fā)如何提高效率？
由于郵件發(fā)送比較耗時(shí)，所以我用AsyncTcpConnection異步任務(wù)，但由于workerman是多進(jìn)程單線程，那么在如下場景中，該如何提高并發(fā)效率呢？ 場景： 有2個(gè)耗時(shí)任務(wù)需要在同一時(shí)間執(zhí)行，其中一個(gè)是郵件群發(fā)，假設(shè)要發(fā)送1000個(gè)郵件，任務(wù)進(jìn)程100個(gè)。 方案疑問： 1、1000個(gè)郵件分別通過AsyncTcpConnection發(fā)送給100個(gè)進(jìn)程。這種方案會(huì)因?yàn)?00個(gè)進(jìn)程被占滿，而導(dǎo)致另一個(gè)任務(wù)必須等待1...
求解，windows下，開啟了多進(jìn)程，協(xié)議還是堵塞的原因
不知道哪里寫的不對，設(shè)置了4個(gè)進(jìn)程，同時(shí)打開3個(gè)網(wǎng)頁，每個(gè)等待10s，結(jié)果總時(shí)長需要30s，求大神幫忙解釋下，謝謝了 下圖是http: 下圖是websocket ...
gatewayworker每次重啟，client_id都是從固定的1開始
下面兩個(gè)圖是我分別重啟后截圖，默認(rèn)都是從client_id=1開始遞增。 這樣是不是一旦項(xiàng)目上線后，就不能關(guān)閉重啟了，只能通過平滑重啟，不然clietn_id與數(shù)據(jù)庫的uid對不上了？或者有沒有其他解決辦法？ 查看源碼發(fā)現(xiàn)，client_id是通過ip+端口+connection_id的16進(jìn)制，connection_id是當(dāng)前連接數(shù)，所以workerman重啟后，connection_id就從1重新開始計(jì)算了。 /...
