对muduo库的一些思考

结论

以前总觉得muduo写的不错，以后用这个就可以了，但是现在看来，muduo还是有点单薄。

原因

原因是什么呢，是上次开会，老板说了一种场景。客户端C1向服务端S1发起登录请求，但是S1要先向S2请求C1是否在黑名单，S2返回数据之后S1才能响应C1的请求。

阻塞肯定是可以完成的，现在考虑的是非阻塞的情况。那么非阻塞的话，S1就不能用epoll主线程来完成这项操作。那么办法就只有通过Task扔给线程池，但是muduo的线程池是没办法传递数据进去的，也没办法告诉线程池完成对应工作之后要调哪个特定的函数。这样就导致S1的线程给S2发完请求之后就会结束，重归到线程池中。而S2回来的请求由于没有上下文，导致S1无法处理。即使S1的线程阻塞在那里等待S2的会话，那也会导致S2回消息之后S1的线程接了这个数据之后要继续做什么操作，也就是说S1的线程不知道C1在等待他的数据。

我觉着muduo是不能处理这种业务逻辑比较复杂的操作的，从他定义的Task void()就可以看出来，中间没办法传递数据进去，结果也不好传出来。

所以说muduo是一个很好的网络库，但仅仅只是一个网络库而已。

业务逻辑还需要在上面再进行封装。

解决方案：

嗯，可以在上面加一个Entity，用multiplexer来管理的那种。

具体来说就是Entity定义S1接收C1消息之后传递给S2进行验证并且将验证结果交还给C1的过程。

multiplexer用来将S2传回给S1的数据交付给对应的Entity。