网络模型

JProxy作为一个非常典型的代理服务，程序本身的性能非常关键，具体在实现的时候我们参考了Nginx的网络模型。

大家都知道Nginx的性能非常高，根据机器核数配置相应的worker数就可以，每个worker可以理解为围绕一个epoll把前后端的连接以完全基于事件驱动的方式串在一起，避免了上下文切换避免了锁等待等各种可能阻塞或者耗时的操作。

同样的网络模型也可以参考一下Redis的实现，redis虽然不像nginx需要考虑前后端连接的处理，但redis的模型也是一种非常类似的经典的实现方式。

JProxy整个网络模型如图所示，采用一个全局的nioacceptor以及多个nioreactor，由nioacceptor统一accept连接，之后把连接分给某个nioreactor。

nioreactor可以理解为底层就是一个epoll（java nio实现），前后端的连接都是注册在这个epoll上，我们只需要根据事件是读事件或写事件调用相应的回调函数即可。这种模型的特点是系统几乎没有太多的上下文切换，而且性能很高。

基于事件驱动的网络模型的好处是性能很高，但问题也很明显，编写时复杂度非常高，一条SQL发送过来到收到结果的上下文被切成很多片段，同一时刻有来自很多不同上下文的不同的片段要处理，全程只有一个进（线）程来处理这些片段（暂且假设NIOReactor只配置成一个），所以在实现的过程中要求把所有的细节都考虑非常周全，一旦某个片段的处理有阻塞或者耗时，整个程序都将阻塞，个人觉得这种编程方式有点反人类思维。