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

# 改进低延迟处理
<a name="kinesis-low-latency"></a>

*传播延迟*定义为从记录写入流的那一刻起到消费者应用程序读取该记录的 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 每个分片具有每秒 5 次 `GetRecords` 调用的限制，因此将 `idleTimeBetweenReadsInMillis` 属性设置为少于 200ms 可能导致您的应用程序观察到 `ProvisionedThroughputExceededException` 异常。如果这类异常过多，则可能导致指数退避，并因此导致处理过程中出现重大的意外延迟。如果您将此属性设置为 200 ms 或更大并且具有多个正在处理的应用程序，则会遇到类似的限制。