关于分布式:分布式分布式基本理论

36次阅读

共计 2074 个字符,预计需要花费 6 分钟才能阅读完成。

一.CAP 定理:

Consistency 一致性

同一个数据的所有备份,在同一时刻是否有雷同的值。一种比拟常见的强一致性实现就是,在看到统一的后果之前,写申请不返回,读申请阻塞或者超时

Availability 可用性

在集群中一些节点故障时,集群还能够响应读写申请

Partition-tolerance 分区容忍性

分布式系统具备多个节点,如果节点间网络中断,就会造成分区

CA 零碎

不容许分区(也就只能单机零碎了), 例如单机数据库 mysql

CP 零碎

不要求高可用, 但要求强一致性. 并且节点间传输数据失落导致未同步,要么重试, 要么更新失败, 回滚数据, 例如 Paxos,2PC,3PC,RAFT 等

AP 零碎

要求高可用, 不必强一致性. 产生分区时, 节点间的数据可能不统一, 每个节点用本人的本地数据提供服务. 个别该类零碎都会实现最终一致性, 即分区完结后, 通过一些机制同步数据.

二.BASE 实践

BASE 实践是 Basically Available(根本可用),Soft State(软状态)和 Eventually Consistent(最终一致性)三个短语的缩写。

BA 根本可用

  • 响应工夫上的损失:失常状况下的搜索引擎 0.5 秒即返回给用户后果,而根本可用的搜索引擎能够在 2 秒作用返回后果。
  • 性能上的损失:在一个电商网站上,失常状况下,用户能够顺利完成每一笔订单。然而到了大促期间,为了爱护购物零碎的稳定性,局部消费者可能会被疏导到一个降级页面。

S 软状态

容许零碎中的数据存在中间状态,并认为该状态不影响零碎的整体可用性,即容许零碎在多个不同节点的数据正本存在数据延时。

E 最终一致性

存在一个期限, 在期限过后,该当保障所有正本保持数据一致性,从而达到数据的最终一致性

三.2PC 协定

第一阶段:筹备阶段(投票阶段)
第二阶段:提交阶段(执行阶段)
如 mysql server 记录 binlog 后 发送 sql 语句让引擎 (innodb) 执行, 引擎执行结束记录 redolog 后返回执行胜利给 server,server 再下发命令提交事务.

缺点:
网络抖动导致的数据不统一:第二阶段中协调者向参与者发送 commit 命令之后,一旦此时产生网络抖动,导致一部分参与者接管到了 commit 申请并执行,可其余未接到 commit 申请的参与者无奈执行事务提交。进而导致整个分布式系统呈现了数据不统一。

超时导致的同步阻塞问题:2PC 中的所有的参与者节点都为事务阻塞型,当某一个参与者节点呈现通信超时,其余参与者都会被动阻塞占用资源不能开释。

单点故障的危险:因为重大的依赖协调者,一旦协调者产生故障,而此时参与者还都处于锁定资源的状态,无奈实现事务 commit 操作。尽管协调者呈现故障后,会从新选举一个协调者,可无奈解决因前一个协调者宕机导致的参与者处于阻塞状态的问题。

四.3PC


CanCommit:协调者向所有参与者发送 CanCommit 命令,询问是否能够执行事务提交操作。如果全副响应 YES 则进入下一个阶段

PreCommit:协调者向所有参与者发送 PreCommit 命令,询问是否能够进行事务的预提交操作,参与者接管到 PreCommit 申请后,如参与者胜利的执行了事务操作,则返回 Yes 响应,进入最终 commit 阶段。一旦参与者中有向协调者发送了 No 响应,或因网络造成超时,协调者没有接到参与者的响应,协调者向所有参与者发送 abort 申请,参与者承受 abort 命令执行事务的中断。

DoCommit:在前两个阶段中所有参与者的响应反馈均是 YES 后,协调者向参与者发送 DoCommit 命令正式提交事务,如协调者没有接管到参与者发送的 ACK 响应,会向所有参与者发送 abort 申请命令,执行事务的中断。

三段提交(3PC)是对两段提交(2PC)的一种降级优化,3PC 在 2PC 的第一阶段和第二阶段中插入一个筹备阶段。保障了在最初提交阶段之前,各参与者节点的状态都统一。同时在协调者和参与者中都引入超时机制,当参与者各种起因未收到协调者的 commit 申请后,会对本地事务进行 commit,不会始终阻塞期待,解决了 2PC 的单点故障问题,但 3PC 还是没能从根本上解决数据一致性的问题。

五.TCC

TCC(Try-Confirm-Cancel)又被称弥补事务,TCC 与 2PC 的思维很类似,事务处理流程也很类似,但 2PC 是利用于在 DB 层面,TCC 则能够了解为在利用层面的 2PC,是须要咱们编写业务逻辑来实现。
TCC 它的核心思想是:” 针对每个操作都要注册一个与其对应的确认(Try)和弥补(Cancel)”。

还拿下单扣库存解释下它的三个操作:
Try 阶段:
下单时通过 Try 操作去扣除库存预留资源。
Confirm 阶段:
确认执行业务操作,在只预留的资源根底上,发动购买申请。
Cancel 阶段:
只有波及到的相干业务中,有一个业务方预留资源未胜利,则勾销所有业

TCC 的毛病:

利用侵入性强:TCC 因为基于在业务层面,至使每个操作都须要有 try、confirm、cancel 三个接口。
开发难度大:代码开发量很大,要保证数据一致性 confirm 和 cancel 接口还必须实现幂等性。

正文完
 0