数据存储容灾建设主要从数据可靠性和业务稳定性两个维度阐述。这两者有哪些区别呢？举个例子，业务数据存储在COS，如果该地域出现地震等极端灾难，COS所在机房被外力摧毁导致业务数据全部丢失，属于数据可靠性范畴；同样如果COS机房网络出现波动或者机器出现负载，导致客户端请求数据出现延时高或者中断，属于业务稳定性范畴；从而两者区别是数据是否丢失。
企业通常使用数据存储产品主要为云硬盘（CBS）以及对象存储（CFS）。
1.数据可靠性
1.1 云硬盘（CBS）
云硬盘采用三副本的分布式机制，系统确认数据在三个副本中都完成写入后才会返回写入成功的响应。后台数据复制机制能在任何一个副本出现故障时迅速通过数据迁移等方式复制一个新副本，时刻确保有三个副本可用，避免单点故障引起的数据丢失等问题，提高数据的可靠性。云侧承诺数据可靠性为九个9，即99.9999999%，https://cloud.tencent.com/document/product/362/3039。
CBS快照功能进一步加固数据可靠性，快照生成支持按照小时粒度，最小频率是1个小时。另外CBS分布式存储系统和快照系统是完全独立不同存储体系，来进一步提升平台数据可靠性。
当前CBS架构和业内分布式存储系统类似，主要分为元数据管理(Master)，数据存储（Cell），前端接入（Driver）三个部分组成。详细架构如下：
1.元数据管理：主要负责集群管理功能，例如路由、卷元数据，集群故障探测以及恢复等管理功能
2.driver接入：主要包括client和agent两部分，client作为块设备在用户侧呈现，转发用户的IO到存储cell；agent主要上报client信息与master进行交互。
3.数据存储（cell）：主要是负责数据存储和副本复制功能。
CBS架构图注意事项：
CBS三副本是可用区粒度，即AZ粒度，例如云侧北京有六个可用区，如果出现可用区粒度的极端情况，例如地震火灾，CBS三副本数据可能会丢失。
CBS快照是地域粒度的，即region粒度，例如北京地域，只有出现地域极端情况，快照数据有可能丢失。
1.2 对象存储（COS）
COS将数据分散存储在城市中多个不同的数据中心，其中某数据中心故障了，多AZ存储架构依然可以为云上客户提供稳定可靠的数据服务，云上数据可靠性是12个9，即99.9999999999%，https://cloud.tencent.com/document/product/436/41283。
COS分布式存储系统架构多AZ架构为分层结构主要如下：
COS存储架构图COS目前具备多AZ属性，如果对于核心数据，成本允许前提下，建议开启跨地域复制功能来进一步加固数据可靠性。但是这里特别注意，目前存量单AZ的COS桶暂不支持开启多AZ属性，需要对COS桶数据进行迁移，核心步骤就是新建COS存储桶，将旧桶数据迁移到新桶，推介使用存储桶复制（同地域）功能来做迁移。
2.业务稳定性
从业务视角来保障稳定性，结合云平台能力，结合自身业务来进一步对业务进行加固。列举一下几个场景：
场景一： CBS快照跨地域能力建设
当前云平台CBS数据可靠性的能力在地域粒度，对于公司核心数据要求多地域备份时，需要业务通过调用云API来实现；高可用能力建设核心思路：
1.定期快照复制新CBS盘，调用CBS创建接口。https://cloud.tencent.com/document/product/362/16312
2.将CBS数据上传异地COS,调用cos分块上传接口。https://cloud.tencent.com/document/product/436/7746
3.销毁创建CBS盘，调用CBS销毁接口。https://cloud.tencent.com/document/product/362/16321
场景二： 客户端重试逻辑能力建设
无论是自建IDC和云平台均都会出现硬件故障以及网络抖动，需要业务层进行规避或者降低业务影响。
对于数据写入或者读，客户端或者应用均有超时重试机制，随着业务重要等级不同，超时时间设置和重试次数个性化定制。一般网络抖动都是秒级的，建议重试次数通过退避指数方式来进行，以免造成短时间内机器负载突增。
同时针对使用COS分块上传或者重传，有一个优化技巧，首先COS分块上传以下三步：
1.初始化。实现初始化分块上传，成功执行此请求后将返回 UploadId，用于后续的 Upload Part 请求。
2.并发上传多个分块。
3.完成整个分块上传，当使用 Upload Part 上传所有分块完成后，必须调用该 API 来完成整个文件的分块上传。
通常情况下，如果分块上传失败，客户端会放弃这个文件，重新发起新的上传任务，而且采用分块上传文件一般均为较大文件，为此浪费时间来重试，同时效率也较为低下；为此业务侧如果记录了之前uploadid，通过调用LIST parts接口查询uploadID所有已完成的分块，然后筛选出未完成的分块，来单独上传来进一步节约时间，提升效能。
场景三：存储设备故障时间较长业务自愈能力建设
如果存储集群或者访问链路出现秒级的抖动，采用客户端或者应用重试方式是可行的。如果CBS或者COS分布系统故障时间为分钟级，重试无法解决恢复失效问题，同时会引起机器负载偏高。这里需要针对业务场景来进行设计方案。
方案核心思路主要分为读和写业务。
针对读业务，解决是否有数据备份入口，供业务临时读。例如COS如果开启了异地复制，业务可以临时读异地存储桶，虽然存在访问延时，只是影响用户体验，不会造成业务持续不可用；如果是CBS通过挂载新盘通过快照恢复，或者通过使用大内存机器周期性将核心数据读到内存供业务临时访问等等。
针对写业务，解决业务有写数据入口，供业务临时写入，等故障恢复了，将盘里新增数据复制到原先存储介质里。这里最常用的就是新增COS和CBS盘的方式让业务进行临时写入，待故障恢复后，补齐数据。
