原创声明
：本文系作者原创，谢绝个人、媒体、公众号或网站
未经授权
转载，违者追究其法律责任。
继单元化实施，本文针对金融级分布式系统中，异地多活方案实施过程单元化技术弹性存储层数据分类设计调研与思考。
一、多数据中心: 困难的存储伸缩
现代金融级业务需求严格遵守业务连续性管理(BCM)体系，如因交易瞬间无法执行造成异常的后果，都是巨大的经济损失、投资损失。因此，金融级系统架构对效率、容错、灾备恢复等都有高指标要求。而分层体系金融级分布式架构弹性方案设计中，存储层因复杂IO吞吐、高消耗性能、纠错成本高、容错要求高、扩展性差等等特点，成最难实施落地的一层，存储层设计的优劣几乎决定应用、接入等服务化程度的质量，对技术团队的挑战也是最高(没有之一)。
二、多数据中心: 机房单向、双向热复制
之前讲到过金融级系统为了提高
RPO（Recovery Point Object）和RTO（Recovery Time Object）指标，传统成熟实施的有“两地三中心“等同城多活方案，但是这种方案已经不能满足现代互联网环境用户高并发、高流量等要求，因此当前的互联网环境在逐步摸索和实践中，设计出更为成熟的多活方案,新的主流异地多活方案中，存储层的最大特点是数据中心之间实时、高效对数据做单向、双线热复制，如下图:
注:本图将一个单元化系统等价于一个机房空间，结合阿里、饿了么等大公司实践分享，实际中一个单元化系统的定义粒度更细，一个机房里具有很多个单元化系统，只不过它们是同机房的。
其中任何一个机房出现故障，都能在分钟级别将用户流量切换到另外一个机房。
三
、多数据中心:数据归类设计
3.1 是否有必要做多数据中心以及是否有做多数据中心的成本
多数据中心方案的设计、实施并非易事，在开始所有计划之前，我们需要考虑系统生命周期各段时间的矛盾点:当前经济成本、将来的可扩展性、近2、3年的预期流量、容灾能力、业务连续性、成本控制等，虽然这看起来并不完全属于技术的工作，但除了作为架构设计的你，没有别人更能懂这个方案的所有问题及效益成本。
3.2 数据服务分类问题
并没有完美物理定理式的多数据中心方案，作为工程性解决办法，更多结论都是由实施人员经验、业务判断、业务折中等综合设计而来，并且尽可能带有预见性，降低实施返工成本。
多数据中心系统数据需要解决3类数据的问题：
业务层可分区数据
、
高频全局数据
、低频全局数据。
业务层可分区数据:
这类数据最接近业务层机房自治理念，数据拓扑结构如下:
这类数据在每个机房里面会部署有多个独立单元，数据是全局数据按照某种水平维度进行划分之后的一部分，不同机房之间以类似镜像的逻辑存在，这种设计下，当一个机房出事故，可以快速将流量切换到另外一个机房。通常类似订单、支付流水、账户的数据归为此类。
特点: 多节点写入、机房间双向复制。不同机房都在发生写和读，数据在机房间不断复制，对技术的考验性最高。双向、多向复制。这类数据基本都会是从用户角度划分，发生一笔业务时，数据全部是机房内聚的，只在自己的机房内读取，不会跨机房发生业务，是最合适机房自治概念的数据。
高频全局数据:
这类数据全局性突出，并且访问频率高，通常每笔交易发生时都会使用到， 通常用户类数据归为此类。这类数据如果不考虑水平设计，那么它在机房间的数据拓扑结构如下图，出于降低出错几率，通常设计为一个机房写入，另外一个机房读，如下图:
这类数据如果考虑水平分区，那么它在机房间有类似如下的拓扑结构:
该图片来源: 技术锁活公众号，文章: 从传统银行到互联网，异地多活难不难？
不同机房存不同的分片数据，机房间不复制。这种设计下，跨机房读数是比较明显的。
特点: 从一个机房写入，其他机房都是从写入机房同步,其他机房只能读，通常用户数据归为此类。 db层同步是 单项复制。并且假设这类数据写入后不会马读，读通常会于写之后有一定时差读。
低频全局数据:
这种数据与"
高频全局数据
"类似，全局性，单机房写入，多机房读，不过此类数据使用频率低，配置性数据通常被归为此类。该类数据实施成本低，常规方案即可解决。
四、结尾
本文介绍了异地多活方案单元化实施中的数据分类复制问题。目前主流大公司在实施多活技术时，结合自身业务，大方向都围绕着这样的数据分类规则， 虽各有细节实现差异，但万变不离其宗 。希望你在实践多活方案时，本文的思路能帮助到你，并且在不断实践中，你能做出更好的方案。