問題描述

如題，按照串行開發(fā)推薦，在onworkerstart中創(chuàng)建了一個(gè)mysqli連接對(duì)象，在onmessage中使用這個(gè)對(duì)象。執(zhí)行沒有問題，因?yàn)閛nmessage是串行執(zhí)行的，workerman會(huì)在這個(gè)onmessage執(zhí)行完以后再進(jìn)行下一個(gè)響應(yīng)。

現(xiàn)在由于需要請(qǐng)求api，使用了workerman/http-client，但是搞不懂它的原理是怎么實(shí)現(xiàn)異步非阻塞的(我沒有使用coroutine)，我在workerman/http-client中的請(qǐng)求回調(diào)匿名函數(shù)中需要使用這個(gè)之前在onworkerstart中創(chuàng)建的mysqli對(duì)象。我現(xiàn)在擔(dān)心如果workerman/http-client正在等待api返回，此時(shí)workerman又收到一個(gè)請(qǐng)求，在這個(gè)新請(qǐng)求中使用了這個(gè)mysqli對(duì)象，此時(shí)很可能api返回成功，觸發(fā)匿名回調(diào)函數(shù)，又使用了這個(gè)mysqli對(duì)象。會(huì)不會(huì)造成資源競(jìng)爭(zhēng)？

注:這個(gè)mysqli對(duì)象是自己寫的類，對(duì)mysqli進(jìn)行二次封裝，只是里面有幾個(gè)函數(shù)，一個(gè)SQL構(gòu)建器(因?yàn)樾枰l繁select一個(gè)特定的場(chǎng)景)，其余與官方mysqli無(wú)二。調(diào)用流程是set參數(shù)-》buildSQL-》execute-》getdata.我擔(dān)心在下一個(gè)onmessage中執(zhí)行了set參數(shù)到execute之間的任何一步，此時(shí)回到回調(diào)函數(shù)中會(huì)毀掉這個(gè)onmessage中在mysqli對(duì)象中設(shè)置的數(shù)據(jù)，當(dāng)然我也擔(dān)心下一個(gè)onmessage中的set參數(shù)到execute之間的任何一步毀掉回調(diào)函數(shù)所在的那個(gè)onmessage中的時(shí)候設(shè)置的mysqli中的參數(shù)。

為此你搜索到了哪些方案及不適用的原因

沒有找到workerman/http-client與mysqli相關(guān)的問題。大家好像都用thinkorm。(官方也推薦使用)。
但是小型項(xiàng)目沒必要使用連接池，私認(rèn)為連接池所帶來(lái)的消耗與開發(fā)難度所帶來(lái)的那點(diǎn)優(yōu)化，以及所帶來(lái)的coroutine心智負(fù)擔(dān)還不如優(yōu)化一下SQL慢查詢:)

希望大神幫忙解惑,指點(diǎn)一下:)

更新

重新包裝了一下類，拆出一個(gè)類專門保存mysqli連接對(duì)象以及賬號(hào)密碼以及重連函數(shù)。

然后將查詢構(gòu)建器等拆出來(lái)，然后每個(gè)onMessage中new出一個(gè)查詢構(gòu)建器對(duì)象，use這個(gè)mysqli連接對(duì)象。由于底層的mysqli是阻塞串行執(zhí)行，所以一定不會(huì)導(dǎo)致競(jìng)爭(zhēng)，且由于每個(gè)onMessage的查詢構(gòu)建器是獨(dú)立的所以不會(huì)影響。

但_Anyway,還是想知道原問題的答案:)