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