第二章数据复制与一致性

2.1 CAP BASE ACID

C: consistency,强一致性
A: available 可用性,对于request系统在有限时间内做出响应的能力
P: Partition Tolerance,分区容错性,即发生网络分区时,系统依然可以工作

cap定理:C A P无法兼得,最多同时满足其中两个。这个定理可以这么理解,如果我们的系统对数据没有
采取同步措施,那么读数据可以立马返回,但是数据可能会出现不一致,如果采取了同步措施来保证强一
致性,那么一定会影响系统的可用性。但是这个定理只是说明不可能设计出完美的系统满足cap,但是C
与A并不是非0即1,而是连续的变量,我们需要做的是在两者之间权衡。
--书上有具体证明
A: atomicity 原子性,一个事务操作要么全部执行成功,要么一条也没有执行
C: consistency,一致性,事务开始和结束时应该满足系统的一致性约束条件,比如系统要求A+B==100,那
               么无论执行了什么事务,A+B的值必须是100
I: isolation,隔离性,事务之间的操作是互相隔离的,对应的隔离级别有,读未提交,读已提交,不可重复     读,串行化
D: duratioon,持久性,事务成功执行后,更改是永久的
BA: Basicaly Avaliable,允许偶尔的失败,基本可用
S: Soft State,软状态,系统不要求数据在任意时刻都是一致的
E: Eventual Consistency,最终一致,数据需要最终一致的,结合软状态,就是说系统中存在一个数据不一致的窗口。

传统数据库的设计思路是ACID,强化数据一致性,现在大多数的Nosql数据库设计思路是
BASE,弱化数据一致性来获得高可用性。

补充:幂等性
在分布式系统中幂等性设计很重要,因为可能一个操作已经执行成功了,但是由于网络的原因,调用者没有收到ack,那么就会产生重复执行。

2.2 一致性模型分类

  1. 强一致性
  2. 最终一致性
  3. 读你所写一致性
  4. 因果一致性:进程A更改值后会向B发送信号,但是不涉及其他进程
  5. 会话一致性:客户端与系统在一个会话内是读你所写的,如果另起一个会话还是可能读 到旧值的
  6. 单调读一致性:如果值v被读到,那么后续的所有读操作得到的值不能比v旧
  7. 单调写一致性:一个进程所有的写操作,该进程看来是顺序操作的,不能执行两次i++,后实际是分别在两台节点各执行一次

2.3 副本更新策略

  • 同时更新
    采样一致性协议来确定请求的执行顺序,否则,节点之间就执行顺序无法达成一致,就会出现有的节点先i++在i=i*i,有的则相反,就有bug了。缺点时,采用一致性协议会带来一定的延迟。
  • 主从式更新
    A: 同步更新,数据强一致,但是请求延时较大
    B:异步更新:减弱数据一致性,增强请求实时性
    C:混合方式:A和B是两个极端,要么数据全部一致,要么不去管其他副本让其自动更 新,我们可以定义一次写操作至少副本同步更新的数量W,可以是0-n的任意值、可以请求延时与副本更新之间权衡。
  • 任意节点更新
    类似于主从,只不过它没有主节点,任意节点都可以是更新的发起者

2.4 一致性协议

  • 两阶段提交协议
    如图,有两个地方会发生阻塞,可以引入超时判断与参与者互询机制来避免长时间的阻塞。超时判断机制可以避免协调者长时间等待,超时判断机制和参与者互询可以避免绝大多数的参与者长时间阻塞的情况,比如当他询问到其他参与者还是init,他就发送absort信号,如果是commit,那么它自动commit。只有一种情况,那就是它询问到的参与者都是ready,那么只能等待崩溃的协调者自己恢复了。三阶段提交协议解决了这个问题但是其时延太长,同时这种情况发送的概率较低所以很少使用它。
    如果一个协议有阻塞态,那么这个系统是一个很脆弱的系统,因为一旦有某个进程挂掉,很有可能使得其他进程长时间陷入阻塞态在这里插入图片描述

  • 向量时钟
    在分布式环境下可以确定事件之间偏序关系的算法。
    算法描述:分布式环境,多个进程可以互相通信,每个进程i对某一块数据维护了一个向量时钟Pi=[0,0…,0],其中第j位数代表进程i看到的进程j的逻辑时钟,每个 向量时钟以下列规则更新
    1. 本进程i发生一次事件(我暂时理解为对数据进行一次写操作),该进程向量时钟的第i个数++
    2. 进程间发送消息时,对带上数据对应的向量时钟
    3. 当进程接收到消息后,会根据收到的向量时钟进行比对,如果某位对方的大,则更新为对方的
    对于两条消息E,F如果E任意一项都大于等于F的,并且不想等,那么我们可以知道E中的数据新于F的,可以将E,F中的数据合并为E的。

    具体的示例

  • RWN协议
    即每次写保证W份写成功,每次读保证读取到R个节点,并且W+R>N,首先它可以保证每次读取的都是最新的,而且可以根据场景进行灵活配置W和R。其次仅仅时RWN协议还不能保证每次读最新的数据,一般配合向量时钟来从R份数据中跳出最新数据。

  • Paxos协议
    Paxos协议的重点是定义了什么时候视为成功做出了决议,以及用何种机制保证了这样定义的正确性。Paxos协议认为当vote被过半的accptor chosen后,该vote的value是最后的决议,同时允许流程继续,但是之后所有轮的vote中的value肯定都与之前的value一样,可用归纳法证明,不难。为了加快速度,我们可以设置一个learner,该learner与所有的accptor保持通信,一旦发现某个value被超过一半的accptor接受了,那么协商结束。

    具体流程:
    1. proposer选择一个提案号Mi,然后向accptor发送提议
    2. accptor接收到提议,如果发现该提议号比之前接收的提议号都大,那么回复,如果accptor之前已经批准过提案了,那么还要返回之前批准的提案号最大提案
    3. 当proposer的提议收到过半的回复后,它会将原提议的提议号作为提案号,同时将它收到的提案中的提案最大的value作为新提案的value,然后发送给accptor
    4. accptor接收到提案,如果期间回复过比该提案号更大的提议,则不批准,否则批准
    原生的Paxos协议可能会产生活锁并存在优化方案

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值