开发

连接复原能力和服务器负载

开发客户端应用程序时，请务必考虑与连接复原能力和管理服务器负载相关的最佳做法。

考虑更多键和较小的值

Azure Cache for Redis 的值越小，效果最佳。 若将数据分布到多个键，请考虑将较大的数据块划分为较小的区块。 有关理想值大小的详细信息，请参阅这篇文章。

请求或响应大小过大

请求/响应过大可能导致超时。 例如，假设你在客户端上配置的超时值为 1 秒。 你的应用程序（使用相同的物理网络连接）的同时请求两个键 （例如，A 和 B）。 大多数客户端支持对请求进行“管道操作”，使得请求“A”和“B”可以逐个发送，而无需等待响应。 服务器会按相同顺序将响应发送回来。 如果响应“A”较大，可能会消耗掉后续请求的大部分超时时间。

在以下示例中，请求“A”和“B”快速发送到服务器。 服务器开始快速发送响应“A”和“B”。 由于数据传输需要时间，即使服务器的响应速度很快，响应“B”也必须等到响应“A”超时。

|-------- 1 Second Timeout (A)----------|
|-Request A-|
     |-------- 1 Second Timeout (B) ----------|
     |-Request B-|
            |- Read Response A --------|
                                       |- Read Response B-| (**TIMEOUT**)

此请求/响应很难度量值。 可对客户端代码进行检测，以跟踪大型请求和响应。

针对大型响应的解决方法各不相同，但是包括：

• 优化应用程序以处理大量的小值，而不是处理少量的大值。
  • 首选解决方案是将数据分解成较小的相关值。
• 增加虚拟机 (VM) 的大小以获得更高的带宽功能
  • 提高客户端或服务器 VM 上的带宽可以缩短较大响应的数据传输时间。
  • 将两台计算机上的网络用量与当前 VM 大小的限制进行比较。 只提高服务器上的带宽，或者只提高客户端上的带宽，都不足以解决问题。
• 增加应用程序使用的连接对象数。
  • 使用轮询方法通过不同的连接对象发出请求。

键分布

如果计划使用 Redis 聚类分析，请先阅读针对键的 Redis 聚类分析最佳做法。

使用管道

尝试选择支持 Redis 管道的 Redis 客户端。 管道有助于高效利用网络并尽可能获取最佳吞吐量。

避免高开销的操作

某些 Redis 操作（如 KEYS 命令）开销很高，应避免使用。 有关长时间运行命令的一些注意事项，请参阅长时间运行的命令。

选择适当的层级

对生产系统使用标准层或高级层。 请勿在生产环境中使用基本层。 基本层是没有数据复制和 SLA 的单节点系统。 此外，使用至少一个 C1 缓存。 C0 缓存仅适用于简单的开发/测试方案，原因如下：

• 它们共享一个 CPU 核心
• 使用少量内存
• 容易出现“近邻干扰”问题

建议进行性能测试以选择适当的层级，并验证连接设置。 有关更多信息，请参阅性能测试。

客户端与缓存位于同一区域

将缓存实例和应用程序定位在同一区域中。 连接到不同区域中的缓存可能会明显提高延迟并降低可靠性。

虽然可以从 Azure 外部进行连接，但不建议这样做，尤其是使用 Redis 作为缓存时。 如果仅将 Redis 服务器用作键/值存储，那么延迟可能不是主要问题。

依赖主机名而不是公共 IP 地址

分配到缓存的公共 IP 地址可能会因缩放操作或后端改进而发生变化。 建议依赖主机名，而不依赖显式公共 IP 地址。 下面是各种层的建议表单：

选择适当的 Redis 版本

创建缓存时使用的默认 Redis 版本可能会随时间推移而更改。 发布新版本的开源 Redis 时，Azure Cache for Redis 可能会采用新版本。 如果需要应用程序的特定 Redis 版本，建议在创建缓存时显式选择 Redis 版本。

使用 TLS 加密

默认情况下，Azure Cache for Redis 要求使用 TLS 加密通信。 目前支持 TLS 版本 1.0、1.1 和 1.2。 但是，TLS 1.0 和 TLS 1.1 即将在全行业范围内弃用，因此，请尽可能使用 TLS 1.2。

如果客户端库或工具不支持 TLS，则可通过 Azure 门户或管理 API 来启用未加密的连接。 在无法加密连接的情况下，建议将缓存和客户端应用程序放入虚拟网络中。 有关虚拟网络缓存方案中使用的端口的详细信息，请参阅此表。

Azure TLS 证书更改

Microsoft 在将 Azure 服务更新为使用来自一组不同的证书颁发机构 (CA) 的 TLS 服务器证书。 这一更改从 2020 年 8 月 13 日至 2020 年 10 月 26 日（预计）分阶段推出。 Azure 进行此更改是因为当前 CA 证书不符合某个 CA/浏览器论坛基线要求。 此问题已于 2020 年 7 月 1 日报告，适用于全球多个热门公钥基础结构 (PKI) 提供商。 目前，Azure 服务使用的大多数 TLS 证书来自 Baltimore CyberTrust 根 PKI。 Azure Cache for Redis 服务将继续链接到 Baltimore CyberTrust 根。 不过从 2020 年 10 月 12 日开始，其 TLS 服务器证书将由新的中间证书颁发机构 (ICA) 颁发。

此更改是否会对我产生影响？

大多数 Azure Cache for Redis 客户不会受此更改的影响。 如果应用程序显式指定可接受证书的列表（做法称为“证书固定”），则可能会受到影响。 如果已固定到中间证书或叶证书，而不是 CyberTrust 根证书，则应该立即采取措施来更改证书配置。

Azure Cache for Redis不支持 OCSP 装订。

下表提供了有关正在被回滚的证书的信息。 根据应用程序使用的证书，你可能需要对其进行更新，以防丢失与 Azure Cache for Redis 实例的连接。

我应该采取什么措施？

如果你的应用程序使用操作系统证书存储或将 Baltimore 根固定在其他地方，则无需执行任何操作。

如果应用程序固定任何中间或叶 TLS 证书，建议固定以下根：

若要继续固定中间证书，请将以下内容添加到包含几个附加证书的“固定的中间证书”列表中，以最大程度地减少将来的更改：

如果应用程序使用代码来验证证书，则需修改代码以识别新固定的证书的属性（例如颁发者、指纹）。 这一额外验证应覆盖所有固定的证书，以便更好地面向未来。

特定于客户端库的指南

有关详细信息，请参阅客户端库。

后续步骤

• 性能测试
• Azure Cache for Redis 的故障转移和修补