发布于: Oct 30, 2022
本文将探讨如何为 Amazon ElastiCacheRedis 缓存数据库工作负载确定正确的节点大小与集群拓扑结构，以及在此期间需要考量的因素。本文内容涉及 Redis 及其操作命令，同时也要求您对于 Amazon ElastiCache for Redis 及其功能（例如在线集群大小调整、扩展、从 Amazon EC2 到 ElastiCache 的在线迁移、通用型与内存优化型节点以及增强 I/O 等内容）具备一定的了解。
对于入门级、小型（TPS 在 2000 及以下，数据规模在 10 GB 及以下水平）以及中型（TPS 在 2000 到 20000 之间，数据规模在 10 GB 到 100 GB 之间）的缓存工作负载，包括某些可能出现临时需求峰值的工作负载，我们建议大家从 T3 家族（即具备突发峰值支持能力的 T3-Standard 缓存节点的下一代通用型解决方案）当中选择缓存节点。如果您刚刚开始使用 ElastiCache 处理工作负载，则最好从 T3.micro 缓存节点起步，借此享受免费层服务。随着负载容量的增加，您可以逐步提升至 T3.medium 等其他缓存节点类型。
对于中型到大型（TPS 超过 20000，数据规模超过 100 GB）工作负载，我们建议您从 M5 或者 R5 家族当中选择缓存节点，这种最新节点类型支持最新一代 CPU 与网络功能，可配合弹性网络适配器（ENA）提供高达 25 Gbps 的综合网络传输带宽以及超过 600 GiB 的内存容量。与 R4 节点类型相比，R5 节点类型能够为每个 vCPU 提供额外 5% 的内存容量，且每 GiB 使用成本比 R4 节点类型降低 10%。此外，与 R4 节点类型相比，R5 节点类型的 CPU 性能平均提升约 20%。
如果 T3.medium 节点无法继续满足需求，大家也可以选择以下几种节点选项：
- M5 缓存节点，适用于需要增加内存容量以提升数据吞吐量的用例。
- R5 缓存节点，适用于数据吞吐量需求更高的用例，其中每缓存节点内存容量将提升 35% 至 51%。
为了进一步确定合适工作负载需求的节点大小与集群拓扑，大家也可以通过以下操作确定实际需求：
- 确定工作负载中的五项基本特性。
- 运行基准性能测试。
大家可以使用应用程序指标、Redis 中的 INFO 命令或者 Amazon CloudWatch 指标以确定工作负载中的大部分特性。关于最大节点内存选择的更多详细信息，请参阅 Redis 节点类型相关参数说明。
在确定 ElasctiCache 节点需求时，请关注以下核心指标：
- 内存
- 备用或预留内存
- 可用性
- 弹性伸缩
性 - 数据
在初步确定节点内存大小时，我们可以从以下几点入手：
- 确定完整的数据存储大小、键以及值大小。您可以将需要缓存的条目大小乘以同一时间内需要保留缓存的条目数，即可粗略估算
了所需的缓存容量。 - 确定您打算保留的数据，或者使用 TTL 为缓存内的键设置过期机制。TTL 能够在节点上建立起显式内存管理机制。
- 对于当前最为重要的指标（例如在纯缓存用例中），请为其确定现有及预期的缓存命中率。我们必须保证集群的缓存命中率符合预期，或者保证不会频繁清退低命中率键。您可以通过增加内存容量的方式实现这项目标。
除了能够容纳数据库之外，我们还至少应该为节点保留 25% 的内存容量。针对主节点执行的复制操作或多或少会占用一部分内存。另外，缓存节点还应保留 10% 到 15% 的备用内存，用于应对意外出现的负载峰值；同时配合 CloudWatch 警报功能进行早期检测，以提前增加内存容量。我们可以将早期检测与实际需求结合起来，判断选择纵向扩展或者横向扩展方案。
写入操作较为密集的应用程序也有可能占用大量内存空间。在保存快照或者对另一副本进行故障转移时，都需要使用这部分备用内存资源。
如果需要建立集群以满足客户的要求，不妨考虑设置一套包含一个主副本、至少两个辅助副本并启用多可用区复制机制的副本组。这不仅能够提高数据保护能力，也可在主数据库发生意外故障时，保证集群继续提供服务。一旦出现故障，原本的辅助副本将被提升为新的主副本。多副本体系还有助于提高读取吞吐量。
对于写入密集型的主节点，请注意将其写入和读取率设定于 50% 到 80% 之间。如果主节点写入密度过高，可能会提高主副本与辅助副本之间的同步频率，进而影响集群整体的性能。过分频繁的同步操作会占用大量主节点的资源，挤占处理资源并导致传入请求的时长增加。
另外，避免单纯为了追求可用性而启动过多的副本；这会给主数据库造成不必要的压力，迫使其与多个副本执行同步。每个主节点所对应的辅助副本应被限制在不超过五个。可以在其他可用区内额外建立一到两个副本以保障可用性。
ElastiCache 提供的配置模板中包含集群模式，支持在线进行纵向与横向弹性伸缩，且在此期间集群将继续对外提供服务。如果您在主节点上同时使用多个客户端（TPS 可能超过 10000，即 10000 个客户端各 1 TPS 或者 2000 个客户端各 5 TPS），则最好选择横向扩展以保证您拥有充足的计算能力为所有节点提供服务。每个主节点的最佳并发客户端数量，取决于您的实际用例与整体应用程序架构。除了为大量并发客户端提供服务之外，横向扩展还能保证将数据分散在多个分片当中，从而进一步提高集群中数据的可用性。但如果您的业务需要在现有集群配置上获得更高的性能，则应选择纵向弹性扩展。纵向扩展的本质，在于提高单一节点的性能水平。
利用源集群中的 .rdb 文件，我们还可以使用备份/还原操作实现两种集群配置（禁用集群模式与启用集群模式）之间的迁移。因此，请在配置中默认启用集群模式，灵活通过纵向与横向规模伸缩满足后续可能出现的不同需求。
如果要下调集群大小与内存容量（降低配置或减少节点数量），请保证新的配置方案仍有充足的内存以容纳数据及 Redis 运行需求。
确定您的工作负载当中是否存在热键，即请求率极高或者请求率有可能快速增长的一个或多个数据对象。热键的存在，可能对您的缓存引擎性能及请求处理能力造成影响。对于此类情况，建议大家在配置中启用集群模式以将工作负载分散至各多个分片之上，保证将热键保留在特定分片中，而其余键将保留在其他分片中，借此实现传入请求分流。如果存在多个热键，可以考虑将其分散在多个分片中。
另外，大家也可以考虑读写分离。拆分读取和写入之后，我们可以通过独立添加更多副本扩展读取能力。而各副本将保证读取操作的最终一致性。ElastiCache 为禁用集群模式的配置提供副本终端，用于对副本上的读取流量执行负载均衡，借此实现读写分离。另外，也有部分启用集群模式的 Redis 客户端允许将流量路由至各副本。关于更多详细信息，请参阅各 Redis 客户端对应的说明文档
相关文章