孔令俊
作者孔令俊2019-09-04 17:38
软件开发工程师, 建行

分布式模式下数据部署的横平竖直

字数 9806阅读 11130评论 0赞 6

分布式模式下最大的问题就是数据的分布,很早就想总结一下,但各行各业数据类型都不一样,都有自身的特点,很难用一种统一的语言进行描述,某天看到孩子练习书法,我也套用老祖宗的话,“书法要横平竖直”来教育孩子,突然迸发出一个念头,多复杂的字都是从横竖组合而成, ” 横平竖直 ” 是书法领域的基本规则。在数据领域,是否能用这个为起点,用抽象化的概念,阐述数据的特点,从而能够协助各行各业制定分布式下数据模型建立、部署规划和应用改造。

这里我就沿着这种思路,和大家一起探讨是否存在这种可能

一、 定义横竖数据

抽象的第一个命题就是进行定义。最基本的定义就是何为横,何为竖?数据来自于业务,在集中式模式下,数据是一种浑沌状态,不要妄想一下将所有的数据都有序的分开,所有初始都要从一生二开始,我们的初始目标就是将混沌数据分成横竖两仪模式。

从企业的行为主体看,数据的用途永远有两个永恒的属性,一个是面向外部客户的属性,一个是面向内部人员的属性(实际过程中,还有面向监管等,我们也可以根据其要求,划分到内部和外部两个领域),虽然在实际的业务中,很多客户业务也联动企业内部数据,很多企业内部数据也是来源于客户信息的统计,但从本质上,这些数据在可见度永远都存在阴阳的属性,客户是不关注企业内部数据,虽然交易过程中可能发生联动,反之内部数据虽然来源于外部,但并不关注某个具体客户数据的属性,不关注这个人到底是张三还是李四,因为企业不会自发的频繁更改某个客户的数据。

根据这个特征,我们就将企业数据分为两部分:

外部客户数据,就是外部客户要求频繁的增删改查,并察看结果的数据

企业内部数据,企业内部关注的数据

我们就定义:客户数据: 内部数据: 貌似很简单,我们成功将客户数据和企业内部数据分开,通常所讲的企业交易和核算分离也就是如此。

现实很残酷,这种简单粗暴的分离方式,扯断数据之间的关联性,无法应用于实际业务,因为毕竟内部和外部数据存在着千丝万缕的联系,这种数据联系也是我们在做分布式系统所面临最大的问题,从技术上,解决的手段也很明确。

1、 实时分布式事务

基于应用框架(TCC,GTS)、数据库分布式事务(XA)、或者消息队列机制(XA),或者交易冲正等实现的交易一致性,强调的重点就是一致 。

2、 异步数据线传输

基于文件传输、数据库同步、异步消息等,依赖的基础就是非实时,不追求瞬间的一致。

如果从我们的定义来说,其实不论是分布式事务,还是数据传输,这中间的数据对于用户都是不可见的,虽然不一定服务于企业内部的业务人员,但是也是企业内部技术要求而产生的,因此也应符合内部数据(竖)的原则,并且其特点就是传递变化,因此,一个简单的数据模型建立了 。

如果用数据分布来描述

1. 外部数据(客户数据)

2. 传输数据(包含在内外交互过程中产生的数据),主要用来传递双向的变化数据,其实这也是分布式设计中一个关键的环节,由于本文主要讲解数据的分布,我们不做重点讲解。

3. 内部数据(企业数据)

这个模型好不好,非常好,因为简单,实现容易;缺点也很明显:

1、 大量数据交互导致性能很差。因为客户数据和内部数据交互之间将频繁的进行数据交互,即不方便客户行为对内部数据的访问,也不方便内部数据对客户数据的统计。

2、 相互依赖关系很重,彼此干扰。客户行为依赖内部数据的控制,内部数据的汇总依赖客户数据的变化,实际过程中任何一方出现异常都会导致全局的异常。

3、 关联的数据变化产生了分布式事务。内部和外部同时的数据协同变化,就必须依赖分布式事务来保证交易的一致性。

二、 基本数据模型构建

针对上面阐述的优劣,我们可以通过对横竖进行优化,解决性能和相互干扰的问题

a) 内部静态数据采用副本机制。根据数据特点,内部数据的改动往往是周期性、计划性的,外部数据是随机、实时的,因此如果我们可以在外部数据里穿插一些变动较小的内部数据副本,可以极大减少外部数据对内部数据的依赖,提升性能

