在使用Flink处理流式数据的过程中，会经常和外部系统进行数据交互。通常情况下在 Flink 中可以创建外部数据库系统的Client连接，然后通过Client连接将数据元素写入外部存储系统中或者从外部存储系统中读取数据。考虑到连接外部系统的网络等因素，这种同步查询和操作数据库的方式往往会影响整个函数的处理效率，用户如果想提升应用的处理效率，就必须考虑增加算子的并行度，这将导致大量的资源开销。

Flink在1.2版本中引人了Asynchronous IO，能够支持通过异步方式连接外部存储系统，以提升Flink系统与外部数据库交互的性能及吞吐量，但前提是数据库本身需要支持异步客户端。

异步IO可以提升性能和吞吐量，主要原因是在异步函数中可以尽可能异步并发地查询外部数据库。在异步IO中需考虑对数据库查询超时以及并发线程数控制两个因素。有两个重要参数：

• Timeout是定义Asynchronous 请求最长等待时间，超过该时间Fink将认为查询数据超时而请求失败，避免因请求无法控时返回导致系统长时间等待的情况，对于超时的请求可以通过复写AsyncFunction中的timeout 方法来处理。
• Capacity定义在同一时间点异步请求并发数，一旦Capacity定义的请求数被耗尽，Flink会直接触发反压机制来抑制上游数据的接人，从而保证Flink系统的正常运行。

使用异步IO方式进行数据输出，其输出结果的先后顺序有可能并不是按照之前原有数据的顺序进行排序，因此在Flink异步I0中，需要用户显式指定是否对结果排序，这也影响着结果的顺序和系统性能:

• 乱序模式:异步查询结果输出中，原本数据元素的顺序可能会发生变化，请求且完成就会输出结果，可以使用**AsyncDataStream.unorderedWait(.)**方法应用这种模式。如果系统同时选择使用ProcessTime特征具有最低的延时和负载。
• 顺序模式:异步查询结果将按照输人数据元素的顺序输出，原本Steam数据元素的顺序保持不变，这种情况下具有较高的时延和负载，因为结果数据需要在Operator的Buffer中进行缓存，直到所有异步请求处理完毕，将按照原来元素顺序输出结果，这也将对Checkpointing过程造成额外的延时和性能损耗。可以使用**AsyncDataStream.orderedWait(.)**方法使用这种模式。

另外在使用Event-Time时间概念处理流数据的过程中，Asynchronous IO Operator总能够正确保持Watermark的顺序，即使使用乱序模式，输出Watermark也会保持原有顺序，但对于在Watermark之间的数据元素则不保持原来的顺序，也就是说如果使用了Watermark，将会对异步I0 造成一定的时延和开销，具体取决于 Watermark的频率，频率越高时延越高同时开销越大。