本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 搜索写入限制
为了保持最佳性能和数据持久性， ElastiCache 在**持久模式下**，必要时会对搜索流量实施写入限制。节流有助于确保自动备份机制有效运行，而不会在高写入活动期间落后。通过暂时降低写入吞吐量，系统可以保持 Multi-AZ 事务日志的完整性，这对于数据库的快速恢复和重启至关重要。
## 限制范围
只有针对属于搜索索引的键的写入命令才会受到限制。对非索引密钥的写入和所有读取命令**不受**影响。
以下命令在以索引键为目标时会受到限制：
**受搜索写入限制的命令**
| 类别 | 命令 |
| --- | --- |
| 哈希 | 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= 非活动状态。 | 布尔值 |
| SearchWriteThrottledClientsCount | 当前受限制的客户端连接数。 | 计数 |
| SearchWriteThrottleEvents | 报告间隔内的限制事件数量。 | 计数 |
| SearchWriteCPUUtilization | 搜索写入器线程的当前 CPU 利用率。 | 百分比 |
## 最佳实践
+ **监控 `SearchWriteCPUUtilization`** — 跟踪您的搜索写入 CPU 使用率，以了解您的工作负载模式并预测何时可能接近限制阈值。
+ **监控 `SearchWriteThrottleActive`**-跟踪限制是否处于活动状态，以便您可以进行调查并及时做出响应。
+ **在 2 小时左右计划持续摄取 — 系统使用 2 小时**的滚动平均值，因此，只要在同一时间段内较低的使用量抵消短暂的高写入活动，就可以完全支持短暂的高写入活动。
+ **如果您观察到持续或频繁的限制，则可以扩展集群** — 如果您的工作负载持续超过阈值并且限制会影响应用程序的延迟要求，请考虑通过扩展来增加容量。