b) 动态数据建立独立的数据处理单元。如果大量的数据变化都在本地或者传递到内外数据源去加工处理,都会对两者产生极大的性能影响,因此我们引入一个数据汇集地的概念,将双向变化的数据都汇总到汇集地,进行统一的加工处理,然后将结果传递到相应的环节,可以极大地提升性能,减少干扰,因此慢慢演进到如下布局:

如果用数据分布来描述

1. 客户数据+部分内部数据副本

2. 传输数据

3. 内部数据

4. 数据池(部分基础数据+部分变化数据)

这个模型部分解决了客户数据对内部数据的访问性能,也优化了内部数据对客户数据的汇总处理,此外还部分解耦了对同步要求不高的内部数据和外部数据的变化协同,但这个模型也有很多缺点:

1、 副本的产生导致数据的差异,而且需要开发相应的应用捕捉变化并同步数据,因此在 1 , 2 , 3 部分都增加了大量的变化数据处理需求。

2、 如果客户数据或者内部数据很大,依然没有解决性能问题

3、 数据的冗余度增加很多,而且需要额外的设备进行数据池的加工处理,冗余的数据传输,冗余的数据存储,冗余度甚至超过1:1,从成本的角度,性价比较低

4、 内部数据对外部数据汇总的时效性变差(或者说一致性),整体速度依赖于数据池 4 的加工处理能力,而数据池又依赖于各方的变化数据的采集能力,往往按天计算。(一般来说内部数据变化很少引起客户数据的变化,但不排除)

5、 没有解决分布式事务问题。

虽然这个模型不完善,但基本上把企业最基本的数据中心模型描述清楚了,下面我们就开始阐述我们的核心观念,横平竖直 。

如果只有一个横,一个竖,当然就无所谓平直的概念了,实际的业务中,由于客户群体的不同,要求不同,业务的不同等,天然的就形成了很多横,例如个人企业,存款/贷款,同理竖也是如此,有面向会计的内部帐务,有面向实物的管理等,有和客户联动的额度数据,也有只是用于查询的机构员工信息等。因此现实中的数据模型往往如此:

这里的每个框代表一个数据实体,其中1.1,1.2,1.3可以理解为多类客户数据。同理竖3。1,3.2也使如此,代表不同类型的内部数据。

这种模型下,好处就是客户数据和内部数据对于性能的要求被均摊了,缺点也很明显。

1、 数据交互的压力更大,不单局限于内外交互,因为产生了新的内内交互,外外交互,保障一致性付出的代价更高了。

2、 交易链变长了,出问题的概率增加了,原本内->外,实际业务中可能是1.1->1.2->3.1->3.2 …… .

3、 故障的排查也复杂了

4、 横容易不平

5、 竖容易不直

三、 实现横平

何为横不平,不平就是不平均,不平等,不平滑等。

Ø 访问频率不平均,离散度不一样,热点数据资源利用率高,空闲数据的资源利用率很低。

Ø 处理能力不平均,高低参差不齐,处理能力差的环节严重制约整体的并发能力。

Ø 如果存在大量交易依赖少部分数据的情况,一旦出现问题,影响整体的稳定性。

Ø 业务的关联导致部分数据出现故障,业务不能平滑的将故障隔离。

矛盾点

如果只是简单依靠数据的摆放,是很难解这个问题,往往大家都以为分布式不就是把数据分几堆,再加上各分布式事务就好了?其实这里面存在一些无法调和的矛盾,如果追求资源的利用率和故障影响度,最好的方式就是分布的单元很小,数据很离散,但是太离散导致大量的依赖关系,产生分布式事务的概率就越高,并且故障率是伴随分布的离散递增。很难利用数据简单拆分方法找到解决这些问题的平衡点。

分布式事务的危险

我们先用金融里面最常见的涉及两个账户的金融转账业务作为案例,了解一下分布式在实际过程中遇到的一些难点。如果帐户分布式离散,很可能交易双方的数据不在一起,容易产生大量分布式事务;如果按照区域划分,则北京上海这类城市就变成热点,还是没有解决性能和扩展问题;而且在在客户存取款的过程中,总有热点交易客户,例如某大超市的收款帐户,也总有离散客户,例如普通大众的消费帐户,如果按照同一种处理模式处理,不论如何分布,收款帐户的集中属性,很容易引起单帐户高并发,数据的一致性又要求导致帐户必须串行处理,因此很容易产生性能问题,最恐怖的是,这种热点情况下,分布式事务的影响被放大,一旦热点帐户异常,会联动大量的离散帐户被锁定,在二阶段提交模式下,捆绑大量数据库资源。就算采用框架,还是解决不了这种热点客户的性能问题。所以,通常大家都认为分布式最害怕的就是分布式事务,其弊端猛如虎。

