什么是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开启强一致，对性能损耗就大，因为至少大于二分之一的节点写入文章来源：https://www.toymoban.com/news/detail-442120.html
所以可靠性和性能是冲突的文章来源地址https://www.toymoban.com/news/detail-442120.html
到了这里，关于三地五中心（ldc(逻辑数据中心）单元化）和容灾的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
