【问题标题】:Kinesis max shard reads/sec and multiple consumersKinesis max shard reads/sec 和多个消费者
【发布时间】:2017-10-16 04:20:20
【问题描述】:

所以我有一个 AWS Kinesis 流,我在其中为多个消费者发布事件。对他们中的大多数人来说,接收热点数据很重要——这意味着他们中的许多人可能会同时轮询和读取最新数据。根据 AWS 文档,增加分片数量将提高并行度,而每秒读取次数最多可以达到每个分片 5/秒。我的问题是添加更多分片是否(以及如何?)有助于我所有消费者都是最新的并尝试从同一个分片读取新传入数据的情况?似乎每秒读取次数限制会自动限制您可以拥有的消费者数量(至少在需要随时更新时),还是我遗漏了什么?

【问题讨论】:

    标签: amazon-web-services sharding amazon-kinesis


    【解决方案1】:

    是的,你是对的。

    在消费者中,我假设您将使用 Amazon Kinesis Client(或 KCL:amazon-kinesis-client)作为 API 助手;请看一下消费者逻辑中有一个参数“idleTimeBetweenReadsInMillis”。这定义了您的应用程序将轮询多少流(此值越低,您的应用程序将更频繁地轮询)。

    无论您的流包含 1 个分片还是 100 个分片,您每秒都不能为每个分片发出超过 5 个“GetRecords”请求。那就是;

    • 如果您有 1 个应用程序,则最多可以将轮询间隔设置为 200 毫秒(理论上)。
    • 如果您有 2 个应用程序,则最短为 400 毫秒。
    • 如果您有 3 个应用程序,则最短为 600 毫秒。
    • 或者使用您的 3 个应用程序,其中两个可以以 1000 毫秒的速度轮询,最后一个可以以 333 毫秒的速率进行轮询。

    您还可以为自己创建一个 Kafka 集群并对其性能进行基准测试。 Kafka 可能会提供更高的吞吐量。

    有关 Kafka 和 Kinesis 概念之间的示例比较,请参阅此答案:Kafka like offset on Kinesis Stream?

    【讨论】:

      【解决方案2】:

      另一种替代架构是让您拥有一个 kinesis 消费者应用程序,它将消息从 kinesis 流推送到 SNS 主题。当然,如果您的消费者需要“回顾”过去的消息进行处理,这可能行不通,但只是想把它作为一种选择扔掉。

      【讨论】:

        猜你喜欢
        • 2023-03-31
        • 2016-04-02
        • 1970-01-01
        • 1970-01-01
        • 2018-08-20
        • 2015-10-23
        • 2018-06-20
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多