沿用上面的存取款案例,我们就用跨2节点的100%转账业务在某节点异常后的影响来分析,图例:

共三个节点,每个节点处理能力100,其中50个取款,联动外部节点50个存款,同时自身还承载50个存款,联动外部50个取款,基本每个节点都是50个取款,50个存款。正常情况下,整体的处理能力是300单帐户处理能力。

当一个节点故障后,整体处理能力只有100,并不是300-100=200,因为有100资源被异常节点的事务锁住(25*4)。

按照这个理论,任何节点异常都要从剩余节点中扣除等量的资源。

4节点=(3-1)/4

5节点=(4-1)/5

N节点=(N-1-1)/N

所以,如果是涉及两个节点的分布式事务,当一个节点异常后,性能将变成N节点=(N-1-1)/N

因此,从性能的角度讲,只要节点数量足够多,单个节点异常差生的性能影响,可以通过多节点消除。(当然如果事务跨度大于2节点,则受影响将更大)

但还存在如下问题,通常的设计下,如果收款帐户出现异常,往往交易流程都是先取款,再存款,因为某节点异常,会导致存款失败,因此必须回滚事务,占用数据库资源,从而堵塞更多的其他交易,导致超时,从而形成雪崩,分布式还真是挺恐怖的。

从上图看,如果产生雪崩,就算回滚资源等同于正常业务,整体有效处理能力也只有50,而且伴随50%的交易失败,并且实际情况中可能更糟。而且伴随数据不平衡,可能会出现如下情况,如果数据分布不均衡。

上述场景,不但资源无法得到充分利用,而且如果热点异常,将导致100%的交易失败。这种情况下,不论怎么分布数据,也无法解决现实的问题,我承认分布式事务真的很恐怖。

但从我的角度,分布式事务是分布式架构的衍生品,我们要做的不是因为分布式事务而摒弃分布式架构,分布式事务有其优势,也有其天然缺点,我们要发挥其扩展性的优势,从设计上,正视偶发的事务异常,避免分布式滚雪球效应,产生某个点引起其他大片点的故障,并引起更多的故障或者回滚,并尽可能从应用逻辑上保障出现异常后,相关数据还能继续办理后续义业务,通过合理的设计和规划降低其产生的概率和异常后带来的后果。

如何做到横平?

1) 第一个平,就是平等

实现相互无依赖或者少依赖,这样可以直接降低分布式事务的产生,也避免了大量的数据交互。在分布式建设过程中,可以参照数据库直方图的原理,对所有涉及多个数据的交易进行多维度的统计,从而得出相互交互可能最少的分布策略

Ø 依赖属性分布式事务比例(图例)

Ø 客户数据分布式事务比例(图例)

Ø 其他更多属性等

从而我们可以很清晰的分析出目前客户的行为模式下,那些客户数据适合放在一起,那些可以分离单独存放,甚至可以分一级,二级分布等模式。

2) 第二步我们利用客户对数据的不同需求做平衡

彻底的消除分布式事务是不可能的,我们要做的就是让分布式事务可控。从上面分布式的风险,我们可以看到,如果都是离散客户之间的分布式事务,其实整体风险还是可控的,通过增加节点数量,就可以降低单个节点数据异常造成的影响。

现实中总有捣乱分子,不可能都是离散化,例如转账业务中,大的客户、腾讯、支付宝都是分布式架构的拦路虎,无论放哪里都是害群之马,因为他们交互属性具备一对多的特质,甚至我们的一些行为,例如发红包,发工资等,都带有这种一对多属性的直接导致性能的不平衡,而且通常采用串行处理,交易性能也是一个严峻考验,这是我们就不但要关注数据,还要从数据的需求来分析,分析客户对数据的要求,根据其需求的不同,在性能和数据上搞平衡

例如,通常数据有如下特点:

