我们在平时的开发过程中，经常会遇到水平触发与边缘触发这两种IO机制的选择，常常会比较难选择。
1. 边缘触发（Edge-Triggered）
定义：
- 边缘触发只在 I/O 状态发生变化时发出通知。例如，当一个文件描述符从不可读变为可读时，边缘触发机制会发出一次通知。
优点：
-
减少通知次数：
- 边缘触发只在状态变化时发出通知，而不是在每次状态保持时重复通知。这减少了通知次数，尤其是在高频率 I/O 事件的情况下。
-
高效性：
- 边缘触发通常比水平触发更高效，因为它减少了不必要的通知次数。
-
适合高性能场景：
- 边缘触发适用于高性能网络服务器，如使用
epoll的 Linux 系统，可以处理大量并发连接。
- 边缘触发适用于高性能网络服务器，如使用
缺点：
-
需要完全处理事件：
- 应用程序必须确保在每次通知时完全处理所有 I/O 操作，否则可能会错过后续的 I/O 事件。例如，如果应用程序只读取了一部分数据而没有完全读取所有可用数据，后续的数据可能会被遗漏。
-
复杂性增加：
- 由于需要在每次通知时完全处理所有 I/O 操作，边缘触发增加了应用程序的复杂性。开发者需要更仔细地管理 I/O 操作，避免数据丢失。
-
调试困难：
- 边缘触发的行为较为复杂，调试起来相对困难，尤其是在处理大量并发连接时。
2. 水平触发（Level-Triggered）
定义：
- 水平触发在 I/O 状态保持特定水平时持续发出通知。例如，当一个文件描述符处于可读状态时，水平触发机制会持续发出通知，直到该状态发生变化。
优点：
-
简单易用：
- 水平触发更容易理解和实现，因为它持续发出通知，直到 I/O 操作完成。应用程序不需要一次性处理所有 I/O 操作，可以逐步处理。
-
可靠性高：
- 水平触发机制不容易遗漏 I/O 事件，因为只要状态保持，通知就会持续发出。这对于需要可靠处理 I/O 事件的应用程序非常重要。
-
易于调试：
- 水平触发的行为较为直观，调试起来相对容易。
缺点：
-
可能产生大量通知：
- 水平触发在 I/O 状态保持时持续发出通知，可能会产生大量不必要的通知，特别是在高频率 I/O 事件的情况下。这可能导致性能问题。
-
不适合高性能场景：
- 由于可能产生大量通知，水平触发在处理大量并发连接时可能不如边缘触发高效。
-
资源消耗：
- 水平触发可能需要更多的系统资源来处理持续的通知。
3. 比较总结
| 特性 | 边缘触发（Edge-Triggered） | 水平触发（Level-Triggered） |
|---|---|---|
| 通知次数 | 较少，只在状态变化时通知 | 较多，持续在状态保持时通知 |
| 效率 | 高效，适合高性能场景 | 可能较低，特别是在高频率 I/O 事件的情况下 |
| 复杂性 | 较高，需要完全处理每次通知 | 较低，易于理解和实现 |
| 可靠性 | 较低，需要小心处理 I/O 操作，避免遗漏事件 | 较高，不容易遗漏 I/O 事件 |
| 调试难度 | 较难，行为复杂 | 较易，行为直观 |
| 适用场景 | 高性能网络服务器，如使用 epoll 的 Linux 系统 | 需要可靠处理 I/O 事件的应用程序，如简单的文件操作、网络通信等 |
4. 应用场景
-
边缘触发：
- 适用于高性能网络服务器，如使用
epoll的 Linux 系统。 - 适用于需要处理大量并发连接的场景，如 Web 服务器、实时数据处理等。
- 适用于高性能网络服务器，如使用
-
水平触发：
- 适用于需要可靠处理 I/O 事件的应用程序，如简单的文件操作、网络通信等。
- 适用于对性能要求不高，但对可靠性要求较高的场景。
