建行采用Flink的第一个方案是什么？

第一个方案采用滑动窗口，当请求响应到达之后，先把它分开再提取唯一业务标识，然后再做一次 keyBy。因 为这里存在一个前后到达的问题，有可能是请求先来，也有可能是响应先来，所以采用了一个 10 秒钟的滑动 窗口，5 秒钟滑一次。如果请求来了响应能够在 5 秒之内到达，就能在窗口内连接上并直接进行业务操作输出； 如果 5 秒内没有到达，就要把状态提取出来存到 Redis 中做等待。等下一次响应来了，它就会先去 Redis 上根据业务标识去查看有没有请求，如果有，就拿出来再进行业务操作和业务处理。也就是把请求和响应先做一次连接，然后把连接上的请求响应和埋点再做一次连接，相当于做了两次实时 join，并把 Redis 作为状态存储， 将没有连接上的消息存放在里面。但是这会导致一些缺点：

• 吞吐量低。随着数据接入的消息越来越多，Flink 设置的并行度就要越来越大，使用的 Redis 连接数请求 也会越来越多，受限于 Redis 的吞吐量和连接数限制，达到一个阈值之后就会限制整体的吞吐量；

• Redis 运维压力大。数据量大了之后，没有连接上的数据就会越来越多，Redis 很快就会满了。为了保证 稳定性就需要做一些手动的清除；

• 需要手动在 Flink 里面写一些额外的代码与 Redis 进行交互；

• Redis 的状态积压变大，会导致里面的参数或者数据过期，或者被挤出。

以上内容摘自《Apache Flink 案例集（2022版）》电子书，点击https://developer.aliyun.com/ebook/download/7718 可下载完整版