使用workerman/http-client回调中使用mysqli连接对象会不会导致竞争

问题描述

如题，按照串行开发推荐，在onworkerstart中创建了一个mysqli连接对象，在onmessage中使用这个对象。执行没有问题，因为onmessage是串行执行的，workerman会在这个onmessage执行完以后再进行下一个响应。

现在由于需要请求api，使用了workerman/http-client，但是搞不懂它的原理是怎么实现异步非阻塞的(我没有使用coroutine)，我在workerman/http-client中的请求回调匿名函数中需要使用这个之前在onworkerstart中创建的mysqli对象。我现在担心如果workerman/http-client正在等待api返回，此时workerman又收到一个请求，在这个新请求中使用了这个mysqli对象，此时很可能api返回成功，触发匿名回调函数，又使用了这个mysqli对象。会不会造成资源竞争？

注:这个mysqli对象是自己写的类，对mysqli进行二次封装，只是里面有几个函数，一个SQL构建器(因为需要频繁select一个特定的场景)，其余与官方mysqli无二。调用流程是set参数-》buildSQL-》execute-》getdata.我担心在下一个onmessage中执行了set参数到execute之间的任何一步，此时回到回调函数中会毁掉这个onmessage中在mysqli对象中设置的数据，当然我也担心下一个onmessage中的set参数到execute之间的任何一步毁掉回调函数所在的那个onmessage中的时候设置的mysqli中的参数。

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

没有找到workerman/http-client与mysqli相关的问题。大家好像都用thinkorm。(官方也推荐使用)。
但是小型项目没必要使用连接池，私认为连接池所带来的消耗与开发难度所带来的那点优化，以及所带来的coroutine心智负担还不如优化一下SQL慢查询:)

希望大神帮忙解惑,指点一下:)

更新

重新包装了一下类，拆出一个类专门保存mysqli连接对象以及账号密码以及重连函数。

然后将查询构建器等拆出来，然后每个onMessage中new出一个查询构建器对象，use这个mysqli连接对象。由于底层的mysqli是阻塞串行执行，所以一定不会导致竞争，且由于每个onMessage的查询构建器是独立的所以不会影响。

但_Anyway,还是想知道原问题的答案:)