AWS Kinesis Stream检查点

时间:2018-10-15 21:44:07

标签: amazon-web-services amazon-kinesis checkpoint amazon-kcl

我有一个能够处理重复的Kinesis流记录的应用程序。我们正在考虑在处理故障方面可以采取的方法。并提出了以下方法:

如果在processRecords期间捕获到异常,则该应用程序不检查点。这样,记录将与下一批记录一起再次发送,间接执行重试。

所以我的问题是-当涉及Kinesis流的检查点时,应用程序是否应始终定期检查点?操纵检查点机制是否被视为反模式?

谢谢

1 个答案:

答案 0 :(得分:0)

我想首先澄清一些有关检查点的问题,这可能会改变您的观点。除非我彻底误解了您的问题,否则它不是在“操纵”检查点机制,而是在“将其用于预期目的”。

  • 检查点本质上是一种机制,允许您从最后一个检查点位置(而不是最早的可用记录或“现在”)重新开始流处理。
  • 跳过检查点并不自动意味着下一批将自动重试记录-您需要通过在错误发生之前从某个流位置重新启动记录处理器来处理该异常(通常是“最后一个检查点”,以这样做) 。

通常,目标是使用Kinesis来推动有用的处理-通常,重新处理重复的记录是无用的(仅花费您的钱,就付给了AWS)。检查点通常意味着减少处理重复记录的时间和金钱。

您可以在时间基准(每X秒),记录基准(每Y个记录),每批,从不或任何您想要的点上进行检查-这取决于在发生以下情况时您可以容忍多少浪费失败。

注意:请记住,检查点机制是由DynamoDB表支持的,因此有一些较小的开销(确保您具有足够的表吞吐量)来频繁执行此操作。