我的IOCP模型架构(高手请指点)

[monk2000]

业务需求：
客户端与服务器通讯，服务器根据客户端不同的业务类型的请求，对服务器端的数据库(mysql)进行读写操作，并把操作结果返回给客户端。

我的IOCP设计是开cpu*2个工作者线程，工作者线程根据客户的请求类型，进入不同的业务处理流程(查询、读写数据库)，然后返回结果给客户端。

业务流程大概有十几个，都是查询数据库的。只有一个是写数据库的，写的内容比较大，大概有4M大小。

我的问题是：我的IOCP模型是否是最优的？我觉得这个模型有一个致命的问题，就是当大量的请求是写数据库(内容4M大小)时，由于所有的工作者线程都进行写数据库处理，没有线程对其他请求进行及时响应(这些请求的完成包在完成端口队列堆积)。

我看到有人把网络请求和处理业务逻辑分开(我的网络请求和业务逻辑是一起的)，这样虽然提高了网络请求的响应速度，但是要开一个线程专门处理网络请求，每来一个请求就开一个线程处理该请求的业务。但是这样又违背了IOCP模型了。

我的IOCP模型是不是最好的？除了这样好像就没别的模型架构了啊？

[woshinia]

耗时的操作不能放在在工作者线程中，你可以把耗时的操作类型和参数之类打包成一个结构体，然后把这个结构体放入list中，再开个另外的线程，循环中list中取出来操作，这样就一共就3个线程。

[monk2000]

引用 1 楼 woshinia 的回复:

耗时的操作不能放在在工作者线程中，你可以把耗时的操作类型和参数之类打包成一个结构体，然后把这个结构体放入list中，再开个另外的线程，循环中list中取出来操作，这样就一共就3个线程。

3个线程？应该是cpu*2+1个线程吧，cpu*2个工作者线程，1个专门处理耗时业务的线程。你的意思是这样的吧？

[smwhotjay]

不想看. 网络层就干收发就完事. db是db层干的 .数量小,还不如直接远程连接db 操作完事. 比自己的实现 搞不好效率还好.

[monk2000]

引用 1 楼 woshinia 的回复:

耗时的操作不能放在在工作者线程中，你可以把耗时的操作类型和参数之类打包成一个结构体，然后把这个结构体放入list中，再开个另外的线程，循环中list中取出来操作，这样就一共就3个线程。

但是这样的话，如果耗时操作的请求同时来N个，岂不是要开N个处理耗时工作的线程，那岂不是违背了IOCP避免线程切换的初衷？

[woshinia]

引用 2 楼 monk2000 的回复:

[quote=引用 1 楼 woshinia 的回复:] 耗时的操作不能放在在工作者线程中，你可以把耗时的操作类型和参数之类打包成一个结构体，然后把这个结构体放入list中，再开个另外的线程，循环中list中取出来操作，这样就一共就3个线程。

3个线程？应该是cpu*2+1个线程吧，cpu*2个工作者线程，1个专门处理耗时业务的线程。你的意思是这样的吧？[/quote] 我的意思就是这个

[woshinia]

引用 4 楼 monk2000 的回复:

[quote=引用 1 楼 woshinia 的回复:] 耗时的操作不能放在在工作者线程中，你可以把耗时的操作类型和参数之类打包成一个结构体，然后把这个结构体放入list中，再开个另外的线程，循环中list中取出来操作，这样就一共就3个线程。

但是这样的话，如果耗时操作的请求同时来N个，岂不是要开N个处理耗时工作的线程，那岂不是违背了IOCP避免线程切换的初衷？[/quote] 同时来N个，只是list中增加了N个而已，耗时处理的线程还是一个，慢慢一个一个从list取出来做。

[淬渊阁]

完成端口模型不是说一定要限制线程的数量，你完全可以多开几个线程，维护一个线程池，在线程等待队列中的线程数量维持大于最低的线程数。只要任务数量有，CPU使用率低于某个值，线程等待队列为空，就可以创建一个线程。这样大多任务都能被执行，在根据CUP值并且线程数小于最低值来杀线程就可以了，这里最关键的是CPU的监视。任务堵塞问题没有能够完全避免的。当然用一个LIST来保存费事的任务也是可以，这样就失去了并发出了的优势。