zoukankan      html  css  js  c++  java
  • 分布式的数据一致性

    一.前序

    数据的一致性和系统的性能是每个分布式系统都需要考虑和权衡的问题。一致性的级别如下:
    1.强一致性
    这种一致性级别是最符合用户直觉的,它要求系统写入什么,读出来的也会是什么,用户体验好,但实现起来往往对系统的性能影响大
    2.弱一致性
    这种一致性级别约束了系统在写入成功后,不承诺立即可以读到写入的值,也不久承诺多久之后数据能够达到一致,但会尽可能地保证到某个时间级别(比如秒级别)后,数据能够达到一致状态
    3、最终一致性
    最终一致性是弱一致性的一个特例,系统会保证在一定时间内,能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来,是因为它是弱一致性中非常推崇的一种一致性模型,也是业界在大型分布式系统的数据一致性上比较推崇的模型

    一.CAP原则(https://en.wikipedia.org/wiki/CAP_theorem)
    CAP原则:指的是在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼。

    注意:此处的Consistency(一致性)为强一致性;

    * 一个分布式系统无法同时满足以上三个需求,因此在实际运用时,我们就要抛弃其中一项.
    * CAP定理应用:
    1. 放弃P:放弃P就意味着放弃了扩展性.就是把所有数据放在一个分布式节点上.
    2. 放弃A:系统遇到故障时,在等待时间内系统无法对外提供正常服务,即不可用.
    3. 放弃C:放弃强一致性,而保持数据的最终一致性.引入“时间窗口”概念.
    * 对于分布式系统而言,网络问题是必定会出现的异常情况,因为P是一个分布式系统必须面对和解决的问题.
    * 所以往往要根据业务权衡C和A之间的选择.
    Consistency(一致性)和 Availability(可用性)的共存问题?
    一致性与可用性为什么不能同时成立?其实答案很简单,由于Partition tolerance(分区容错性)的存在,节点间的通行可能会失败。
    举个例子:
    假设微服务A异地部署,东莞区域为A1,深圳区域为A2。如果要保证A1的一致性,那么在A2执行写操作的时候,锁定A1的读操作和写操作。只有在数据同步后,才重新开放读写权限。锁定期间,A1不能读写的,对于Availability(可用性)是不成立。
    如果要保证A1的可用性,那么势必不能锁定A1,这样Consistency(一致性)肯定是不成立。

    如下公共组件:
    Zookeeper、ETCD符合CP设计;Eureka符合AP设计;

    二.BASE理论(https://en.wikipedia.org/wiki/Eventual_consistency)
    BASE理论由eBay的架构师Dan Pritchett提出,BASE理论是对CAP理论的延伸,核心思想是即使无法做到强一致性,应用应该可以采用合适的方式达到最终一致性。BASE是指基本可用(Basically Available)、软状态( Soft State)、最终一致性( Eventual Consistency)。

    ●基本可用(Basically Available)
    分布式系统出现故障的时候,允许损失部分可用性,即保证核心可用。
    ●软状态( Soft State)
    允许系统存在中间状态,并且该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本,允许不同节点间副本同步的延时,这就是软状态的体现。
    ●最终一致性( Eventual Consistency)
    分布式系统中所有的副本经过一定的时间后,最终能够达到一致的状态。

    最终一致性分为5种:
    1. 因果一致性(Causal consistency)
    指的是:如果节点 A 在更新完某个数据后通知了节点 B,那么节点 B 之后对该数据的访问和修改都是基于 A 更新后的值。于此同时,和节点 A 无因果关系的节点 C 的数据访问则没有这样的限制。

    2. 读己之所写(Read your writes)
    这种就很简单了,节点 A 更新一个数据后,它自身总是能访问到自身更新过的最新值,而不会看到旧值。其实也算一种因果一致性。

    3. 会话一致性(Session consistency)
    会话一致性将对系统数据的访问过程框定在了一个会话当中:系统能保证在同一个有效的会话中实现 “读己之所写” 的一致性,也就是说,执行更新操作之后,客户端能够在同一个会话中始终读取到该数据项的最新值。

    4. 单调读一致性(Monotonic read consistency)
    单调读一致性是指如果一个节点从系统中读取出一个数据项的某个值后,那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。

    5. 单调写一致性(Monotonic write consistency)
    指一个系统要能够保证来自同一个节点的写操作被顺序的执行。

    然而,在实际的实践中,这 5 种系统往往会结合使用,以构建一个具有最终一致性的分布式系统。实际上,不只是分布式系统使用最终一致性,关系型数据库在某个功能上,也是使用最终一致性的,比如备份,数据库的复制过程是需要时间的,这个复制过程中,业务读取到的值就是旧的。当然,最终还是达成了数据一致性。这也算是一个最终一致性的经典案例。

  • 相关阅读:
    初涉SQL Server性能问题(2/4):列出等待资源的会话
    初涉SQL Server性能问题(1/4):服务器概况
    分享
    React Native 自定义radio 单选or多选
    css之定位
    小小小小小小之新闻案例
    paddingmargin的属性与连写
    css标准流和浮动
    css 伪类
    css元素的显示方式
  • 原文地址:https://www.cnblogs.com/lovegrace/p/10366162.html
Copyright © 2011-2022 走看看