本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
搜尋寫入限流
為了維持最佳效能和資料耐久性，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— 指出限流是否處於作用中狀態，以及程度為何。如需詳細資訊，請參閱 監控。
限流啟用時
系統會在 2 小時的滾動時段監控搜尋模組寫入器執行緒的 CPU 用量。當該時段的平均 CPU 用量超過 50% 時，調節會啟用 ，並調整允許的寫入速率，將平均使用率恢復為 50%。
因為指標是在 2 小時的時段內平均，所以只要在同一時段內受到較低的用量所偏移，短暫的高載 CPU 用量不會自行觸發限流。
為了防止過度調節，系統也會即時評估目前的 CPU 用量。如果目前的 CPU 用量已達 50% 或以下，即使 2 小時平均值仍高於閾值，系統仍會保持穩定的寫入率，而不是進一步降低寫入率。這可確保寫入容量永遠不會低於正常輸送量的 50%。
調節停用時
一旦 2 小時的平均 CPU 用量降至 50% 以下，系統會逐漸增加允許的寫入速率，直到完全輸送量還原且限流停用為止。
監控
下列 Amazon CloudWatch 指標可用於監控搜尋寫入限流：
| 指標 | 說明 | 單位 |
|---|---|---|
SearchWriteThrottleActive |
指出限流目前是否作用中。 1 = 作用中， 0 = 非作用中。 |
Boolean |
SearchWriteThrottledClientsCount |
目前正在調節的用戶端連線數目。 | 計數 |
SearchWriteThrottleEvents |
報告間隔內的調節事件數量。 | 計數 |
SearchWriteCPUUtilization |
搜尋寫入器執行緒的目前 CPU 使用率。 | 百分比 |
最佳實務
監控
SearchWriteCPUUtilization— 追蹤搜尋寫入 CPU 用量，以了解工作負載模式，並預測何時可能接近限流閾值。監控
SearchWriteThrottleActive— 追蹤限流是否處於作用中狀態，以便您可以立即調查和回應。規劃 2 小時時段的持續擷取 — 系統使用 2 小時滾動平均值，因此只要在同一時段內受到較低的用量偏移，就能完全支援高寫入活動的短暫暴增。
如果您觀察到持續或頻繁的限流 - 如果您的工作負載持續超過閾值，且限流影響應用程式的延遲需求，請考慮擴展以增加容量。
