我要先做几点志愿者：
我是Flink的新手（和它一起工作了大约一个月）
我使用的是kinesis分析（aws托管的flink解决方案）。不管怎么说，这并没有真正限制flink的多功能性或容错选项，但我还是要说出来。
我们有一个相当直接的滑动窗口应用程序。密钥流通过特定的密钥（例如ip地址）组织事件，然后在processorfunction中处理它们。我们主要用它来记录事物的数量。例如，过去24小时内某个特定ip地址的登录次数。每隔30秒，我们计算窗口中每个键的事件数，并将该值保存到外部数据存储中。状态也会更新以反映该窗口中的事件，以便旧事件过期并且不会占用内存。
有趣的是，基数不是问题。如果我们有20万人登录，在24小时内，一切都是完美的。当一个ip在24小时内登录20万次时，事情开始变得棘手起来。此时，检查站的时间开始越来越长。一个普通的检查点需要2-3秒，但是在这种用户行为下，检查点开始需要5分钟，然后10分钟，然后15分钟，然后30分钟，然后40分钟，以此类推。
令人惊讶的是，应用程序可以在这种情况下平稳运行一段时间。大概10到12个小时。但是，检查点迟早会完全失败，然后我们的最大迭代器年龄开始激增，没有新的事件被处理等等。
在这一点上，我尝试了一些方法：
向问题投掷更多金属（同时启用自动缩放）
对检查点之间的间隔和最小次数的检查大惊小怪https://docs.aws.amazon.com/kinesisanalytics/latest/apiv2/api_checkpointconfiguration.html
重构以减少存储状态的占用
（1） 其实做的不多(2） 这似乎有帮助，但随后又出现了一个更大的流量高峰，而我们之前看到的情况压榨了任何好处（3）目前尚不清楚这是否有帮助。我认为我们的应用程序内存占用比你想象的yelp或airbnb都使用flink集群来处理大规模应用程序的内存占用要小，所以我不能想象我的状态真的有问题。
我想说的是，我希望我们不必对应用程序输出的期望进行深刻的改变。这个滑动窗口是非常有价值的数据。
编辑：有人问我的状态看起来是什么样的valuestate[foostate]

case class FooState(
                         entityType: String,
                         entityID: String,
                         events: List[BarStateEvent],
                         tableName: String,
                         baseFeatureName: String,
                       )

case class BarStateEvent(target: Double, eventID: String, timestamp: Long)

编辑：我想强调一下用户davidanderson在评论中说的话：
有时用于实现滑动窗口的一种方法是使用mapstate，其中键是切片的时间戳，值是事件列表。
这是必要的。对于其他试图走这条路的人来说，我找不到一个可行的解决方案，不把事件分成一些时间段。我的最终解决方案是将事件分成30秒的批，然后按照david的建议将它们写入map状态。这似乎很管用。对于我们的高负载时期，检查点保持在3mb，它们总是在不到一秒钟的时间内完成。