三地五中心（ldc(逻辑数据中心）单元化）和容灾

什么是LDC

LDC 的全称为: Logic Data Center, 逻辑数据中心，之所以叫LDC，是跟传统的IDC（ Internet Data Center ）相比而提出来的概念。

IDC 相信大家都很清楚，就是物理的数据中心，说白了就是能够建站的物理机房。

LDC（逻辑数据中心），核心架构思想就是不管你物理机房部署是怎样的，比如你可能有三个IDC，分别在二个不同城市（常说的两地三中心），在逻辑上是统一的，我逻辑上看成一个整体，统一协调调配。

三地五中心，每个中心都是单元化架构，独立的，没有灾备（灾备的话再下面三地五中心的灾备里面会讲）的概念了，每时每刻生产流量运行的

其实每个中心都是另一个中心备份，但时都是生产数据中心，每时每刻对外提供服务

数据中心双向数据同步，这样不会出问题

对比：

两地三中心 主中心出故障的话，但是切换不是立马能切换的，因为要各种检查网关路由之类的

三地五中心就是搞单元化架构了 

ldc 单元化的负载策略和 两地三中心不一样 ，按照用户去id去路由到指定的中心去，而双活按照流量随机路由

 

单元化架构最小组成就是 zone ，一个独立的逻辑单元

每个单元的服务和数据完全隔离 不受别的单元影响，每个单元都是独立的

rzone 指的就是三个单元

每个rzone里面的比如 zk之类的注册中心也是完全隔离的

每个应用也是完全对等 比如第一个单元四个节点，那么第二个应用也是四个节点，即资源对等

三地两中心和三地五中心最大差别 尤其是是数据层面的，因为双活同步数据（数据库）是双向同步的，存在数据冲突问题，三地五中心不存在这个问题，每个中心数据独立的，跟其他机房同步数据不会出现冲突，灾备的话会有fo解决，下面会说。

还有个不同 就是上面讲的双活流量负载均衡，单元化是 用户id之类路由的

所以这样看三地五中心高可用能力更强

rzone 如果是跨机房访问的话，那么可能性能比较差，所以这里出来个gzone

gzone维护全量的数据，所以全量读的话都在gzone里面

否则如果有的数据需要三个机房数据查出来汇总聚合，那么这样的话效率差，稳定性不好。

rzone是按照用户纬度拆分，比如交易可以按照用户id负载均衡做rzone

但是有的不好这么拆分，比如全局性的规则配置，值对象数据等，强行分开的话维护和效率比较差，那么这种就使用gzone去维护，下面举个例子来说明

比如合同，早期有一个模板，模板是全局性的数据，

rzone里面的用户需要的合同模板的话就去gzone获取合同，然后再rzone生成这个用户的合同数据

gzone是独立的，只能存在一个地方，不能存两三个地方

gzone是解决全局性数据查询复杂度的问题（全局性数据访问都在这边）

所以rzone一般来说是局部读写，不能跨机房访问其他zone，除非做容灾能力才会切换访问 

总结如下：

数据不利于查询: Gzone 来存储需要提供外部使用的公共数据，此时 Gzone 只处理读请求

1、对于符合Rzone拆分的业务，只从Rzone中读写数据，所有读写请求通过路由层进行分发。 2、对于不能拆分的业务，抽离出来后单独部署于 Gzone 中 

但是这样的话gzone会有性能问题因为只放在一个机房，其他机房都来访问

所以使用czone解决，下面我们来说czone

czone 解决跨城市问题： 

 

每一个城市的每一个机房加一个czone 

gzone数据存储同步到czone，这样rzone访问本机房的czone

一般来说，全局性数据的写频率比较低，读的频率比较高， 对延迟有容忍度的，不需要太高，所以可以这样从gzone同步到czone里面

双十一 也是这个架构，因为性能没法提升那就只能用架构提升 

因为应用性能优化到这个地步已经不会有太大空间了

总结下：

跨机房城市延迟: 其一：

服务间调用优先 zone 内调用，减少跨zone的请求；

其二 ：跨 zone 调用优先请求同一物理机房；

其三：Rzone 调用 Gzone 情况下，无法避免跨机房访问，则在每个物理机房添加一个 Czone 用来同步 Gzone的数据，提供给同一机房内其他 zone 调用 （这样整个请求都在逻辑单元如rzone里面闭环，跨zone调用优先还是在本机房里跨zone调用，这样请求耗时不会有太大问题。）

这样的话就有一个调用的优先级：

ZONE访问顺序: R>C R>G C>G G>R

解释如下：

gzone（架构层面的设计，解决全局数据问题）可以调用rzone数据，因为全局数据可能需要rzone数据来聚合，比如客服需要用户数据来查询rzone里面的数据 ，不同用户在不同rzone里面，那么这时候就需要调用不同的rzone然后聚合

gzone调用czone坚决杜绝，因为czone从gzeon同步数据的

每个服务都有标签，这样gzone发现访问的是czone就不会去访问

LDC-架构约束

LDC约束:

1、每个rzone不能连接gzone的db和其它存储

2、czone不能连rzone的db和其它存储

3、rzone gzone可以连czone的db和其它存储

4、rzone中的db rpc msg都要实现uid sharding

5、rzone只能连本zone的 uid相应的存储

6、RPC调用顺序:R->C R->G G->R G->C不允许C->G C->R

我们先来回顾下双活的数据同步方式： 

uid 0和uid1的用户：

都是随机访问的，所以两个机房都可能访问到

数据库是双主模式

uid1的用户在左边库产生数据 会异步同步到右边库,反过来右边库的数据也会异步同步到左边库

这种适合日志这种容许丢失的数据

不容许数据丢失的话那就使用一主一备，只不过这样的话数据时效性就有慢了

 

主和从节点，   主节点产生数据同步到主节点的库是没问题的 ，如果访问到从节点即第二个机房怎么办呢

从节点即机房2会把数据达到主节点即第一机房然后再同步过来到第二个机房来，也就是说不管怎么样 uid1的用户数据都会来到机房1的主数据库 

三地五中心数据同步方式

uid1会直接打到第一个zone，uid2打到第二个zone，uid3打到第三个zone，这三个db是完全独立的，每个zone都是隔离的不会去相互访问，不同的zone不会做数据同步（数据同步会做容灾fo这样的，下面会说）

三个zone的数据都会回流到gzone里面那么就可以全局读了 

LDC-如何解决异地调用问题？

 这里硬负载指硬件负载，vip就是虚拟ip

服务级容灾：也就是本机房找不到服务那么就跨机房调用

其中

 跨机房调用的代理，因为每个机房里面zk都是独立的别的机房不知道的，所以通过这玩意找到别的机房的指定服务

接下来说容灾，先再来看一张三地五中心的架构图

 db和应用的数字可以理解为分片00-19id的用户路由到第一个机房处理这样。

机房1 故障怎么容灾：三地五中心的容灾架构

应用级层面：只要应用无状态切到机房2里面的应用。

 数据库里面有fo

也就是说其他机房的库在机房里面都有

这样支持同城级容灾，也支持跨城级容灾从可用性来考虑了，这样才能说达到4个九的目标的

容灾场景：1 2 和3三个用户

uid为1 的 机房1不可用了，会去机房2访问，跨zone访问  

 这里特别提一句，机房内的高可用上主库不能用那么就访问备库，这是应用层面的高可用

机房级高可用 ：请求打到机房2的 fo里面的00的库 

同理 ，上面是同城容灾，要是同城都挂了直接打到异地机房三的of库的 00-19里面

最后灾备期间的fo数据（例如上面本应该在机房1结果打到机房2的数据库的流量）都要回写到主库（就是数据回迁了，因为00-19的主库机房1恢复了）

，然后主库需要回写到别的fo库，容灾过程的话需要应用去做 业务层，因为 mysql 和oracle 很难做到强一致 

这里有三个状态：

不可用就是fo状态，数据要写入fo库

fb状态 fallback回迁状态，回迁到主库就变成normal状态，这样流量就可以迁移回来了

机房级切换：应用无状态，业务层做容灾逻辑，因为数据库侧无法保证

就算oceanbase开启强一致，对性能损耗就大，因为至少大于二分之一的节点写入

所以可靠性和性能是冲突的