Reactor模式
Reactor模式的核心思想是：当有IO事件发生时，通过一个统一的事件循环来分发和处理这些事件。这个事件循环通常是一个无限循环，在每一次循环中，它会阻塞等待IO事件发生，当事件发生时，它会调用相应的处理函数来处理这个事件。
Reactor模式的优点是可以处理大量的并发连接，因为所有的IO操作都是异步的。同时，由于所有的IO操作都在同一个线程中处理，因此可以避免线程切换的开销。
具体实现中，Reactor模式通常使用一个select/poll/epoll等函数来等待IO事件发生，并使用回调函数来处理IO事件。
Proactor模式
Proactor模式的核心思想是：当有IO事件发生时，通过一个IO处理器来异步处理这些事件，当处理完成后，通知应用程序。与Reactor模式不同的是，Proactor模式中，所有的IO操作都是异步的，包括读取和写入操作。
Proactor模式的优点是可以避免复杂的回调处理逻辑，提高了代码的可读性和可维护性。同时，由于IO操作是异步的，因此可以提高IO操作的效率。
具体实现中，Proactor模式通常使用异步IO操作来处理IO事件，并使用事件通知机制（如Completion Port）来通知应用程序IO操作已经完成。在Windows系统中，IOCP（IO Completion Port）是一种实现Proactor模式的高效方法。
区别和联系
总体来说，Reactor和Proactor都是用于处理异步IO操作的模式。它们的区别在于，Reactor模式中，IO事件的处理是由应用程序自己实现的，而Proactor模式中，IO事件的处理是由IO处理器来实现的。在Reactor模式中，应用程序需要提供回调函数来处理IO事件，而在Proactor模式中，应用程序只需要等待IO操作完成的通知，就可以继续执行下一步操作。
需要注意的是，Reactor和Proactor并不是对立的两种模式，它们可以结合使用来处理不同的IO场景。例如，在一个网络服务器中，可以使用Reactor模式来处理连接请求，使用Proactor模式来处理具体的数据传输。
Reactor模式
在Reactor模式中，所有的IO操作都是异步的，当有IO事件发生时，统一的事件循环会调用相应的处理函数来处理事件。下面是一个简单的Reactor模式的示例：
假设我们要实现一个简单的网络服务器，它可以同时处理多个客户端连接。我们可以使用Reactor模式来实现：
- 创建一个监听套接字，等待客户端的连接请求。
- 使用select/poll/epoll等函数来等待IO事件发生（即监听套接字的读事件），当有新的连接请求时，创建一个新的连接套接字，并将其加入到一个连接池中。
- 使用select/poll/epoll等函数来等待IO事件发生（即连接套接字的读事件），当有数据到达时，调用相应的处理函数来处理数据。
- 当连接被关闭时，从连接池中删除连接套接字。
在这个例子中，Reactor模式通过一个统一的事件循环来分发和处理IO事件，实现了高效的网络服务器。
Proactor模式
在Proactor模式中，所有的IO操作都是异步的，当有IO事件发生时，IO处理器会异步处理事件，并在处理完成后通知应用程序。下面是一个简单的Proactor模式的示例：
假设我们要实现一个简单的文件传输程序，它可以异步读取一个文件，并将读取到的数据异步写入到另一个文件中。我们可以使用Proactor模式来实现：
- 创建一个文件读取器和一个文件写入器，并使用异步IO操作来读取和写入文件。
- 当文件读取器读取到数据时，将数据发送给文件写入器，继续异步读取文件。
- 当文件写入器完成写入操作时，通知应用程序，并继续等待下一个写入操作。
在这个例子中，Proactor模式通过异步IO操作来实现文件的读写，提高了文件传输的效率和可维护性。
区别和联系
Reactor和Proactor模式都是用于处理异步IO操作的模式，它们的区别在于IO事件的处理方式不同。在Reactor模式中，IO事件的处理是由应用程序自己实现的，而在Proactor模式中，IO事件的处理是由IO处理器来实现的。Reactor模式适用于需要自定义IO事件处理逻辑的场景，例如网络服务器；而Proactor模式适用于简单的IO操作，例如文件传输。在实际应用中，我们可以根据不同的场景选择合适的模式来处理IO操作。
水平触发（Level Triggered）
水平触发是指当一个IO事件发生后，操作系统会不停地向应用程序通知该事件，直到应用程序处理完毕并将其从缓冲区中读出或写入完毕。这意味着在事件发生后，只要事件还未处理完成，操作系统就会不断地通知应用程序。
下面是一个简单的水平触发的例子：
假设我们有一个服务器程序，它需要监听多个客户端连接，并读取客户端发送的数据。使用水平触发时，当客户端发送了一条数据后，操作系统会不停地向服务器程序通知该事件，直到服务器程序将该数据从缓冲区中读取出来。
水平触发的优点是简单易用，可以充分利用CPU资源；缺点是需要应用程序自行处理事件，当事件处理时间过长时，可能会导致资源浪费。
边缘触发（Edge Triggered）
边缘触发是指当一个IO事件发生后，操作系统只会通知应用程序一次，即事件发生时刻。如果应用程序没有立即处理该事件，则操作系统不会再次通知应用程序。这意味着在事件发生后，只有当应用程序处理完毕并准备好下一次事件时，操作系统才会通知应用程序。
下面是一个简单的边缘触发的例子：
假设我们有一个服务器程序，它需要监听多个客户端连接，并读取客户端发送的数据。使用边缘触发时，当客户端发送了一条数据后，操作系统只会向服务器程序通知该事件一次，即事件发生时刻。如果服务器程序没有立即处理该事件，则下次事件发生时刻，操作系统不会再次通知服务器程序。
边缘触发的优点是可以减少不必要的事件通知，提高事件处理的效率；缺点是需要应用程序自行处理事件，对事件处理的效率和正确性有更高的要求。
总的来说，水平触发和边缘触发都有各自的优缺点，应用程序可以根据具体场景选择适合的触发方式。通常情况下，边缘触发在高并发、大数据量、高实时性等场景下表现更优秀；水平触发则更适用于一些简单的应用场景。
当操作系统检测到一个 IO 事件时，就会通知应用程序，并将该事件加入到一个事件队列中。应用程序可以通过一些系统调用（如select、epoll、kqueue等）来从事件队列中读取事件并进行处理。水平触发和边缘触发是两种不同的事件处理方式。
水平触发（Level Triggered）
水平触发是一种默认的事件处理方式。当应用程序通过系统调用从事件队列中获取事件时，操作系统会返回所有当前就绪的事件。应用程序需要一直循环调用系统调用来获取事件，并且需要持续处理事件，直到所有事件被处理完毕，否则操作系统会一直通知应用程序有未处理事件。
以下是水平触发的示意图：
代码语言：txt复制
假设事件队列中有5个事件E1，E2，E3，E4，E5需要处理，应用程序会一直循环调用系统调用，获取所有事件
，然后持续处理事件，直到所有事件被处理完毕。边缘触发（Edge Triggered）
边缘触发是一种高效的事件处理方式。当应用程序通过系统调用从事件队列中获取事件时，操作系统只返回最新的未处理事件。应用程序需要立即处理该事件，否则操作系统不会再次通知该事件，也不会通知之前的已经处理过的事件。
以下是边缘触发的示意图：
代码语言：txt复制假设事件队列中有5个事件E1，E2，E3，E4，E5需要处理，应用程序调用系统
调用获取最新的未处理事件E1，并且
立即处理该事件。当处理完E1之后，
应用程序需要再次调用系统调用来获取新的未处理事件。
如果应用程序没有处理完E1，而是等待其他事件，那么操作系统将不会
再次通知该事件，也不会通知之前的已经处理过的事件。边缘触发相比水平触发，可以有效减少事件处理次数，从而提高系统性能。但是，边缘触发也需要应用程序实现更复杂的事件处理逻辑。
需要注意的是，使用边缘触发时，应用程序需要立即处理事件，否则可能会出现事件丢失的情况。另外，边缘触发可能会引发“惊群”效应，即当一个事件触发时，所有监听同一事件的套接字都会被唤醒，这可能会导致大量的套接字同时被唤醒并争夺系统资源，从而降低系统性能。
总的来说，水平触发和边缘触发都有各自的优缺点，选择合适的触发方式需要根据具体的应用场景进行综合考虑。
