【Azure Redis 缓存】Azure Redis 功能性讨论二

继承上一次讨论了Azure Redis的可用性，可靠性，稳定性，安全性，监控方面的九大功能点。详情可回顾文章：【Azure Redis 缓存】Azure Redis功能性讨论

这次我们继续讨论Azure Redis的以下六点问题：

　　1：Redis能否暂停或重启

2：Redis群集扩大分片后能否缩小

3：Redis默认是否会备份，基础和标准版本如何备份数据？

4：RDB 暂留和AOF 暂留有什么区别

5：设置计划更新后，更新开始前后，redis是否可以继续使用

6：异地复制

一：Redis能否暂停或重启

可以重启，但是不能暂停。除基本定价层的Redis外，其他都是有主/从(副本)两个节点，如果只重新启动其中一个节点，数据通常不会丢失，但仍然存在丢失的可能。重启的操作会根据重启的节点不同对已连接的客户端有不同的影响：

主 - 重新启动主节点时，Redis 会发生故障转移到副本节点，并将其提升为主节点。在此故障转移期间，可能会有一个较短的时间间隔无法连接到Redis。
副本 - 重新启动副本节点时，通常不会影响缓存客户端。
主和副本 - 同时重新启动这两个缓存节点时，缓存中的所有数据都会丢失，并且无法连接到缓存，直到主节点重新联机。如果已配置数据持久性，则在缓存重新联机时会还原最新备份，但在最新备份后发生的所有缓存写入都将丢失。
已启用群集的高级缓存的节点 - 重新启动已启用群集的高级缓存的一个或多个节点时，所选节点的行为与重新启动非群集缓存的相应节点时相同。

更多的重启问题，可参考官方文档：https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-administration#reboot

二：Redis群集扩大分片后能否缩小

可以的，可以在Redis的门户页面中进行分片大小的缩放及扩展。

更多关于Redis集群问题，请参考官方文档：https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-how-to-premium-clustering#what-is-redis-cluster

三：Redis默认是否会备份，基础和标准版本如何备份数据？

Redis不会默认备份，并且基础版，标准版并不具备备份(RDB, AOF)的功能。 Redis的数据暂留只在高级版中提供，它提供两种方式进行数据备份 RDB暂留和AOF暂留。

RDB 暂留 - Azure Redis 缓存按照可配置的备份频率(默认60分钟)，将 Azure Redis 缓存的快照以 Redis 二进制格式暂留在存储账号中(Blob)上。
AOF 暂留 - 追加文件，Azure Redis 缓存将每个写入操作保存到日志，此日志每秒至少保存到 Microsoft Azure 存储帐户一次。

更多数据持久化信息，请参考官方文档：https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-how-to-premium-persistence#what-is-data-persistence

四：RDB 暂留和AOF 暂留有什么区别

AOF 暂留将每个写入保存到日志，与 RDB 暂留相比，这对吞吐量有一些影响，因为 RDB 暂留基于配置的备份间隔保存备份，对性能产生的影响非常小。

如果主要目标是最大程度减少数据损失，并且可应付缓存吞吐量下降，请选择 AOF 暂留。如果希望在缓存上保持最优吞吐量，但仍希望使用一种数据恢复机制，请选择 RDB 暂留。

注：AOF 暂留对性能的影响：

当缓存低于最大负载（CPU 和服务器负载皆低于 90%）时，AOF 暂留对吞吐量产生约 15% - 20% 的影响。缓存处于这些限制以内时不存在延迟问题。但是，启用 AOF 时缓存将更快达到这些限制。

关于Redis数据暂留的优缺点，可参考官方网站：https://redis.io/topics/persistence#rdb-advantages

五：设置计划更新后，更新开始前后，redis是否可以继续使用

正常情况下，如果Redis是标准版或者高级版，Redis在更新时是可用的。

因为基本版缓存没有多个节点，仅建议用于开发和测试目的。在更新完成之前不可用。

Redis 服务定期使用最新的平台功能和修补程序更新缓存。该服务遵循以下步骤来修补缓存

管理服务选择一个要修补的节点。
如果所选的节点是主节点，则相应的副本节点将以协作方式提升自身。这种升级被视为计划性故障转移。
所选节点将重新启动以获取新的更改，然后以副本节点的角色重新启动。
副本节点连接到主节点并同步数据。
数据同步完成后，将对剩余的节点重复修补过程。

因为修补属于计划性故障转移，所以副本节点会快速将自身提升为主节点，并开始为请求和新连接提供服务。群集缓存的每个分片单独进行修补，不会关闭与另一个分片的连接。

更多信息，请参考官方文档：https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-failover

六：异地复制

异地复制设计为灾难恢复解决方案。是一种用于链接两个高级层 Azure Redis 缓存实例的机制。 默认情况下，应用程序将写入主要区域并从中进行读取。

异地复制先决条件

若要在两个缓存之间配置异地复制，必须满足以下先决条件：

这两个缓存是高级层缓存。

这两个缓存在同一 Azure 订阅中。

辅助链接缓存的大小等于或大于主链接缓存的大小。

这两个缓存都已创建且处于运行状态。

异地复制不支持某些功能：

异地复制不支持持久性。

如果这两个缓存都启用了群集功能并且具有相同数目的分片，则支持群集。

支持同一 VNET 中的缓存。

也支持不同 VNET 中的缓存，但需要注意一些问题。有关详细信息，请参阅当缓存位于 VNET 中时是否可以使用异地复制？。

完成异地复制配置后，链接缓存对会有以下限制：

辅助链接缓存为只读状态；这意味着只能从中读取，但不能向其写入任何数据。

添加链接前辅助链接缓存中的任何数据都会被删除。但如果以后删除了异地复制，复制的数据则会保留在辅助链接缓存中。

链接缓存时无法缩放任一缓存。

如果缓存已启用群集功能，则无法更改分片数目。

无法在任一缓存上启用暂存。

可以从任一缓存导出。

无法导入到辅助链接缓存。

只有在取消链接缓存之后，才可以删除任一链接缓存或包含它们的资源组。有关详细信息，请参阅尝试删除链接缓存时为何操作会失败？

如果缓存位于不同的区域，网络传出费用将适用于在区域之间移动的数据。有关详细信息，请参阅跨 Azure 区域复制数据的费用是多少？

主要和辅助链接缓存之间不会发生自动故障转移。有关如何故障转移客户端应用程序的详细信息，请参阅如何故障转移到辅助链接缓存？

关于异地复制，可以参考官方文档：https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-how-to-geo-replication