本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 搜尋寫入限流
為了維持最佳效能和資料耐久性，ElastiCache 在**耐用模式下**會在必要時對搜尋流量實作寫入限流。調節有助於確保自動備份機制有效運作，而不會在高寫入活動期間落後。透過暫時降低寫入輸送量，系統會保留多可用區域交易日誌的完整性，這對於快速資料庫復原和重新啟動至關重要。
## 限流範圍
只有以屬於搜尋索引的索引鍵為目標的寫入命令才會受到調節。寫入非索引金鑰和所有讀取命令**不**受影響。
下列命令在以索引鍵為目標時受到限流：
**受搜尋寫入限流影響的命令**
| Category | 命令 |
| --- | --- |
| 雜湊 | HSET, HSETNX, HMSET, HINCRBY, HINCRBYFLOAT, HDEL |
| JSON | JSON.SET, JSON.DEL, JSON.NUMINCRBY, JSON.NUMMULTBY, JSON.STRAPPEND, JSON.ARRAPPEND, JSON.ARRINSERT, JSON.ARRPOP, JSON.ARRTRIM, JSON.TOGGLE, JSON.CLEAR, JSON.MERGE |
| 一般 | DEL, UNLINK, RENAME, RENAMENX, COPY, RESTORE |
## 用戶端體驗到什麼
調節的命令會**延遲，不會遭到拒絕**。受影響的寫入需要更長的時間才能完成，但仍然成功。用戶端不會傳回任何錯誤。
您可以透過下列 Amazon CloudWatch 指標觀察影響：
+ `SuccessfulWriteRequestLatency` 和 `SearchBasedSetCmdsLatency` — 反映受影響寫入的延遲增加。
+ `SearchWriteThrottleActive`、 `SearchWriteThrottledClientsCount`和 `SearchWriteThrottleEvents` — 指出限流是否處於作用中狀態，以及程度為何。如需詳細資訊，請參閱 [監控](#Durability.SearchThrottling.Monitoring)。
## 限流啟用時
系統會在 2 小時的滾動時段監控搜尋模組寫入器執行緒的 CPU 用量。當該時段的平均 CPU 用量超過 50% 時，調節會啟用 ，並調整允許的寫入速率，將平均使用率恢復為 50%。
因為指標是在 2 小時的時段內平均，所以只要在同一時段內受到較低的用量所偏移，短暫的高載 CPU 用量不會自行觸發限流。
為了防止過度調節，系統也會即時評估目前的 CPU 用量。如果目前的 CPU 用量已達 50% 或以下，即使 2 小時平均值仍高於閾值，系統仍會保持穩定的寫入率，而不是進一步降低寫入率。這可確保寫入容量永遠不會低於正常輸送量的 50%。
## 調節停用時
一旦 2 小時的平均 CPU 用量降至 50% 以下，系統會逐漸增加允許的寫入速率，直到完全輸送量還原且限流停用為止。
## 監控
下列 Amazon CloudWatch 指標可用於監控搜尋寫入限流：
**搜尋寫入限流 CloudWatch 指標**
| 指標 | 說明 | 單位 |
| --- | --- | --- |
| SearchWriteThrottleActive | 指出限流目前是否作用中。 1 = 作用中， 0 = 非作用中。 | Boolean |
| SearchWriteThrottledClientsCount | 目前正在調節的用戶端連線數目。 | 計數 |
| SearchWriteThrottleEvents | 報告間隔內的調節事件數量。 | 計數 |
| SearchWriteCPUUtilization | 搜尋寫入器執行緒的目前 CPU 使用率。 | 百分比 |
## 最佳實務
+ **監控 `SearchWriteCPUUtilization`** — 追蹤搜尋寫入 CPU 用量，以了解工作負載模式，並預測何時可能接近限流閾值。
+ **監控 `SearchWriteThrottleActive`** — 追蹤限流是否處於作用中狀態，以便您可以立即調查和回應。
+ **規劃 2 小時時段的持續擷取** — 系統使用 2 小時滾動平均值，因此只要在同一時段內受到較低的用量偏移，就能完全支援高寫入活動的短暫暴增。
+ **如果您觀察到持續或頻繁的限流** - 如果您的工作負載持續超過閾值，且限流影響應用程式的延遲需求，請考慮擴展以增加容量。