数据要求性能要求一致性要求
离散数据关注结果偶发交易,秒级实时
热点数据关注过程多对一,要求毫秒级最终

我们用银行中目前业务量最大的移动消费支付为例,当你是个人用户,你消费一笔钱后,最关注的是自己帐户余额是否正确,但是对于性能,一秒或者两秒都是可以接受,因为非连续操作,而且你不会关注对方帐户余额变化。反过来热点帐户,其余额一直在变化,他们关注的是每个过程中的发生额是否正确,反而目前余额是哪个交易产生的并没有实时的要求(去商场买东西,用手机支付,没有柜员考虑当前余额是具体消费行为后产生的,只要最终余额正确就好),


这里我们再抽象一下数据,数据往往因为过程而变化,过程往往依赖结果而发生,集中模式下这种涉及多方的业务模型是如下表示:

并发情况下,由于排他性,都是串行执行,1,2,3

其核心就是通过分布式事务关联了多个数据的结果和过程,从而保证了数据的一致性。保证A数据结果-A行为过程-B行为过程-B行为结果的全局一致。这种拉链关系很容易产生问题,不论是遇到分布式事务异常,还是热点数据,或者仲裁异常,或者高并发都将出现问题,而且部分行为影响后续行为,也就是如果某个客户支付异常,可能导致后续客户无法支付。

如果实现一种无论发生任何情况都可以即满足性能,也能持续服务的业务逻辑?

我们搞平衡的方法就是通过分析数据的需求特点,通过 数据冗余(增加在途数据或字段),取长补短,串行变并行,将有上下文影响的一对多的关联,变成无上下文关系的一对一的关联。

上图中如果A行为不关注对方结果,可以将一次同步变成两次同步。

Step1:

Step2:

如果B行为允许不关注自身的结果,Step2也可以变成两个独立操作。

按照思路,我们就演示一下如何将一个高度耦合的热点转账行为变成一个无耦合,支持分布式部署,高并发的模式。

集中模式下的转帐往往流程如下:(顺序上可能有差异)

上图中是一个通畅的转账流程,我们可以发现,热点帐户就将变成所有交易的瓶颈,如果两边帐户没有部署在一起,并且无论那边出现异常,双向帐户都将处于锁定状态。如果将业务流程根据业务需求进行改造,关注如下帐户特性:

Ø 存款账户无须立刻到帐

Ø 查询是业务基础

我们可以有如下思路:

l 消费方只负责自身行为和结果的一致(黑色1,2,3,4)

l 通过仲裁分布式事务保证付款行为和收款行为的一致(5)

l 通过对方查询事件触发收款行为和结果的一致( 红色1,2,3,4 )

l 黄色行为 为异步处理模式下的一种拓展

具体流程我就不讲解了,主要思路就是避免大家同时修改同一条记录,不同交易锁定不同的记录。这样不论是正常交易,或者交易冲正,或者是分布式事务异常,都不会产生热点帐户的事务锁。甚至就算热点帐户异常,不进行2,5步骤的处理,还可以通过黄色线条,进行单边处理(前提是离散帐户必须去取款,热点帐户必须是存款),并通过消息保证最终的一致性。

从上面的分析,我们发现我们的数据模型又有了新的变化,耦合点都在在途数据上,而不是客户数据。

该模型有如下优点:

1、 在数据中增加了在途数据的,并用在途数据和外部数据进行分布式事务的关联,用来作为双向的行为绑定记录,由于这些记录是和客户行为绑定,并不会影响后续的交易,由于客户行为的离散性,即使某个行为出现异常,也不会造成雪球效应。而且由于需要同步的只有两个新增的数据(数据库都是insert),后续的修改,也不会面临高并发的压力,从业务逻辑和数据库层面都不容易出现错误和锁。

2、 另外在途数据的存在使交易的幂等性很容易实现,使仲裁的交易的重发和冲正都相对简单,在保证一致性上也很容易。分布式环境下,幂等的重要性非常大,特别是风不是框架下。

3、 缓存数据的出现,分担了更多的压力,更利于分布式的建设。

缺点也不能不提:

Ø 在途数据的出现,数据模型中,需要对每个涉及多个客户数据的变更,都产生相应的在途数据,设计过程中,还需要设计某种异步机制进行这些数据后续处理,并且应用逻辑上可能变复杂,数据上要增加附加的字段

