Amazon Kinesis Data Streams
开发人员指南
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 Amazon AWS 入门

低延迟处理

传播延迟 的定义是从将记录写入到流到使用者应用程序读取该记录的端对端延迟。此延迟会因各种因素而变化,但主要受使用者应用程序的轮询间隔影响。

对于大多数应用程序,我们建议针对每个应用程序每秒轮询每个分片一次。这使您能够具有并行处理流的多个使用者应用程序,而不会达到每秒 5 次 GetRecords 调用的 Amazon Kinesis Data Streams 限制。此外,若要处理大批量的数据,降低您的应用程序中的网络和其他下游延迟时往往更高效。

KCL 默认值被设置为遵循每 1 秒轮询一次的最佳实践。此默认值导致了通常少于 1 秒的平均传播延迟。

Kinesis Data Streams 记录在写入后便立即可被读取。有一些需要利用此延迟并且在流中的数据可用时立即需要使用它的使用案例。您可通过覆盖 KCL 默认设置来更频繁地进行轮询,从而显著降低传播延迟,如以下示例所示。

Java KCL 配置代码:

kinesisClientLibConfiguration = new KinesisClientLibConfiguration(applicationName, streamName, credentialsProvider, workerId).withInitialPositionInStream(initialPositionInStream).withIdleTimeBetweenReadsInMillis(250);

Python 和 Ruby KCL 的属性文件设置:

idleTimeBetweenReadsInMillis = 250

注意

由于 Kinesis Data Streams 具有每秒 5 次 GetRecords 调用的限制,因此将 idleTimeBetweenReadsInMillis 属性设置为少于 200ms 可能导致您的应用程序观察到 ProvisionedThroughputExceededException 异常。如果这类异常过多,则可能导致指数退避,并因此导致处理过程中出现重大的意外延迟。如果您将此属性设置为 200 ms 或更大并且具有多个正在处理的应用程序,则会遇到类似的限制。