感覺在runAll()之前實(shí)例化mysql或者redis是可以的，因?yàn)槭莄opy on write

zhuxiaoyu 更新于2018-11-11

workerman文檔里面建議將redis或者mysql的實(shí)例步驟放到onWorkerStart里面，fork之后執(zhí)行onWorkerStart，這樣實(shí)例就是屬于這個(gè)子進(jìn)程的。
但是在測(cè)試中，我發(fā)現(xiàn)如果在runAll前實(shí)例化，這個(gè)資源數(shù)據(jù)是copy on write的，并沒有發(fā)現(xiàn)在runAll外面實(shí)例化有什么影響
測(cè)試代碼如下：

[attach]1362[/attach]
?
在id為0的子進(jìn)程中改變r(jià)edis實(shí)例，并不會(huì)影響id為1的子進(jìn)程
兩次curl請(qǐng)求，第二個(gè)請(qǐng)求redis插入不進(jìn)去
?
為了測(cè)試copy on write

[attach]1363[/attach]
兩次curl請(qǐng)求，第一個(gè)輸出5，第二個(gè)輸出10
?
可見：
1.子進(jìn)程繼承父進(jìn)程的數(shù)據(jù)，是以copy on write模型
2.在runAll實(shí)例化redis和mysql，好像并沒有什么不可
?
?
以上不知道是對(duì)是錯(cuò)

 3160  2 0

2個(gè)回答

walkor 2018-11-08

打賞

高并發(fā)下會(huì)有問題

zhuxiaoyu 2018-11-08

所以子進(jìn)程繼承父進(jìn)程的數(shù)據(jù)，是以copy on write的模式，一開始相當(dāng)于是同一個(gè)數(shù)據(jù)，在子進(jìn)程或者父進(jìn)程改變了數(shù)據(jù)，之后才會(huì)變成兩份不一樣的數(shù)據(jù)，這樣理解對(duì)吧？
zhuxiaoyu 2018-11-08

7.1以上的xdebug_debug_zval不太好用了，沒法更直觀的展現(xiàn)出copy on write

walkor 2018-11-11

打賞

比如主進(jìn)程初始化了一個(gè)mysql連接，fork后的各個(gè)子進(jìn)程會(huì)繼承主進(jìn)程的連接資源，這個(gè)資源猜測(cè)應(yīng)該不會(huì)copy on write，你會(huì)發(fā)現(xiàn)mysql服務(wù)端只看到一個(gè)連接，但是各個(gè)子進(jìn)程都有能對(duì)這個(gè)mysql連接讀寫，如果出現(xiàn)同時(shí)讀寫應(yīng)該會(huì)造成mysql連接異常。