3

我正在使用 Lambda 通过 Firehose 向 Redshift 发送批量消息。根据Firehose API 文档，如果存在一些传递问题（中毒消息、端点关闭等），Firehose 将继续尝试 24 小时并删除该消息。我想在 X 次尝试失败后将失败的消息移动到另一个队列（基本上就像SQS Redrive Policy）。最好的方法是什么，最好不要交叉检查目标 Redshift 数据库？

4

2 回答 2

0

从您的链接中，我假设您有兴趣将 PutRecord 的故障跟踪到 Firehose Kinesis 流，而不是 Kinesis -> S3 -> Redshift 流。

初始化 Firehose 客户端时，您实际上可以指定要发生的重试次数。当收到异常时（未能将 PutRecord 放入流中），Firehose 将自动尝试达到您设置的最大重试次数；这是在 SDK 的底层完成的，因此在异常冒泡到您的函数之前，您不会知道您的重试次数已超过。当您收到此异常时，您可以假设已超出重试次数。这种异常处理可以包括将消息发送到 SQS 队列。

您可以在此处了解有关 Firehose 客户端配置的更多信息，它并不为人所知，但非常有用。Firehose 客户端配置。

于 2016-02-28T01:53:20.890 回答
0

这可以通过以下方式以不同的方式安静地完成，而不是从消防软管直接进行。

  1. 你可以让你的 lambda 函数调用 firehose 来写入 S3。
  2. 创建从 firehose 读取的 kinesis 分析。
  3. 根据 kinesis 分析配置不同的流
    1. 成功的记录（流内）将移动到将加载到 redshift 中的 firehose。
    2. 错误记录（错误流）将被加载到另一个将加载到 S3 中的 firehose。

您将成功的记录加载到 redshift 中，将不成功的记录过滤到 S3。

这是我们遵循的一种方法，如果您需要对此进行任何澄清，请告诉我。

于 2017-09-05T17:10:38.933 回答