在前几期，我们介绍了对象存储的对外接口规范、内部存储池分配以及快速根据标签查找到对象的实现。但是，这对于实现企业级和运营级SLA，还需要跨越一道鸿沟……
经过这么多期的介绍，我们知道，无论机械硬盘还是SSD盘，都不是一个可靠的部件。因此，在集中式存储中采用RAID机制，而在分布式存储中使用多副本和纠删码来为磁盘损坏这种日常出现的事件进行兜底，保证数据不丢失。以单磁盘数据持久性为99.9%论，三副本机制下，对象存储的数据持久性是可以达到99.9999999%的。
然而，存储系统还有一个重要的指标是，服务可用性。
让我们回到一个古老的话题——在五年前，数据中心建设最流行的一句话：
“同城双活，异地灾备，两地三中心”。
从此，大型企业的数据中心建设，开启了《双城记》的新纪元：
那是最好的时代，那是最坏的时代；
那是智慧的年头，那是愚昧的年头；
那是信仰的时期，那是怀疑的时期；
那是光明的季节，那是黑暗的季节；
那是希望的春天，那是失望的冬天；
我们全都直奔天堂，我们全都在直奔相反的方向。
正如查尔斯·狄更斯在《双城记》中写道，巴黎人民攻占巴士底狱的消息，需要好几天才能同步到伦敦那样，异地数据中心之间的数据实时同步一直是难以解决的问题。因此，我们一般认为，两个同城双活数据中心用于保障单数据中心出现基础设施故障时，另一数据中心的关键数据，应当需要保持一致性，暂时先不考虑异地灾备的问题。
在现代云计算模型中，每个地区为一个Region，每个Region有多个AZ：
其中，如果某个服务是跨AZ的服务，那么，一个AZ瘫痪时，服务是不受影响的。
前面提到，对象存储在AZ内可以实现99.9999999%的数据持久性，那么，有没有办法让对象存储成为跨AZ的服务，从而提升它的业务可用性呢？
让我们再次重温分布式对象存储系统的架构：
如果我们希望对象存储能够跨AZ提供服务，显然，我们需要让这些部件都可以跨AZ实现服务：
HTTP Server：跨AZ使用统一的域名；
Metadata数据库：两个AZ各自有各自的索引；
存储池：跨AZ数据同步，或实现三副本分散到两个AZ；
如下图所示：
在下一期，我们开始为大家详解对象存储双活的设计实现。
