摘要：对于业务处理来说，我们尽量的让某个类型的业务或者某个玩家的业务自己在1个线程上跑，这样可以减少数据的竞争，同时还可以减少线程上下文切换。毕竟通常情况下玩家自己关注自己的数据的时间更多一些。这就是一种处理线程模型的方式。（懵懵的我其实也是懵逼的）

对于业务处理来说，我们尽量的让某个类型的业务或者某个玩家的业务自己在1个线程上跑，这样可以减少数据的竞争，同时还可以减少线程上下文切换。毕竟通常情况下玩家自己关注自己的数据的时间更多一些。这就是一种处理线程模型的方式。（懵懵的我其实也是懵逼的）

这里我画一个简单的业务流程图吧。

其实也就是现在有很多个worker工人，每个工人的处理能够处理的业务类型有差别，然后我们给每个工作work打好标记，交给工厂workermanager，然后工厂根据标记去发现哪个工人该干这个活，然后就丢给具体的工人。工人去做这个事情就是了。（有股现在的程序开发就是在管理工厂一样。。。流程化作业。。。牛马哟！！！）

上面就是提交工作work的过程：

过程就是工厂找工人，然后把工作堆到工人的身边。

说到堆到工人身边，其实就是放到一个队列里面去，工人从这个队列里面按照先入先出的顺序处理这个具体的工作。就像是流水线上的工人一样，一颗颗螺丝钉在传送带上，它们都是1个1个挨着挨着到工人手里来的，工人也是按照来的顺序来处理这些螺丝的。

下面是具体数据结构和处理逻辑：

工人数据结构：

处理逻辑：

可以看出来，这就是一个标准的工厂管理。。。

有传送带（队列），有监工（业务时耗统计），还有唤醒空闲的工人活儿来的。（程序员是牛马，程序员也在创造牛马呀。。。）

一个worker线程模型大概就是这个样子。中间涉及到一些数据结构和总监工统计没有贴细节，有兴趣的可以看看(engine/work/workmanager.go · weizLj/lnzw - Gitee.com)。

下次我们可以看看上面的那个多生产者单消费者的队列（我也是参考【抄】别人的，嘿嘿），这东西真的有点意思他们都叫它mpsc。在我们这个地方因为生产者来源很广，就像工厂的客户很广一样，但是小工厂做某个业务的就那么1个人，所以是消费者就这么1个，所以就是多生产者单消费者喽！！！

好了，今日天的worker模型就这个样子吧，菜鸡播报完成，希望自己能由菜转变过来吧。。。

来源：一百科解码处