本页面介绍了如何以最佳方式使用 Memorystore for Valkey。此页面还指出了需要避免的潜在问题。
内存管理最佳做法
本部分介绍了管理实例内存的策略，以便 Memorystore for Valkey 高效地为您的应用提供服务。
内存管理概念
写入负载 - 在 Valkey 实例中添加或更新密钥的量和速度。您的写入负载可能从正常到非常高，具体取决于您的 Valkey 用例和应用使用模式。
逐出政策 - Memorystore for Valkey 使用
volatile-lru逐出政策。您可以使用 EXPIRE 命令等 Valkey 命令为密钥设置逐出。
监控具有正常写入负载的实例
查看“/instance/cpu/maximum_utilization”指标。如果/instance/cpu/maximum_utilization
设定为 100% 或更低，那么当您使用正常的写入负载时，Valkey 实例的性能会比较好。
但是，如果您的内存用量接近 100%，且您预计流量用量会增加， 您应该扩大实例大小，为新数据腾出空间。
监控写入负载较高的实例
查看“/instance/memory/maximum_utilization”指标。根据高写入负载的严重程度，您的实例可能会在以下阈值下出现性能问题：
如果
/instance/memory/maximum_utilization达到 65% 或更高，极高的写入加载可能会出现问题。如果
/instance/memory/maximum_utilization达到 85% 或更高，较高写入负载可能会出现问题。
在这些情况下，您应该扩大实例大小以提高性能。
如果您遇到问题，或担心实例的写入负载较高，请与 Google Cloud 支持团队。
扩缩分片
在实例中扩缩分片数时，应在低写入时段进行扩缩。在高写入负载期间进行扩缩可能会因复制或槽迁移造成内存开销而导致实例的内存不足。
如果您的 Valkey 用例使用键逐出，则伸缩到较小的实例大小可以降低缓存命中率。不过，在这种情况下，您无需担心数据丢失，因为系统预计会逐出键。
对于不想丢失密钥的 Valkey 用例，您应仅缩减为仍然有足够的空间存储数据的较小实例。新的目标分片数应至少支持数据所用内存的 1.5 倍。换句话说，您应该预配足够的分片，以存储实例中当前数据量的 1.5 倍。您可以使用 /instance/memory/total_used_memory 指标查看您的实例中存储了多少数据。
CPU 使用最佳实践
如果发生意外的可用区级中断，由于不可用可用区中的节点会丢失容量，从而导致实例的 CPU 资源减少。我们建议您使用高可用性实例。每个分片使用两个副本（而不是每个分片一个副本）可在服务中断期间提供额外的 CPU 资源。此外，我们建议管理节点 CPU 使用率，以便节点有足够的 CPU 开销来处理因可用区级数据意外中断而丢失的额外流量。您应使用主线程 CPU 秒数 /instance/cpu/maximum_utilization 指标监控主实例和副本的 CPU 用量。
根据您为每个节点预配的副本数量，我们建议您设置以下 /instance/cpu/maximum_utilization CPU 使用率目标：
- 对于每个节点 1 个副本的实例，应该将主实例和副本的
/instance/cpu/maximum_utilization值设置为 0.5 秒。 - 对于每个节点有 2 个副本的实例，应将主实例的
/instance/cpu/maximum_utilization值设置为 0.9 秒，将副本指定为 0.5 秒。
如果指标的值超过这些建议值，我们建议您增加实例中的分片数或副本数。
CPU 开销高的 Valkey 命令
您应当避免使用因各种原因而运行成本高昂的 Valkey 命令。 本部分举例说明了某些命令成本高昂的原因， 并非详尽无遗。
对整个键空间执行操作的命令
- KEYS
对可变长度密钥集执行的命令
- LRANGE
- ZRANGE
- 赫盖尔
执行脚本时阻止的命令
- 评估
- EVALSHA
使用开销大的命令的风险
- 延迟时间长且客户端超时。
- 由增加内存用量的命令引起的内存压力。
- 由于阻塞 Valkey 主线程，导致节点复制和同步期间数据丢失。
- 缺少的健康检查、可观测性和复制。
Valkey 客户端最佳实践
在连接到 Memorystore for Valkey 实例时，您的应用必须使用集群感知型 Valkey 客户端。如需查看集群感知型客户端和示例配置的示例，请参阅客户端库代码示例。您的客户端必须维护一个将哈希槽映射到实例中相应节点的映射，以便将请求发送到正确的节点，并避免因重定向而导致的性能开销。
客户端映射
客户端必须获取完整的槽列表和 以下情况：
客户端初始化时，必须将初始槽填充到节点中 映射。
从服务器收到
MOVED重定向时，例如在故障切换的情况下，副本接管了之前主节点提供的所有槽，或者在将槽从来源主节点移至目标主节点时重新分片。从服务器收到
CLUSTERDOWN错误或与特定服务器的连接持续发生超时情况。当从服务器收到
READONLY错误时。如果将主实例 已降级为副本。此外，客户端应定期刷新拓扑，使客户端处于预热状态 了解更改，并了解可能不会导致重定向的更改 / 错误，例如添加了新的副本节点时。请注意，在拓扑刷新过程中，还应关闭所有过时连接，以减少在命令运行期间处理失败连接的需要。
客户发现
通常，客户端发现是通过向 Valkey 服务器发出 SLOTS、NODES 或 CLUSTER SHARDS 命令来完成的。我们建议使用 CLUSTER SHARDS 命令。CLUSTER SHARDS 通过提供更高效且可扩展的实例表示法，取代了 SLOTS 命令（已废弃）。
客户端发现命令的响应大小可能会因实例大小和拓扑而异。节点越多、越大 大型链接因此，请务必确保执行节点拓扑发现的客户端数量不会无限增长。
这些节点拓扑刷新在 Valkey 服务器上的成本很高，但对应用可用性也很重要。因此，务必要确保每个客户端在任何给定时间发出一个发现请求（缓存导致内存中），并确保发出请求的客户端数量保持绑定，以避免服务器过载。
例如，当客户端应用启动或与服务器的连接断开且必须执行节点发现时，一个常见错误是客户端应用在重试时没有添加指数退避算法，而发出了多次重新连接和发现请求。这可能会导致 Valkey 服务器在很长一段时间内无响应，导致 CPU 利用率非常高。
避免 Valkey 上出现发现过载
缓解连接和发现突然涌入所造成的影响 请求，我们建议您采取以下措施：
实现有限且较小的客户端连接池， 限制来自客户端的并发传入连接数 应用。
当客户端因超时而与服务器断开连接时，请使用带抖动的指数退避进行重试。这有助于避免多个客户端 同时让服务器超负荷运转。
使用 Memorystore for Valkey 发现端点来执行节点 发现。发现端点具备高可用性并进行了负载均衡 实例中的所有节点此外，发现端点会尝试 将节点发现请求路由到 拓扑视图。
持久性最佳实践
本部分介绍了持久性的最佳实践。
RDB 持久性
为了在使用 RDB 快照备份实例时获得最佳效果，您应采用以下最佳实践：
内存管理
RDB 快照使用进程分支和“写入时复制”截取节点数据快照的机制。随着写入所涉及页面的复制，节点的已用内存会随之增长，具体取决于写入节点的模式。在最坏的情况下，内存占用量可能是节点中数据大小的两倍。
为了确保节点有足够的内存来完成快照，您应该将 maxmemory 保留或设置为节点容量的 80%，从而预留 20% 用于开销。如需了解详情，请参阅监控写入负载较高的实例。除了监控快照之外，这种内存开销还有助于您管理工作负载，以便成功创建快照。
过时快照
从过时快照中恢复节点可能会导致应用出现性能问题，因为它会尝试协调大量过时的键或对数据库进行的其他更改，例如架构更改。如果您担心从过时快照进行恢复，可以停用 RDB 持久化功能。重新启用永久性存储后，系统会在下次按计划创建快照的时间间隔创建快照。
RDB 快照的性能影响
RDB 快照可能会影响实例的性能并增加应用的延迟时间，具体取决于您的工作负载模式。如果您能接受不那么频繁的快照，可以安排在实例流量较低的时段运行 RDB 快照，从而最大限度地降低对性能的影响。
例如，如果实例在凌晨 1 点到凌晨 4 点的流量较低，则可以将开始时间设置为凌晨 3 点，并将时间间隔设置为 24 小时。
如果系统负载持续且需要频繁的快照，则应仔细评估性能影响，并权衡为工作负载使用 RDB 快照的好处。
如果您的实例不使用副本，请选择单可用区实例
在配置没有副本的实例时，我们建议使用单可用区架构来提高可靠性。原因如下：
最大限度地降低服务中断影响
可用区级服务中断不太可能影响您的实例。通过将所有节点 那么可用区级服务中断影响您的服务器的几率就会下降 从 100% 到 33%这是因为您所在区域有 33% 的几率 那么位于实例位置的节点不会 100% 的几率 不可用的可用区会受到影响
快速恢复
如果发生可用区级服务中断，系统会简化恢复流程。你可以快速回复 在正常运行的可用区预配新实例，并将您的 尽可能减少中断。