Ø 由于存在在途数据,部分客户数据无法实时反映实际结果,因此对于数据池4的数据的提取和统计分析提出了更高的要求。

Ø 缓存的出现又增加了数据复制要求,虽然可以从应用上进行完善,先访问缓存,不存在再访问主体库,并根据结果更新缓存,但是还是增加了很多的应用开发和复制。

Ø 同时2环节压力更大,变化数据中,又出现了在途数据的变化传递,还要处理异常情况下的查询和重发

3) 第三个平我们来解决平稳问题

数据分布的离散,导致出故障的概率增加,虽然有各种高可用的保护,但是很多情况下高可用还没有生效,持续的业务失败已经将服务压垮,导致大量冲正或者不一致,这里也没啥好办法,就是用时间换可靠,尽量避免回滚的发生。

在分布式模式下,单笔交易的性能已经不是主导并发的关键因素,因此分布式模式我们可以通过适当的增加交易逻辑,来减少异常情况下恶性事件的出现

解决的思路很简单,就是通过预读来避免回滚,就算没有在途数据,也是如此:

避免如下情况:

通过提前的预读,解决因为节点或者性能异常造成的大量回滚,尽管可能耗费一定的资源,但是对于应对节点故障或者性能异常,可以有效地降低错帐和冲正以及帐务不一致的数量。

总结:

其实我们还可以通过对“横”更多方面 有取有舍 ,构造一个相对“平”的客户数据的访问环境,不要幻想把数据分开就是平分,在有效的数据分离的基础上,还要多在数据模型和业务逻辑中下功夫,通过数据冗余及逻辑冗余在平衡各方面的需求;业务逻辑中,对于涉及多边交易的环节,不要想当然的理解为 转帐=取+存 ,应该针对性的设计 “在途取”“在途存” ,来满足解耦的业务要求,也不要幻想分布式事务能解决一切问题,完全可以从业务上牺牲一小步,换来整体系统稳定的一大步。客户是上帝,但上帝不会提非分要求,很多过于高大上的业务目标都是画蛇添足,经常搬石头砸了脚。

总结一下技术上的 “横平”的评判依据:

Ø 分布式事务尽可能少,数据平等,独立,

Ø 分布式事务下,分布锁尽可能离散,平均,不产生热点

Ø 锁不影响结果数据,最好锁行为数据,这样无上下文关联,不造成连锁反应,业务运行平稳

Ø 通过一下必要的查询动作,提前评判参与者状态,故障发现及时,平滑处理异常情况,不要做了才知道错了,要能成功才做。

PS:如果事务非常离散,没有热点,其实大部分分布式数据库都能很好的承接业务。

四、 竖直

其实前面横“平”的很多原则都适用于竖,横之间的矛盾也存在于竖之间,竖和横之间,也可以采用上面的一些原则。同时,由于竖还有自身的一些特点,因此对于竖,我们本章强调重点就是直。

何为直

大家都知道,在两点之间,直线最短,这里我们的要求竖的要求就是最短。

如果说横是要体现较高的并发,则竖就是要最好的性能,因为横大部分是以单个客户为主体,数据量有限,但是竖是内部数据,关注的是大量客户数据的统计结果,性能是一个主要指标。

不直的后果

其实用互联网业务和传统金融业务对比就知道,互联网采用的是扁平模式的企业模型。

而金融业务则由于历史原因,往往如此结构。

这两种模式其实和传统的三层网络架构以及目前流行的spine-leaf网络架构类似(有点跳跃)。

传统金融关注南北的数据,关注数据的按层汇总,但是和网络发展一样,随着数据的增加和分布的需求,东西流量现在变成了矛盾的焦点,大量的客户之间的行为,也导致了内部数据之间的交互非常频繁,如果还采用这类层级的架构,最终的企业数据变成热点,另一方面频繁的机构之间数据交互也压力很大,而且内部数据之间的加工处理还要依赖其它内部数据的数据交互。整个交易链冗长,内部数据之间存在行为的依赖关系(图例,不代表实际业务)。

在分布式模式下,如果还沿用这种串行模式,性能将受到很大的影响,优化的模式应该如此。

如何做到竖直

第一步就是减竖

优化业务模型,要尽量降低层级数据的概念,对于内部汇总类数据,现实中没有实时性的数据要求,对这些数据的加工处理尽量异步完成,避免和联机交易发生太多的交互

可以想象一下,如果没有机构,网点,区域,级别的约束下的分布式是多简单的一个概念:

