amazon-web-services - AWS Kinesis Stream 检查点

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

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

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

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

谢谢

最佳答案

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

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

  • 一般来说,目标是使用 Kinesis 来驱动有用的处理 - 通常重新处理重复记录是没有用的(并且只是花钱,支付给 AWS)。检查点通常意味着更少的时间和金钱浪费在重新处理重复记录上。

    您可以基于时间(每 X 秒)、基于记录(每 Y 条记录)、每批、从不或任何您想要的检查点 - 这一切都取决于在发生故障时您可以容忍多少浪费。

    注意:请记住,检查点机制由 DynamoDB 表支持,因此过于频繁地执行此操作会产生一些小成本(确保您有足够的表吞吐量)。

    关于amazon-web-services - AWS Kinesis Stream 检查点,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/52825171/

    相关文章:

    C# BackgroundWorker 取消检查点缩短

    r - unloadNamespace(package) : namespace 'MASS' is imported by 'vegan' so cannot be unloaded 中的错误

    javascript - 在 JavaScript 中存储执行状态?可以稍后恢复吗?

    amazon-web-services - AWS : Mounting a template disk with Batch/ECS

    mysql - 20-30 个并发 mysql 连接导致 RDS 飙升至 80% 以上

    java - 强制删除使用带版本号的乐观锁的表

    amazon-web-services - AWS Elastic Beanstalk - 实例之间的共享计数器变量

    java - AmazonKinesisClient 构造函数已弃用

    amazon-web-services - AWS Lambda 执行持续时间随机激增并导致超时

    node.js - 更改 aws kcl 的故障转移时间