• 分布式理论


    ------------恢复内容开始------------

      分布式系统概念:一个硬件或软件组件分布在不同的网络计算机上,彼此间仅仅通过消息传递进行通信和协调的系统。

      分布式存在的问题:

        1.通信异常:通过网络通信(中间可能出现各种情况导致通信异常)

        2.网络分区:网络异常  导致分布式部分节点之间不能正常通信

        3.三态:指成功、失败、超时(消息丢失)    

        4.节点故障:组成分布式系统的服务节点宕机  

    分布式理论:一致性概念

        一致性又分为:1.强一致性:实时保证数据一致性   要求系统写入什么,读出来就是什么。实现起来对系统的性能影响很大。

                  2.弱一致性:尽可能保证数据达到一致性 

                  3.最终一致性:系统在一定一时间内,一定保证数据一致性。

    分布式事务

        分布式系统中数据分散在不同机器上,而分布式事务就是指事务的参与者,支持事务的服务器以及事务管理器分别位于分布式系统的不同节点上,通常一个分布式事务中会涉及多个数据源或业务系统的操作。

    分布式理论:CAP定理

          分布式系统不能同时满足 一致性:指上面所说的强一致性

          可用性:系统提供的服务一直可用

          分区容错性:遇到网络故障,还能继续提供服务。

    分布式理论:BASE理论

          是对CAP中一致性和可用性权衡的结果,核心思想:当无法做到强一致性时,但每个应用可以根据自身的业务特点,采用适当的方式来使系统最终达到一致性。

          基本可用:在系统出现故障时,允许损失部分可用性  不等于系统完全不可用。

          软状态:要求多个节点的数据副本都是一致, 这是一种硬状态,软状态是指允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性,也就是允许系统在多个不同节点的数据副本之间进行数据同步的过程中存在延迟。

          最终一致性:分为5类

              1.因果一致性:节点A更新一个数据,通知节点B,那么节点B之后对该数据的访问和修改都是基于A更新后的值。节点A与节点C无因果关系,那么节点C得数据访问则没有这样的限制。

              2.读已知所写:节点A更新一个数据后,它自身总是能访问到最新的值,看不到旧的值。

              3.会话一致性:将系统数据的访问过程框定在一个会话当中:系统能保证在同一个有效的会话中实现“读已知所写”的一致性。执行更新后,客户端能够在同一个会话中始终读取到该数据的最新值。

              4.单调读一致性:一个节点读取出一个数据,那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。

              5.单调写一致性:系统要保证同一个节点的写操作被顺序执行。

          总结:BASE理论面向的大型高可用可扩展的分布式系统,和传统事务的ACID是相反的,它完全不同于ACID的强一致性模型,而是通过牺牲强一致性来获得可用性,并允许数据在一段时间是不一致的,但最终要保证数据一致。

    分布式理论:一致性协议(二阶段)2PC

          2PC:即两阶段提交。为了使基于分布式系统架构下的所有节点在进行事务处理过程中能够保持原子性和一致性而设计的一种是算法。作用:保证分布式系统数据一致性。

          一阶段:1.调度者发起事务询问,并开始等待参与者响应 2.参与者节点执行事务,并将Undo(保证事务的一致性)和Redo(保证事务的原子性和持久性)信息记入日志中。 3.各参与者想调度者反馈事务的询问响应。

          阶段二:执行事务提交  步骤如下:

              1.发送提交请求:调度者向所有的参与者发起Commit请求。2.事务提交:参与者收到commit请求,会正式执行事务提交,并且提交后释放整个事务执行期间占用资源。3.反馈事务提交结果:参与者在完成事务提交后,想调度者发送ACK信息(确认消息) 4.完成事务:调度者接收到所有参与者反馈的ACK信息,完成事务。

         中断事务:   触发条件  阶段一 有参与者对询问响应NO 或超时  就会执行中断事务。

          1.向所有参与者发送回滚请求 2.参与者收到请求,借助Undo执行事务回滚。完成回滚后释放整个回滚占用资源。

          3.参与者反馈事务回滚结果,向调度者发送ack信息。4.中断事务:调度者接收到所有参与者的ack信息,完成事务中断

          总结:二阶段做了两个事情  投票  执行。 核心是对每个事务采用先尝试后提交的处理方式,从而保证其原子性和一致性,因此可以将二阶段提交看成一个强一致性的算法。

        优点:原理简单,实现方便。(投票,执行)  

        缺点:同步组撒问题 单点问题 数据不一致 过于保守

          同步阻塞:限制了分布式系统性能  执行过程中,所有参与者(Cohort)节点都是事务阻塞型。各个参与者(Cohort)在等待其他参与者响应的过程中,将无法进行其他任务操作

          单点问题:如果调度者崩溃了  其他参与者会处于锁定状态。

          数据不一致:网络原因导致 部分执行了事务提交,部分没有执行。

          过于保守:没有容错机制,任意一节点失败,所有事务都会失败。

     分布式理论:三阶段提交协议(3PC)弥补2PC的缺点

          弥补的地方就是将2PC的一阶段 一分为二 形成3PC。

        阶段一(CanCommit):1.事务询问:

                      调度者会向所有的参与者发送一个包含事务内容的请求,询问是否可以提交事务操作,并开始等待各参与者响应。

                   2.各参与者向调度者反馈事务询问的响应:

                      参与者如果认为自身可以顺利执行事务,则反馈YES响应,并进入预备状态,否则反馈NO响应。

        阶段二(PeiCommit):根据响应结果有2种执行操作。

                     1.调度者发送事务预提交请求

                     2.参与者执行事务预提交

                     3.各参与者向调度者反馈事务执行结果,并等待最终执行命令(事务成功执行了反馈ACK)

                     2.中断事务(任意参与者反馈NO响应 执行中断事务)

                     1.调度者向所有参与者发送事务中断请求

                     2.中断事务:1.收到调度者发起的中断请求  2.等待调度者请求超时了。

        阶段三(DoCommit):1.真正事务提交

                    1.调度者发送提交请求。 2.所有的参与者接收到后开始正式执行事务提交操作,并在提交完成后释放事务提交过程中所占事务资源。3.所有的参与者完成提交后,想调度者发送Ack响应。 4.完成事务

                    2.事务回滚

                     1.调度者发送中断请求

                     2.参与者跟Undo信息执行事务回滚,并在回滚后释放整个事务执行期间占用资源

                     3.参与者完成事务回滚后向调度者发送ACK响应。

                     4.调度者收到响应,完成中断事务

        PS:进入阶段三可能会出现两种故障 1.调度者出现问题  2.调度者与参与者发生网络故障。 进入阶段三后:等待超时后,参与者会执行事务提交。

          如果是中断超时,会发生数据不一致问题。

        优点:1.降低了3PC的参与者阻塞故障 2.单点故障后继续达成一致。

        缺点:出现网络分区,无法进行节点通信  部分节点执行事务提交 或部分节点执行事务回滚

        2PC对比3PC:

          1.参与者与调度者都有超时机制(2PC只有调度者有超时机制,默认时间没有收到消息,默认失败)

          2.3PC在2PC准备阶段与提交阶段之间插入了预提交阶段

          3.PreCommit是一个缓冲,保证在最后提交阶段之前各参与者节点状态一致。

    分布式理论:一致性算法Paxos(拍可搜)  目前公认解决一致性问题的有效算法

          解决的问题:分布式一致性问题。  如何在一个可能发生异常的分布式系统中,快速且正确地在集群内部对某个数据的值达成一致,并且保证不论发生任务异常,都不会破坏整个系统的一致性。(引入多个调度者)

          Paxos概念:有一个概念叫提案,最终要达成一致的value就提案里。

            提案:提案信息包括提案编号和提议的值

          在Paxos 算法中,有三种角色

            1.Proposer:提案发起者

            2.Acceptor:决策者,可以批提案

            3.Learners:最终决策的学习者

            PS:具体实现中,一个进程可以充当多种角色。

          那么Proposer 、Acceptor 、Learner分别在什么情况下才能被认为某个value被选定呢?

            1.Proposer发起的提案被Acceptor接受(刚开始只需要一个,推导过程中需要半数Acceptor同意),Propose就认为该提案的value被选定。

            2.Acceptor:只要Acceptor接受了某个提案,Acceptor 就认为该提案里的value被选定了。

            3.Learner:Acceptor告诉Learner那个value被选定了,Learner 就认为那个Value 被选定了。

          推导过程

            一个Accpetro必须接受它收到的第一个提案

            规定:一个提案被选定需要被半数以上的Acceptor接受      

                  

                           

                   

          

    ------------恢复内容结束------------

  • 相关阅读:
    Mysql 如何设置字段自动获取当前时间
    如何利用OCS缓存TomcatSession全局变量(转)
    CDN技术分享
    怎么在阿里云服务器部署多个tomcat
    nginx模块开发篇 (阿里著作)
    Nginx开发从入门到精通 学习目录分享学习 (阿里著作)
    阿里云 通过YUM源安装nginx
    Java 模板引擎 jetbrick-template
    七天学会NodeJS
    Android开发之蓝牙 --修改本机蓝牙设备的可见性,并扫描周围可用的蓝牙设备
  • 原文地址:https://www.cnblogs.com/qi2332356/p/13450663.html
Copyright © 2020-2023  润新知