变成:

第二步就是数据上分竖

其实我们前面那些缓存,也是分竖的一种,不但能贴近横,也能更贴近其他的竖。

同时一些不相关的竖,我们坚决分开存放,这样不但有利于分布,还能提升性能,减少相互干扰。

第三步,数据操作逻辑上并竖操作

众多的竖线,如果都是串行链接,其性能将大受影响,要理解内部数据的变化往往是由于外部数据的变化,此时我们完全可以把竖都并起来,从而提升性能。

题外话:之前不太理解IBM的BPM为啥那么贵,其实在分布式过程中,一个好的BMP真是核心中的核心。如果能用好了,真是事半功倍。

当然,并行的处理对于开发的复杂度增加了不少,特别是异常情况的处理,同时可能作了很多无用功,但如果实际业务中成功交易比例居多,这种模式其实也不会导致资源增加过多而且分布式下,最不缺的就是资源。

第四步,均竖

实际的实现中还要保障A,B,C的长度平均,这样才能使最终的耗费时间最短。

第五步竖的操作原子化(其实横也有这个要求)

由于数据池的存在,在并行的基础上,内部数据服务的原子化能够极大降低每个竖自身的长度,同时也避免造成间接依赖。

避免如下场景:

A依赖B ,(B内部依赖C),C内部依赖D

第六步竖的瘦身,降低热点

从互联网经验,我们也可以看出,太多的竖的要求都是性能提升的障碍,随着发展,各种地域、机构、人员等概念越来越模糊,此类数据应该尽量减少。

另外对于涉及竖的操作的客户行为应该避免不必要的准确、实时要求,例如一些相关的一些销售限额控制,特别是跟客户行为关联的企业控制行为。

简单的例子,企业的发售限额行为,通常是抢购,如果每笔都查询限额,就是灾难,其实客户是不关注的这些的,客户关注的是买进了还是没买进,没强求一定要买,大部分也没有实时的要求,这种把竖强加于横的做法,也是分布式建设中的拦路虎,特别是人为制造N对一模式的业务行为。这方面,完全可以参考火车售票行为,将这种有限额的活动变成客户申请和查询,企业后端异步对列处理的过程,手机和窗口优先级区分。

1) 用户查询当前模糊查询企业数据,或者定期同步的企业副本数据(查询当前车票余额)

2) 变更客户数据,生成客户行为在途(扣除金额,生成购票需求,标示未提交)

3) 仲裁发起客户在途行为和企业在途行为的同步(生成火车分票行为,标示为未处理,设置客户购票标示已提交)

4) 企业发起并行请求处理对列,逐个处理,并修改企业行为标识(可以根据列车,时间等生成处理请求对列,每个对列察看当前列车余额,如果没票,阻塞等待,如果有N张票,从企业行为中查找<=N条未处理的买入该列车乘票行为,修改企业行为标识为已处理,修改企业数据为已销售,生成在途成功买入信息,如果超过S时间没票,删除当前时间-请求时间>S的未处理请求,并生成在途申请失败,并未冲正的反馈信息)

5) 通过客户查询,判断是否有金额回退或者已经买入,处理失败行为(如果存在客户购票行为,查询在途反馈信息,如果成功,显示,如果失败,发起金额回退,设置失败已处理表示)

从设计中,通过这种异步的处理,把大量高并发串行行为变成可控的有序行为,并且实现了过时取消的能力,设置成定期排队处理(可以卖定量后,取消所有请求对列,让客户从新申请,但客户体验较差)。同时,还可以设计请求的优先级,优先服务窗口的购票行为,冲正或者取消都很容易设计。

同理的票据号,凭证号,现金控制,存量控制等,都会有类似的情况。

五、 目标

现实数据的复杂性远不是横竖就能简单表示的,但一生二,二生三,三生万物,写字也不简单只有横竖,我们可以继续寻找横竖(内部数据,外部数据)的阴阳属性,继续分解组合,形成自己的分布式的数据部署,正如太极的演化,简单的几个符号就能包罗万象。

六、 后续

在分布式的建设过程中,产生的的传输数据的处理也是十分关键,因为数据传输就像是大脑和经脉,联系着多方面的数据需求,后续有机会我们再设想一下,分布式下到底有哪些过程数据需要处理和传输,需要的技术能力到底有哪些。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

6

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广