低延迟处理 - Amazon Kinesis Data Streams
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

低延迟处理

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

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

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 的限制为 5GetRecords每个分片每秒调用,将idleTimeBetweenReadsInMillis低于 200ms 的属性可能会导致您的应用程序观察ProvisionedThroughputExceededException例外。如果这类异常过多,则可能导致指数退避,并因此导致处理过程中出现重大的意外延迟。如果您将此属性设置为 200 ms 或更大并且具有多个正在处理的应用程序,则会遇到类似的限制。