我们通过Amazon Managed Service for Apache Flink部署了一个Flink应用程序。整个应用程序在运行时的性能符合预期。但在Flink应用程序升级期间，我们在保持吞吐量方面面临挑战。

设置：

在高级别上，这是一个真实的时间流应用程序：
业务事件将进入源Kinesis流
资料来源：使用EFO（增强扇出）轮询上述Kinesis流Flink应用程序然后处理和转换数据目标汇：这是一个自定义汇到Sagemaker功能组（您可以将其视为目标数据库）
一条记录在流水线Kinesis -> Flink -> Sagemaker Feature group (the target database)中运行时会经历大约100 - 200 ms的延迟。
下游应用程序期望记录在1秒内（原始事件进入Kinesis流后）进入目标Sagemake功能组。
我们将规模扩大到至少8个KPU。

我们面临的问题：

在新版本的Flink jar更新期间（例如，从version1.jar更新到version2.jar），我们将面临一到两分钟的停机时间。我们使用Terraform更新Flink jar s3前缀

application_code_configuration {
  code_content {
    s3_content_location {
      bucket_arn = "s3://example_bucket"
      file_key   = version2.jar       <--- update to new jar setup
    }
  }

字符串
比例放大和其他部分不会改变，只是更新了jar。
我们注意到，记录的端到端延迟（我们有一个监视器设置来监视记录在Kinesis中着陆时的延迟，直到它推到接收器时）将达到20秒或更长时间。
指标millisbehindLatest（从https://docs.aws.amazon.com/managed-flink/latest/java/metrics-dimensions.html）也将跳转到10 - 20秒或更长时间。
最终在1 - 2分钟后，两个记录的平均延迟和millisbehindLatest将恢复到正常速度。
但下游应用程序依赖于目标数据库（Sagemaker功能组）来及时填充，这将导致延迟。
我们的理解是，这是由于flink正在执行reload +重新分配kinesis分区+从检查点重新加载。所以没有数据丢失（因为数据是从检查点加载+最后一个kinesis流位置）。

我们的问题：

AWS Support提到，像我们上面看到的那样，在jar更新过程中，flink的接收/输出“较慢”是正常的。但无法提供“平均中断时间”是多少（1 - 2分钟正常吗）？
所以想知道其他用户的亚马逊托管服务的Apache Flink面临类似的问题？什么将是建议，以减少它？
我们内部认为：
我们的应用程序性质可能会导致数据输出到目标数据库（Sagemaker功能组），以包含一段时间的旧数据/新数据
在升级过程中，我们将

• 在更新过程中启动一个新的flink应用程序与旧的flink应用程序并行（蓝色/绿色）
• 新的应用程序启动后，将终止旧的flink应用程序（或只是停止它，作为下一个“绿色”在未来的更新）

这更复杂，但将减少更新的停机时间。
我们的应用程序能够承受两个flink应用程序写入同一个目标（最新记录将覆盖以前写入的一个）+可能使用旧的flink应用程序是最新记录。
但想知道其他人是否有更好的想法来做。
谢谢你，谢谢