最佳做法

本页面介绍使用 Memorystore for Memcached 时应遵循的最佳做法。

缓存最佳做法

构建应用以处理缓存未命中

您应该遵循标准缓存设计最佳做法,将缓存设计为处理缓存未命中和服务不可用。如需了解 Memorystore for Memcached 对正常运行时间的承诺,请参阅服务等级协议

对您的应用进行设计,以使缓存未命中和临时服务停机不会阻止应用从 Memcached 实例支持的底层数据库中检索数据。

此外,遇到键空间不可用的情况时,请等待并使用指数退避算法重试。请确保设置了重试次数限制。

我们建议您使用 Memorystore for Memcached Auto Discovery 服务。在集群中添加或移除节点时,此服务会自动执行集群 IP 地址管理。如需了解如何为集群设置自动发现,请参阅使用 Auto Discovery 服务

正确配置 max-item-size 参数

本部分介绍配置 max-item-size 参数的最佳做法。如需了解调整此配置参数的步骤,请参阅配置 Memcached 实例。如需查看可用 Memcached 配置参数的完整列表,请参阅 Memcached 配置

支持的值和默认值

对于开源 Memcached,max-item-size 的最小值为 1KiB,最大值为 1 GiB,默认值为 1 MiB。对于 Memorystore for Memcached,最小值为 512 KiB,最大值为 128 MiB,默认值为 1 MiB。此外,您为此配置设置的任何值都必须可被 512 KiB 整除。

缓存大于配置的 max-item-size 的条目

如果您尝试缓存大于配置的 max-item-size 的条目,则 Memcached 会使操作失败并返回 false。如有可能,请在应用中构建逻辑以从 Memcached OSS 客户端显示此错误,以便您可以对其进行调试。尝试缓存大于配置的 max-item-size 的条目可能会导致实例的高延迟。

max-item-size 设置为最大值

您可以通过将 max-item-size 参数设置为最大值来解决某些问题。但这并不是一种好的做法,因此您不应在生产环境中使用此策略。Memcached 内存管理基于 Slab,而存储大小超过 Slab 的内容会导致内存分配效率低下。

避免 max-item-size 配置问题

首先,确定您的缓存所需的项大小上限。将 max-item-size 设置为略大于项大小上限,作为安全边际。

请注意,写入缓存的值的大小在应用中可能会随时间变化。此外,集群也可能配置错误(例如,在从一个环境迁移到另一个环境时)。您可以采取的另一个方法是验证应用的项大小上限。如果应用尝试缓存大于配置的设置的项时,请求将被拒绝。

如何平衡不平衡的 Memcached 集群

不平衡集群出现的原因以及相关风险

在极少数情况下,当您创建 Memcached 实例时,节点可能会不均衡地分布在一个地区的区域中。如果某一区域在您预配集群时不可用,就会发生这种情况。

不平衡集群会增加数据丢失的可能性,因为节点的分布不均匀。当不可用的区域恢复在线后,集群不会自动重新平衡。

如何重新平衡集群

要重新平衡集群,您可以暂时增加集群中的节点数,然后将节点数缩减到原始节点数。这种扩缩操作使 Memorystore for Memcached 系统可以在各个可用区域中均匀地重新分布节点。

这一重新平衡集群的方法能否成功取决于相关区域的可用性。Google Cloud 目前不会列出可用/不可用区域,因此只有当节点在扩缩操作期间正确地均衡分布时,您才能判断区域是否在线。

Cloud Monitoring 最佳做法

为了跟踪缓存在一段时间内的性能,您应使用 Cloud Monitoring 来监控一些基本的 Memorystore for Memcached 指标:

  • 内存用量 (memcache.googleapis.com/node/cache_memory)
  • CPU 使用率 (memcache.googleapis.com/node/cpu/usage_time)

在一段时间内跟踪这两个指标可帮助您确定集群的使用效率,以及是否应考虑增加或减小集群的大小。

例如,如果指标显示内存用量和 CPU 使用率在一段时间内增长到 80% 以上,那么这一趋势可能会继续。因此,您可以尽早增加实例大小,以便随着应用的资源需求增加,缓存有足够的空间存储新值。

我们建议您在内存用量和 CPU 使用率达到 80% 时设置提醒

或者,跟踪这些指标一段时间后,您可能发现目前拥有的所有空间和 CPU 资源并非都得到了利用。在这种情况下,缩减集群的大小会更具成本效益。

后续步骤