用户数据承诺一个非常高的安全性，但万一出现意外呢？我们是不是还要有适当的应对方案？比如今年的3月8日晚间，Azure 某个区域中的存储几乎全部不能访问，持续达两个多小时。当时最担心的是：用户的数据万一丢掉怎么办？同时，我们是不是可以根据云服务提供的数据服务的特点来优化程序的性能呢？基于如此种种的原因，我们需要了解云端数据服务的一些特性的详情，这将对我们很有帮助。本文将和大家一起探讨 Azure Storage 的冗余策略。

性能选项是有关联性的。比如，当 performance 为 "Standard" 时，Replication 可以选择 ZRS,LRS,GRS,RA-GRS:

升级域中。

升级域 (UD) 是一组在服务升级（推出）过程中一起升级的节点。 三个副本将分布在同一弹性存储单元中的 UD 和 FD 上，以确保即使在硬件故障影响单个机架时，或在推出期间升级节点时，数据也可用。

性能，比如选择performance 为 “Premium” 时只能使用 LRS 策略。

用户的数据也是安全的。

升级域的副本。

用户可以选择这种冗余策略。比如我们在一个 web 应用中保存了用户上传的数据(文档、图片、视频等)。为了保护用户的数据，我们可以把这些文件存放在设置为 GRS 的存储中。当主区域发生问题时，至少可以把用户的数据恢复回来。下面是笔者维护的一个使用了 GRS 的项目：

自动设置的，不支持用户自由选择。其实我们都没有必要知道它的存在，只需要知道数据是安全的就可以了。

获取数据。辅助终结点与主终结点类似，但会在帐户名称后面追加后缀 –secondary。例如，如果 Blob 服务的主终结点是 myaccount.blob.core.windows.net，辅助终结点则是 myaccount-secondary.blob.core.windows.net。 Storage Account 的访问密钥对于主终结点和辅助终结点是相同的。

用户又不能自由的指定次区域的位置，所以十分怀疑是否可以达到真正的目的。