本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
常见故障排除步骤和最佳实践
连接问题
如果您无法连接到 ElastiCache 缓存，请考虑以下方法之一：
使用 TLS：如果您在尝试连接到 ElastiCache 终端节点时遇到连接挂起的情况，则可能没有在客户端中使用 TLS。如果您使用的是 ElastiCache 无服务器，则传输中的加密始终处于启用状态。确保您的客户端使用 TLS 连接到缓存。在此处了解有关连接到启用 TLS 的缓存的更多信息。
VP ElastiCache C：只能从 VPC 内部访问缓存。确保您访问缓存的 EC2 实例和缓存是在同一 VPC 中创建的。 ElastiCache 或者，您必须在您的 EC2 实例所在的 VPC 和创建缓存的 VPC 之间启用 VPC 对等关系。
安全组：ElastiCache 使用安全组来控制对缓存的访问权限。请考虑以下事项：
Redis 客户端错误
ElastiCache 只有使用支持 Redis 集群模式协议的 Redis 客户端才能访问无服务器。根据集群配置，可以在任一模式下从 Redis 客户端访问自行设计的集群。
如果您在客户端中遇到 Redis 错误，请考虑以下几点：
集群模式：如果您在使用 SE LECT
Redis 命令时遇到 CROSSLOT 错误或错误，则可能正在尝试使用不支持 Redis 集群协议的 Redis 客户端访问已启用集群模式的缓存。 ElastiCache 无服务器仅支持支持 Redis 集群协议的 Redis 客户端。如果要在 “禁用集群模式” (CMD) 中使用 Redis，则必须设计自己的集群。 CROSSLOT 错误：如果您遇到
ERR CROSSLOT Keys in request don't hash to the same slot错误，则可能正在尝试访问不属于集群模式缓存中同一插槽的密钥。提醒一下， ElastiCache Serverless 始终在集群模式下运行。仅当涉及的所有密钥都在同一个哈希槽中时，才允许使用涉及多个密钥的多密钥操作、事务或 Lua 脚本。
有关配置 Redis 客户端的其他最佳实践，请查看此博客文章
解决 ElastiCache 无服务器中的高延迟问题
如果您的工作负载出现高延迟，则可以分析 CloudWatch SuccessfulReadRequestLatency和SuccessfulWriteRequestLatency指标，以检查延迟是否与 ElastiCache 无服务器有关。这些指标衡量的是 ElastiCache 无服务器内部的延迟，不包括客户端延迟以及您的客户端和 ElastiCache 无服务器端点之间的网络访问时间。
有些可变性和偶尔出现的峰值不应引起担忧。但是，如果Average统计数据显示急剧增长并持续存在，则应查看和您的 Personal Health Dashboard 以获取更多信息。 Amazon Health Dashboard 如有必要，可以考虑向提出支持案例 Amazon Web Services Support。
考虑以下减少延迟的最佳实践和策略：
启用从副本读取：如果您的应用程序允许，我们建议在您的 Redis 客户端中启用 “从副本读取” 功能，以扩展读取并降低延迟。启用后， ElastiCache Serverless 会尝试将您的读取请求路由到与您的客户端位于同一可用区 (AZ) 的副本缓存节点，从而避免跨可用区网络延迟。请注意，在客户端中启用 “从副本读取” 功能表示您的应用程序接受数据的最终一致性。如果您在写入密钥后尝试读取，您的应用程序可能会在一段时间内收到较旧的数据。
确保您的应用程序部署在与缓存相同的可用区中：如果您的应用程序未部署在与缓存相同的可用区中，则可能会出现更高的客户端延迟。创建无服务器缓存时，您可以提供您的应用程序将从中访问缓存的子网， ElastiCache Serverless 将在这些子网中创建 VPC 终端节点。确保您的应用程序部署在相同的可用区中。否则，您的应用程序在访问缓存时可能会出现跨可用区跳跃，从而导致更高的客户端延迟。
重用连接：ElastiCache 无服务器请求是使用 RESP 协议通过启用 TLS 的 TCP 连接发出的。启动连接（包括对连接进行身份验证，如果已配置）需要时间，因此第一个请求的延迟要高于典型延迟。通过已初始化的连接发出的请求可提供始终如一 ElastiCache的低延迟。因此，您应该考虑使用连接池或重复使用现有的 Redis 连接。
扩展速度：ElastiCache Serverless 会随着请求速率的增长而自动扩展。请求速率的突然大幅增加（快 ElastiCache 于 Serverless 的扩展速度）可能会在一段时间内导致延迟升高。 ElastiCache Serverless 通常可以快速提高其支持的请求速率，最多需要 10-12 分钟才能将请求速率提高一倍。
检查长时间运行的命令：某些 Redis 命令，包括 Lua 脚本或大型数据结构上的命令，可能会运行很长时间。要识别这些命令，请 ElastiCache 发布命令级指标。借助ElastiCache 无服务器，您可以使用这些
BasedECPUs指标。受@@ 限制的请求：在 ElastiCache Serverless 中限制请求时，您的应用程序中的客户端延迟可能会增加。当请求在 ElastiCache Serverless 中受到限制时，您应该会看到无服务器指标有所增加。ThrottledRequests ElastiCache 请查看以下部分，了解受限请求的疑难解答。
密钥和请求的均匀分布：在 ElastiCache Redis 中，每个插槽的密钥或请求分布不均会导致热槽，从而导致延迟增加。 ElastiCache 在执行简单的 SET/GET 命令的工作负载中，Serverless 在单个插槽上支持高达 30,000 ecpu/秒（使用从副本读取时为90,000 ecpu/秒）。我们建议您评估密钥和请求在各个插槽中的分布，并确保在您的请求速率超过此限制时实现均匀分配。
对无服务器中的限制问题进行故障排除 ElastiCache
在服务导向型架构和分布式系统中，限制各种服务组件处理 API 调用的速率称为“限制”。这可以平滑峰值，控制组件吞吐量中的不匹配情况，并在出现意外操作事件时实现更可预测的恢复。 ElastiCache Serverless 专为这些类型的架构而设计，大多数 Redis 客户端都内置了针对受限请求的重试功能。一定程度上的限制对应用程序而言不一定是问题，但是持续限制数据工作流中对延迟敏感的部分可能会对用户体验产生负面影响，并会降低系统的整体效率。
当请求在 ElastiCache Serverless 中受到限制时，您应该会看到无服务器指标有所增加。ThrottledRequests ElastiCache 如果您注意到受限的请求数量很多，请考虑以下几点：
扩展速度：ElastiCache Serverless会随着您摄取更多数据或请求速率的增长而自动扩展。如果您的应用程序的扩展速度快于Serverless的扩展速度，则您的请求可能会受到限制，而 ElastiCache ElastiCache Serverless可以扩展以适应您的工作负载。 ElastiCache Serverless 通常可以快速增加存储大小，最多需要 10-12 分钟才能将缓存中的存储大小增加一倍。
密钥和请求的均匀分布：在 ElastiCache Redis 中，每个插槽的密钥或请求分布不均可能会导致出现热槽。在执行简单的 SET/GET 命令的工作负载中，如果单个插槽的请求速率超过 30,000 ecpus/秒，则热插槽可能会导致请求受限。
从副本读取：如果您的应用程序允许，请考虑使用 “从副本读取” 功能。大多数 Redis 客户端可以配置为 “扩展读取”，将读取定向到副本节点。此功能使您能够扩展读取流量。此外， ElastiCache Serverless 会自动将副本请求中的读取路由到与您的应用程序位于同一可用区的节点，从而降低延迟。启用从副本读取后，对于使用简单的 SET/GET 命令的工作负载，您可以在单个插槽上实现高达 90,000 ECPU /秒。