本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 改善低延遲處理
<a name="kinesis-low-latency"></a>

*傳播延遲*的定義是自從記錄寫入串流直到消費者應用程式讀取該記錄為止的端對端延遲。此延遲依各種因素而異，但主要受消費者應用程式的輪詢間隔影響。

對於大多數應用程式，建議每個應用程式每秒輪詢每個碎片一次。這使您能夠擁有多個取用者應用程式並行處理任一串流，而不會達到 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` 屬性設為少於 200 毫秒，可能會導致您的應用程式產生 `ProvisionedThroughputExceededException` 例外狀況。這類例外狀況過多可能導致指數退避，進而造成處理過程中發生重大的意外延遲。若您將此屬性設為 200 毫秒或更久且同時有多個處理應用程式，便會遭遇到類似的調節牽制。