【AzureRedis缓存】AzureRedis功能性讨论二

继承上一次讨论了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