程序员瓶颈突破架构师?架构设计的理论与实践

每个程序员都有一个成为架构师的梦想，奈何手里无枪无法点燃心中奇梦。本系列文章分享如何让你手里有枪，只要努力，技术的梦想一定能实现，这应该是众多梦想中离地表最近的一个。

单Reactor单进程/线程

单Reactor单进程/线程的方案示意图如下（以进程为例）：

注意，select、accept、read、send是标准的网络编程API，dispatch和“业务处理”是需要完成的操作，其他方案示意图类似。
详细说明一下这个方案：

• Reactor对象通过select监控连接事件，收到事件后通过dispatch进行分发
• 如果是连接建立的事件，则由Acceptor处理，Acceptor通过accept接受连接，并创建一个Handler来处理连接后续的各种事件
• 如果不是连接建立事件，则Reactor会调用连接对应的Handler（第2步中创建的Handler）来进行响应
• Handler会完成read->业务处理->send的完整业务流程

单Reactor单进程的模式优点就是很简单，没有进程间通信，没有进程竞争，全部都在同一个进程内完成。但其缺点也是非常明显，具体表现有：

• 只有一个进程，无法发挥多核CPU的性能；只能采取部署多个系统来利用多核CPU，但这样会带来运维复杂度，本来只要维护一个系统，用这种方式需要在一台机器上维护多套系统
• Handler在处理某个连接上的业务时，整个进程无法处理其他连接的事件，很容易导致性能瓶颈

因此，单Reactor单进程的方案在实践中应用场景不多，只适用于业务处理非常快速的场景，目前比较著名的开源软件中使用单Reactor单进程的是Redis。
Redis是基于内存的数据库，在处理业务会非常快，所以不会对IO读写进行过长时间的阻塞，但是如果Redis开启同步持久化后，业务处理会变慢，阻塞了IO线程，也就无法处理更多的连接了。
Redis不太适合有的key的value特别大，这种情况会导致整个redis变慢，这种场景mc更好。
需要注意的是，C语言编写系统的一般使用单Reactor单进程，因为没有必要在进程中再创建线程；
而Java语言编写的一般使用单Reactor单线程，因为Java虚拟机是一个进程，虚拟机中有很多线程，业务线程只是其中的一个线程而已。

单Reactor多线程

为了克服单Reactor单进程/线程方案的缺点，引入多进程/多线程是显而易见的，这就产生了第2个方案：单Reactor多线程。
单Reactor多线程方案示意图是：

介绍一下这个方案：

• 主线程中，Reactor对象通过select监控连接事件，收到事件后通过dispatch进行分发
• 如果是连接建立的事件，则由Acceptor处理，Acceptor通过accept接受连接，并创建一个Handler来处理连接后续的各种事件
• 如果不是连接建立事件，则Reactor会调用连接对应的Handler（第2步中创建的Handler）来进行响应
• Handler只负责响应事件，不进行业务处理；Handler通过read读取到数据后，会发给Processor进行业务处理
• Processor会在独立的子线程中完成真正的业务处理，然后将响应结果发给主进程的Handler处理；Handler收到响应后通过send将响应结果返回给client

单Reator多线程方案能够充分利用多核多CPU的处理能力，但同时也存在下面的问题：

• 多线程数据共享和访问比较复杂。
  例如，子线程完成业务处理后，要把结果传递给主线程的Reactor进行发送，这里涉及共享数据的互斥和保护机制。
  以Java的NIO为例，Selector是线程安全的，但是通过Selector.selectKeys() 返回的键的集合是非线程安全的，对selected keys的处理必须单线程处理或者采取同步措施进行保护。
• Reactor承担所有事件的监听和响应，只在主线程中运行，瞬间高并发时会成为性能瓶颈

不存在“单Reactor多进程”方案，主要原因在于如果采用多进程，子进程完成业务处理后，将结果返回给父进程，并通知父进程发送给哪个client，这是很麻烦的事情。
因为父进程只是通过Reactor监听各个连接上的事件然后进行分配，子进程与父进程通信时并不是一个连接。
如果要将父进程和子进程之间的通信模拟为一个连接，并加入Reactor进行监听，则是比较复杂的。
而采用多线程时，因为多线程是共享数据的，因此线程间通信是非常方便的。虽然要额外考虑线程间共享数据时的同步问题，但这个复杂度比进程间通信的复杂度要低很多。