由于业务需要，有的时候业务量比较大，小实例的redis无法支撑，需要更改实例类型，支持更大的并发等，后面业务量下去了，需要节约成本收缩实例类型。本文讲下收缩实例类型。
1.通过控制台缩减实例类型
缩减 Redis 缓存集群（控制台）
以下过程介绍如何使用 ElastiCache 管理控制台缩减 Redis 集群。此过程中，在状态从“modifying (正在修改)”变为“available (可用)”之前，阻止应用程序与主缓存集群之间的所有读写操作。但是，只读副本缓存集群的读取继续不受干扰地进行。
（控制台）缩减 Redis 集群
登录 AWS 管理控制台并通过以下网址打开 ElastiCache 控制台：https://console.aws.amazon.com/elasticache/。
从导航窗格中，选择 Redis。
从集群列表中，选择首选集群。
选择 Modify。
在 Modify Cluster 向导中：
从 Node type 列表中选择您希望扩展到的节点类型。要缩减，请选择小于现有节点的节点类型。请注意，并不是可缩减到所有节点类型。
如果您要立即执行缩减过程，请选中立即应用框。如果立即应用框处于未选中状态，则在此集群的下一维护时段内执行缩减过程。
选择 Modify。
如果您在上一步选择了 Apply immediately，则集群的状态将变为 modifying。当状态变为 available 时，即表示修改完成，您可以开始使用新集群。
2.通过AWS CLI缩减实例类型
1.查看支持的缩减或者升级的实例类型
aws elasticache list-allowed-node-type-modifications \
> --replication-group-id new-test（实例名称）
{
"ScaleUpModifications": [
"cache.r5.12xlarge",
"cache.r5.24xlarge",
"cache.r5.2xlarge",
"cache.r5.4xlarge",
"cache.r5.xlarge"
]
}
2.使用 AWS CLI modify-replication-group 命令和以下参数修改复制组以缩减为较小的新节点类型。
--replication-group-id – 要缩减为的复制组的名称。
--cache-node-type – 要将缓存集群扩展为的新节点类型。此值必须是步骤 1 中由 list-allowed-node-type-modifications 命令返回的节点类型之一。
--cache-parameter-group-name – [可选] 如果您在使用 reserved-memory 管理集群的预留内存，则使用此参数。指定为您的新节点类型预留正确内存量的自定义缓存参数组。如果您在使用 reserved-memory-percent，则可以忽略此参数。
--apply-immediately – 导致立即应用向上扩展流程。要将收缩流程推迟到此集群的下一维护时段，请使用 --no-apply-immediately 参数。
aws elasticache modify-replication-group \
--replication-group-id new-test \
--cache-node-type cache.r5.xlarge\
--apply-immediately
3.如果您使用了 --apply-immediately，请使用带以下参数的 AWS CLI describe-cache-clusters 命令检查缓存集群的状态。当状态变为 available 时，您便可开始使用较小的新缓存集群节点。
3 其他相关
操作的时候提示信息如下
您已选择缩小集群。请确保新节点大小为您的数据集提供足够的内存。
节点类型修改和引擎升级过程旨在尽力保留您的现有数据，并且需要进行 Redis 复制才能成功。
有关 Redis 复制的最佳实践，请参阅 该。
请注意，对于集群 Redis，扩大/缩小节点修改的工作流完全在线进行。对于非集群 Redis，您可能会注意到主节点上出现几秒的短暂中断。
4 在线集群大小调整官方建议（重新分片建议）
测试应用程序 – 尽可能在过渡环境中重新分片期间测试应用程序行为。
获取扩展问题的提前通知 – 重新分片是一项需使用大量计算资源的操作。因此，我们建议在重新分片期间，多核心实例的情况下 CPU 保持 80% 以下的利用率，单核心实例的情况下 CPU 保持 50% 以下的利用率。在应用程序开始监测扩展问题前监控 ElastiCache for Redis 指标并启动重新分片。跟踪的有用指标为 CPUUtilization、NetworkBytesIn、NetworkBytesOut、CurrConnections、NewConnections、FreeableMemory、SwapUsage 和 BytesUsedForCache。
缩减前请确保有足够的可用内存 – 如果要进行缩减，请确保要缩减的分片上的可用内存至少是您计划删除的分片上使用的内存的 1.5 倍。
在非高峰时间启动重新分片 – 此实践有助于减少重新分片操作期间对客户端的延迟和吞吐量的影响。同样有助于更快完成重新分片，因为有更多资源可用于槽重新分配。
审核客户端超时行为 – 部分客户端可能会在联机集群调整大小期间出现更高的延迟。为客户端库配置更高的超时会有所帮助，即便服务器处于更高的负载条件下，系统也有时间进行连接。在某些情况下，您可能会打开与服务器的大量连接。在这些情况下，请考虑增加指数回退以便重新连接逻辑。这样做可防止突增的新连接同时连接服务器。
在重新分片期间，建议进行以下操作：
避免耗费大量资源的命令 – 避免运行任何计算型和 I/O 密集型操作，例如 KEYS 和 SMEMBERS 命令。我们推荐此方法是因为这些操作可增加集群上的负载并能对集群的性能产生影响。改用 SCAN 和 SSCAN 命令。
遵循 Lua 最佳实践 – 避免长时间运行 Lua 脚本并始终预先声明在 Lua 脚本中使用的密钥。我们建议使用此方法确定 Lua 脚本未使用跨槽命令。请确保 Lua 脚本中使用的密钥属于同一槽。
重新分片完成后，请注意以下事项：
如果目标分片上的内存不足，缩减可能会部分完成。如果发生此结果，必要时请查看可用内存并重新进行操作。
带有大型项目的槽不会迁移。特别是带有超过 256 MB 后序列化的槽不会迁移。
如果在迁移的槽上进行操作，则不支持 BRPOPLPUSH。重新分片期间，Lua 脚本内不支持 FLUSHALL 和 FLUSHDB 命令。
