精华内容
下载资源
问答
  • ZooKeeper和CAP理论及一致性原则

    万次阅读 2020-03-19 16:44:38
    ZooKeeper和CAP理论及一致性原则 一、CAP理论概述 CAP理论告诉我们,一个分布式系统不可能同时满足以下三种 一致性(C:Consistency) 可用性(A:Available) 分区容错性(P:Partition Tolerance) 这三个...

    ZooKeeper和CAP理论及一致性原则

    一、CAP理论概述

    CAP理论告诉我们,一个分布式系统不可能同时满足以下三种

    • 一致性(C:Consistency)
    • 可用性(A:Available)
    • 分区容错性(P:Partition Tolerance)

    这三个基本需求,最多只能同时满足其中的两项,因为P是必须的,因此往往选择就在CP或者AP中

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NS5yD5JX-1584607472252)(http://www.ymq.io/images/2018/ZooKeeper/1.png)]

    一致性(C:Consistency)

    在分布式环境中,一致性是指数据在多个副本之间是否能够保持数据一致的特性。在一致性的需求下,当一个系统在数据一致的状态下执行更新操作后,应该保证系统的数据仍然处于一致的状态。例如一个将数据副本分布在不同分布式节点上的系统来说,如果对第一个节点的数据进行了更新操作并且更新成功后,其他节点上的数据也应该得到更新,并且所有用户都可以读取到其最新的值,那么这样的系统就被认为具有强一致性(或严格的一致性,最终一致性)。

    可用性(A:Available)

    可用性是指系统提供的服务必须一直处于可用的状态,对于用户的每一个操作请求总是能够在有限的时间内返回结果。“有效的时间内”是指,对于用户的一个操作请求,系统必须能够在指定的时间(即响应时间)内返回对应的处理结果,如果超过了这个时间范围,那么系统就被认为是不可用的

    “返回结果”是可用性的另一个非常重要的指标,它要求系统在完成对用户请求的处理后,返回一个正常的响应结果。正常的响应结果通常能够明确的反映出对请求的处理结果,即成功或失败,而不是一个让用户感到困惑的返回结果。

    分区容错性(P:Partition Tolerance)

    分区容错性约束了一个分布式系统需要具有如下特性:分布式系统在遇到任何网络分区故障的时候,仍然需要能够保证对外提供满足一致性和可用性的服务,除非是整个网络环境都发生了故障

    网络分区是指在分布式系统中,不同的节点分布在不同的子网络(机房或异地网络等)中,由于一些特殊的原因导致这些子网络之间出现网络不连通的状况,但各个子网络的内部网络是正常的,从而导致整个系统的网络环境被切分成了若干个孤立的区域。需要注意的是,组成一个分布式系统的每个节点的加入与退出都可以看作是一个特殊的网络分区。

    由于一个分布式系统无法同时满足上面的三个需求,而只能满足其中的两项,因此在进行对CAP定理的应用的时候,需要根据业务的要求抛弃其中的一项,下表所示是抛弃CAP定理中任意一项特性的场景说明。

    因此,将精力浪费在思考如何设计能满足三者的完美系统上是愚钝的,应该根据应用场景进行适当取舍。

    二、一致性的分类

    一致性是指从系统外部读取系统内部的数据时,在一定约束条件下相同,即数据变动在系统内部各节点应该是同步的。根据一致性的强弱程度不同,可以将一致性的分类为如下几种:

    强一致性:(strong consistency)。任何时刻,任何用户都能读取到最近一次成功更新的数据。

    单调一致性:(monotonic consistency)。任何时刻,任何用户一旦读到某个数据在某次更新后的值,那么就不会再读到比这个值更旧的值。也就是说,可获取的数据顺序必是单调递增的。

    会话一致性:(session consistency)。任何用户在某次会话中,一旦读到某个数据在某次更新后的值,那么在本次会话中就不会再读到比这值更旧的值,会话一致性是在单调一致性的基础上进一步放松约束,只保证单个用户单个会话内的单调性,在不同用户或同一用户不同会话间则没有保障。

    最终一致性:(eventual consistency)。用户只能读到某次更新后的值,但系统保证数据将最终达到完全一致的状态,只是所需时间不能保障。

    弱一致性:(weak consistency)。用户无法在确定时间内读到最新更新的值。

    三、ZooKeeper提供的一致性服务

    ZooKeeper从以下几点保证了数据的一致性

    顺序一致性来自任意特定客户端的更新都会按其发送顺序被提交保持一致。也就是说,如果一个客户端将Znode z的值更新为a,在之后的操作中,它又将z的值更新为b,则没有客户端能够在看到z的值是b之后再看到值a(如果没有其他对z的更新)。

    原子性每个更新要么成功,要么失败。这意味着如果一个更新失败,则不会有客户端会看到这个更新的结果。

    单一系统映像一个客户端无论连接到哪一台服务器,它看到的都是同样的系统视图。这意味着,如果一个客户端在同一个会话中连接到一台新的服务器,它所看到的系统状态不会比 在之前服务器上所看到的更老。当一台服务器出现故障,导致它的一个客户端需要尝试连接集合体中其他的服务器时,所有滞后于故障服务器的服务器都不会接受该 连接请求,除非这些服务器赶上故障服务器。

    持久性一个更新一旦成功,其结果就会持久存在并且不会被撤销。这表明更新不会受到服务器故障的影响。

    实时性:在特定的一段时间内,客户端看到的系统需要被保证是实时的(在十几秒的时间里)。在此时间段内,任何系统的改变将被客户端看到,或者被客户端侦测到。

    四、用CAP理论来分析ZooKeeper

    CAP理论告诉我们,一个分布式系统不可能同时满足以下三种

    • 一致性(C:Consistency)
    • 可用性(A:Available)
    • 分区容错性(P:Partition Tolerance)

    这三个基本需求,最多只能同时满足其中的两项,因为P是必须的,因此往往选择就在CP或者AP中

    在此ZooKeeper保证的是CP

    分析:可用性(A:Available)

    不能保证每次服务请求的可用性。任何时刻对ZooKeeper的访问请求能得到一致的数据结果,同时系统对网络分割具备容错性;但是它不能保证每次服务请求的可用性(注:也就是在极端环境下,ZooKeeper可能会丢弃一些请求,消费者程序需要重新请求才能获得结果)。所以说,ZooKeeper不能保证服务可用性。

    进行leader选举时集群都是不可用。在使用ZooKeeper获取服务列表时,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30 ~ 120s, 且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪,虽然服务能够最终恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的。所以说,ZooKeeper不能保证服务可用性。

    参考:https://www.cnblogs.com/xrq730/p/4944768.html

    参考:https://blog.csdn.net/xiangxizhishi/article/details/78469027

    Contact

    • 作者:鹏磊
    • 出处:http://www.ymq.io/2018/05/18/zookeeper
    • 版权归作者所有,转载请注明出处
    • Wechat:关注公众号,搜云库,专注于开发技术的研究与知识分享

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4K7uXhVU-1584607472253)(http://www.ymq.io/images/souyunku.png “搜云库”)]

    展开全文
  • 我们都了解分布式CAP原则,其中的C就是一致性。有关一致性,实践中又可以分为:强一致性、单调一致性、最终一致性。 CAP中的C默认就是指:在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点...

    我们都了解分布式CAP原则,其中的C就是一致性。有关一致性,实践中又可以分为:强一致性、单调一致性、最终一致性。

    CAP中的C默认就是指:在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)。

    1、强一致性(Strong Consistency)

    在任何时刻所有的用户或者进程查询到的都是最近一次成功更新的数据。强一致性是程度最高一致性要求,也是最难实现的。关系型数据库更新操作就是这个案例。

    2, 单调一致性(Monotonic Consistency)

    单调一致性会从读写两个角度有各自的定义。

    单调读一致性

    如果进程已经看到过数据对象的某个值,那么任何后续访问都不会返回该值之前的值。(“If a process has seen a particular value for the object any subsequent accesses will never return any previous values”)

    单调写一致性

    系统保证来自同一个进程的写操作顺序执行。(Write operations that must precede other writes are executed before those other writes.)

    3、最终一致性(Eventual Consistency)

    和强一致性相对,在某一时刻用户或者进程查询到的数据可能都不同,但是最终成功更新的数据都会被所有用户或者进程查询到。当前主流的nosql数据库都是采用这种一致性策略。

    额外内容:

    zookeeper的一致性

    我们以官方文档为准:(2019-11-17摘录的)

    ZooKeeper is a high performance, scalable service. Both reads and write operations are designed to be fast, though reads are faster than writes. The reason for this is that in the case of reads, ZooKeeper can serve older data, which in turn is due to ZooKeeper's consistency guarantees:
    
    Sequential Consistency : Updates from a client will be applied in the order that they were sent.
    
    Atomicity : Updates either succeed or fail -- there are no partial results.
    
    Single System Image : A client will see the same view of the service regardless of the server that it connects to.
    
    Reliability : Once an update has been applied, it will persist from that time forward until a client overwrites the update. This guarantee has two corollaries:
    
    If a client gets a successful return code, the update will have been applied. On some failures (communication errors, timeouts, etc) the client will not know if the update has applied or not. We take steps to minimize the failures, but the guarantee is only present with successful return codes. (This is called the monotonicity condition in Paxos.)
    Any updates that are seen by the client, through a read request or successful update, will never be rolled back when recovering from server failures.
    Timeliness : The clients view of the system is guaranteed to be up-to-date within a certain time bound (on the order of tens of seconds). Either system changes will be seen by a client within this bound, or the client will detect a service outage.
    
    Using these consistency guarantees it is easy to build higher level functions such as leader election, barriers, queues, and read/write revocable locks solely at the ZooKeeper client (no additions needed to ZooKeeper). See Recipes and Solutions for more details.
    

    简单总结:zk提供的是单调一致性,最终一致性,不是强一致性。 zk的文档清楚强调了ZooKeeper does not guarantee that at every instance in time, two different clients will have identical views of ZooKeeper data.

    原文链接:https://zookeeper.apache.org/doc/current/zookeeperProgrammers.html#ch_zkGuarantees

    mongoDB的一致性

    原文链接:https://docs.mongodb.com/manual/core/read-isolation-consistency-recency/

    mongodb提供单调写一致性。
    Monotonic Writes
    MongoDB provides monotonic write guarantees, by default, for standalone mongod instances and replica set.

    For monotonic writes and sharded clusters, see Causal Consistency.
    Write operations that must precede other writes are executed before those other writes.

    后记:我们实际开发业务分布式系统,必须在强一致性和最终一致性中间进行tradeoff。 根据业务要求,进行取舍。强一致性会增加延时(所有实例和副本进行数据同步)和降低可用性(只要有节点无法完成同步数据, 可用性就有问题)。
    现在很多软件直接提供可配置的一致性,用户可以根据业务要求进行配置。 例如微软的cosmos-db。

    参考:
    1, https://hellokangning.github.io/en/post/consistency-in-distributed-system/
    2,https://docs.microsoft.com/en-us/azure/cosmos-db/consistency-levels
    3, https://docs.mongodb.com/manual/core/read-isolation-consistency-recency/

    展开全文
  • 1.缓存一致性协议(MESI): 由于每个处理器都含有私有的高速缓存,在对缓存中数据进行更新后,其他处理器中所含有的该共享变量的缓存如果被处理器进行读操作,就会出现错误。有些计算机采用LO...

    Java内存模型(JMM)是一个概念模型,底层是计算机的寄存器、缓存内存、主内存和CPU等。
    多处理器环境下,共享数据的交互硬件设备之间的关系:
    这里写图片描述
    JMM:
    这里写图片描述
    从以上两张图中,谈一谈以下几个概念:

    1.缓存一致性协议(MESI):

    由于每个处理器都含有私有的高速缓存,在对缓存中数据进行更新后,其他处理器中所含有的该共享变量的缓存如果被处理器进行读操作,就会出现错误。有些计算机采用LOCK#信号对总线进行锁定,当一个处理器在总线上输出此信号时,其它处理器的请求将被阻塞,那么该处理器就能独自共享内存。然而总线锁定的开销太大,在之后的计算机中一般都采用“缓存锁定”的方式实现。
    MESI是代表了缓存数据的四种状态的首字母,分别是Modified、Exclusive、Shared、Invalid)
    - M(Modified):被修改的。处于这一状态的数据,只在本CPU中有缓存数据,而其他CPU中没有。同时其状态相对于内存中的值来说,是已经被修改的,且没有更新到内存中。
    - E(Exclusive):独占的。处于这一状态的数据,只有在本CPU中有缓存,且其数据没有修改,即与内存中一致。
    - S(Shared):共享的。处于这一状态的数据在多个CPU中都有缓存,且与内存一致。
    - I(Invalid):要么已经不在缓存中,要么它的内容已经过时。为了达到缓存的目的,这种状态的段将会被忽略。一旦缓存段被标记为失效,那效果就等同于它从来没被加载到缓存中。
    在缓存行中有这四种状态的基础上,通过“嗅探”技术完成以下功能:【嗅探技术能够嗅探其他处理器访问主内存和它们的内部缓存】
    - 一个处于M状态的缓存行,必须时刻监听所有试图读取该缓存行对应的主存地址的操作,如果监听到,则必须在此操作执行前把其缓存行中的数据写回CPU。
    - 一个处于S状态的缓存行,必须时刻监听使该缓存行无效或者独享该缓存行的请求,如果监听到,则必须把其缓存行状态设置为I。
    - 一个处于E状态的缓存行,必须时刻监听其他试图读取该缓存行对应的主存地址的操作,如果监听到,则必须把其缓存行状态设置为S。
    - 只有E和M可以进行写操作而且不需要额外操作,如果想对S状态的缓存字段进行写操作,那必须先发送一个RFO(Request-For-Ownership)广播,该广播可以让其他CPU的缓存中的相同数据的字段实效,即变成I状态。
    通过以上机制可以使得处理器在每次读写操作都是原子的,并且每次读到的数据都是最新的。

    2.Java并发编程中要保证的几个原则

    1)原子性:

    是指CPU在执行操作时,要么执行要么不执行,对于单个的读/写操作,在多线程环境下保证是原子操作,但复合操作比如i++,相当于是以下三个操作:

    int temp = get();  // 读
    temp += 1;         // ADD
    set(temp);         // 写

    Java主要提供了锁机制以及CAS操作实现原子性,对于单个读/写操作是通过LOCK#信号或“缓存锁定”实现的。
    除此之外,long和double类型的变量读/写是非原子性的,每次都只读/写32位数据,所以一个单个的读/写操作就变成了两个读/写操作,有可能在只读/写了其中32位操作后CPU就被其他线程抢占到。

    2)可见性:

    由于每个线程都有一个私有的工作空间,并且保存一个主存中共享变量的副本,在线程对私有的工作空间中的数据进行写操作,别的线程并没有读到最新的值,就会出现问题。Java提供了volatile关键字保证了内存的可见性,底层通过LOCK#或“缓存锁定”实现。

    instance = new Singleton();     // instance 是一个volatile变量

    以上代码在进行反汇编后得到的汇编代码如下:

    0x01a3de1d: movb $0×0,0×1104800(%esi);
    0x01a3de24: lock addl $0×0,(%esp);

    如果是一个volatile关键字修饰的变量,则会有第二行的汇编代码,这是一条含有lock前缀的代码。带有lock前缀的代码则会通过LOCK#或通过“缓存锁定”实现线程间的可见性。

    3)有序性

    编译器和处理器会通过多种方式比如重排序对代码进行优化,然而在重排序后可能会导致运行结果与预想的不同。
    a.重排序的方式:
    计算机在执行程序时,为了提高性能,编译器和处理器的常常会对指令做重排,一般分以下3种:
    这里写图片描述
    - 编译器优化的重排序:
    编译器在不改变单线程程序语义的前提下,可以重新安排语句的执行顺序。【as-if-serial原则保证,as-if-serial语义:不管怎么重排序(编译器和处理器为了提高并行度),(单线程)程序的执行结果不能被改变。】
    - 指令级并行的重排序:
    现代处理器采用了指令级并行技术来将多条指令重叠执行。如果不存在数据依赖性(即后一个执行的语句无需依赖前面执行的语句的结果),处理器可以改变语句对应的机器指令的执行顺序。
    - 内存系统重排序:
    由于处理器使用缓存和读写缓存冲区,这使得加载(load)和存储(store)操作看上去可能是在乱序执行,因为三级缓存的存在,导致内存与缓存的数据同步存在时间差。

    b.内存屏障(Memory Barrier,又称内存栅栏):
    内存屏障是一个CPU指令,Java编译器在生成指令序列的适当位置会插入内存屏障指令来禁止特定类型的处理器重排序。它的作用有两个:
    一是保证特定操作的执行顺序;
    二是保证某些变量的内存可见性。
    如果在指令间插入一条Memory Barrier则会告诉编译器和CPU,不管什么指令都不能和这条Memory Barrier指令重排序,也就是说通过插入内存屏障禁止在内存屏障前后的指令执行重排序优化。Memory Barrier的另外一个作用是强制刷出各种CPU的缓存数据,因此任何CPU上的线程都能读取到这些数据的最新版本。
    JMM把内存屏障指令分为下列四类:
    这里写图片描述

    3.happens-before原则:

    使用happens-before的概念来指定两个操作之间的执行顺序。由于这两个操作可以在一个线程之内,也可以是在不同线程之间。因此,JMM可以通过happens-before关系向程序员提供跨线程的内存可见性保证。
    【如果A happens-before B,JMM并不要求A一定要在B之前执行。JMM仅仅要求A操作(执行的结果)对B操作可见,且A操作按顺序排在B操作之前。】
    1)程序顺序规则:一个线程中的每个操作,happens-before于该线程中的任意后续操作。【在A happens-before B中,如果A和B重排序后不会导致结果变化,那么这种重排序是被允许的】
    2)监视器锁规则:对一个锁的解锁,happens-before于随后对这个锁的加锁。
    3)volatile变量规则:对一个volatile域的写,happens-before于任意后续对这个volatile域的读。
    4)传递性:如果A happens-before B,且B happens-before C,那么A happens-before C。
    5)start()规则:如果线程A执行操作ThreadB.start()(启动线程B),那么A线程的ThreadB.start()操作happens-before于线程B中的任意操作。
    6)join()规则:如果线程A执行操作ThreadB.join()并成功返回,那么线程B中的任意操作
    happens-before于线程A从ThreadB.join()操作成功返回。

    本文参考资料:
    书籍:
    《Java并发编程的艺术》
    博客:
    https://blog.csdn.net/javazejian/article/details/72772461
    https://blog.csdn.net/happy_horse/article/details/51657957
    本文图片来自博客:
    https://www.cnblogs.com/nexiyi/p/java_memory_model_and_thread.html

    展开全文
  • CAP, BASE, 最终一致性和五分钟原则

    万次阅读 2017-02-16 16:30:34
    CAP,BASE和最终一致性是NoSQL数据库存在的三大基石。而五分钟法则是内存数据存储的理论依据。这个是一切的源头。 CAP     C: Consistency 一致性A: Availability 可用性(指的是快速获取数据)...
    CAP,BASE和最终一致性是NoSQL数据库存在的三大基石。而五分钟法则是内存数据存储的理论依据。这个是一切的源头。

    CAP

     


     

    • C: Consistency 一致性
    • A: Availability 可用性(指的是快速获取数据)
    • P: Tolerance of network Partition 分区容忍性(分布式)

     

    10年前,Eric Brewer教授指出了著名的CAP理论,后来Seth Gilbert 和 Nancy lynch两人证明了CAP理论的正确性。CAP理论告诉我们,一个分布式系统不可能满足一致性,可用性和分区容错性这三个需求,最多只能同时满足两个。
    而由于当前的网络硬件肯定会出现延迟丢包等问题,所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡,没有NoSQL系统能同时保证这三点。如果你关注的是一致性,那么您就需要处理因为系统不可用而导致的操作失败的情况,而如果您关注的是可用性,那么您应该知道系统的read操作可能不能精确的读取到write操作写入的最新值。因此系统的关注点不同,相应的采用的策略也是不一样的,只有真正的理解了系统的需求,才有可能利用好CAP理论。

    作为架构师,一般有两个方向来利用CAP理论
    key-value存储,如Amaze Dynamo等,可根据CAP三原则灵活选择不同倾向的数据库产品。
    领域模型 + 分布式缓存 + 存储 (Qi4j和NoSql运动),可根据CAP三原则结合自己项目定制灵活的分布式方案,难度高。
    我准备提供第三种方案:实现可以配置CAP的数据库,动态调配CAP。

    • CA:传统关系数据库
    • AP:key-value数据库
    而对大型网站,可用性与分区容忍性优先级要高于数据一致性,一般会尽量朝着 A、P 的方向设计,然后通过其它手段保证对于一致性的商务需求。架构设计师不要精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍。
    不同数据对于一致性的要求是不同的。举例来讲,用户评论对不一致是不敏感的,可以容忍相对较长时间的不一致,这种不一致并不会影响交易和用户体验。而产品价格数据则是非常敏感的,通常不能容忍超过10秒的价格不一致。 

    CAP理论的证明: Brewer's CAP Theorem

    最终一致性

    一言以蔽之:过程松,结果紧,最终结果必须保持一致性

     

    为了更好的描述客户端一致性,我们通过以下的场景来进行,这个场景中包括三个组成部分:
    • 存储系统
    存储系统可以理解为一个黑盒子,它为我们提供了可用性和持久性的保证。
    • Process A
    ProcessA主要实现从存储系统write和read操作
    • Process B 和ProcessC 
    ProcessB和C是独立于A,并且B和C也相互独立的,它们同时也实现对存储系统的write和read操作。


    下面以上面的场景来描述下不同程度的一致性:

    • 强一致性
    强一致性(即时一致性) 假如A先写入了一个值到存储系统,存储系统保证后续A,B,C的读取操作都将返回最新值
    • 弱一致性
    假如A先写入了一个值到存储系统,存储系统不能保证后续A,B,C的读取操作能读取到最新值。此种情况下有一个“不一致性窗口”的概念,它特指从A写入值,到后续操作A,B,C读取到最新值这一段时间。
    • 最终一致性
    最终一致性是弱一致性的一种特例。假如A首先write了一个值到存储系统,存储系统保证如果在A,B,C后续读取之前没有其它写操作更新同样的值的话,最终所有的读取操作都会读取到最A写入的最新值。此种情况下,如果没有失败发生的话,“不一致性窗口”的大小依赖于以下的几个因素:交互延迟,系统的负载,以及复制技术中replica的个数(这个可以理解为master/salve模式中,salve的个数),最终一致性方面最出名的系统可以说是DNS系统,当更新一个域名的IP以后,根据配置策略以及缓存控制策略的不同,最终所有的客户都会看到最新的值。

    变体

    • Causal consistency(因果一致性)
    如果Process A通知Process B它已经更新了数据,那么Process B的后续读取操作则读取A写入的最新值,而与A没有因果关系的C则可以最终一致性。
    • Read-your-writes consistency (读己所写一致性)
    如果Process A写入了最新的值,那么Process A的后续操作都会读取到最新值。但是其它用户可能要过一会才可以看到。
    • Session consistency (会话一致性)
    此种一致性要求客户端和存储系统交互的整个会话阶段保证Read-your-writes consistency.Hibernate的session提供的一致性保证就属于此种一致性。
    • Monotonic read consistency (单调读一致性
    此种一致性要求如果Process A已经读取了对象的某个值,那么后续操作将不会读取到更早的值。
    • Monotonic write consistency (单调写一致性
    此种一致性保证系统会序列化执行一个Process中的所有写操作。

    BASE

    说起来很有趣,BASE的英文意义是碱,而ACID是酸。真的是水火不容啊。

    • Basically Available--基本可用
    • Soft-state --软状态/柔性 事务
    "Soft state" 可以理解为"无连接"的, 而 "Hard state" 是"面向连接"的
    • Eventual Consistency --最终一致性
    最终一致性, 也是是 ACID 的最终目的。

    BASE模型反ACID模型,完全不同ACID模型,牺牲高一致性,获得可用性或可靠性: Basically Available基本可用。支持分区失败(e.g. sharding碎片划分数据库) Soft state软状态 状态可以有一段时间不同步,异步。 Eventually consistent最终一致,最终数据是一致的就可以了,而不是时时一致。 

    BASE思想的主要实现有 
    1.按功能划分数据库 
    2.sharding碎片  

    BASE思想主要强调基本的可用性,如果你需要高可用性,也就是纯粹的高性能,那么就要以一致性或容错性为牺牲,BASE思想的方案在性能上还是有潜力可挖的。 

    其他


    I/O的五分钟法则

    在 1987 年, Jim Gray 与 Gianfranco Putzolu 发表了这个"五分钟法则"的观点,简而言之,如果一条记录频繁被访问,就应该放到内存里,否则的话就应该待在硬盘上按需要再访问。这个临界点就是五分钟。 看上去像一条经验性的法则,实际上五分钟的评估标准是根据投入成本判断的,根据当时的硬件发展水准,在内存中保持 1KB 的数据成本相当于硬盘中存取 400 秒的开销(接近五分钟)。这个法则在 1997 年左右的时候进行过一次回顾,证实了五分钟法则依然有效(硬盘、内存实际上没有质的飞跃),而这次的回顾则是针对 SSD 这个"新的旧硬件"可能带来的影响。 
     






    不要删除数据


    Oren Eini(又名Ayende Rahien)建议开发者尽量避免数据库的软删除操作,读者可能因此认为硬删除是合理的选择。作为对Ayende文章的回应,Udi Dahan强烈建议完全避免数据删除。

    所谓软删除主张在表中增加一个IsDeleted列以保持数据完整。如果某一行设置了IsDeleted标志列,那么这一行就被认为是已删除的。Ayende觉得这种方法“简单、容易理解、容易实现、容易沟通”,但“往往是错的”。问题在于:

    删除一行或一个实体几乎总不是简单的事件。它不仅影响模型中的数据,还会影响模型的外观。所以我们才要有外键去确保不会出现“订单行”没有对应的父“订单”的情况。而这个例子只能算是最简单的情况。……

    当采用软删除的时候,不管我们是否情愿,都很容易出现数据受损,比如谁都不在意的一个小调整,就可能使“客户”的“最新订单”指向一条已经软删除的订单。

    如果开发者接到的要求就是从数据库中删除数据,要是不建议用软删除,那就只能硬删除了。为了保证数据一致性,开发者除了删除直接有关的数据行,还应该级联地删除相关数据。可Udi Dahan提醒读者注意,真实的世界并不是级联的:

    假设市场部决定从商品目录中删除一样商品,那是不是说所有包含了该商品的旧订单都要一并消失?再级联下去,这些订单对应的所有发票是不是也该删除?这么一步步删下去,我们公司的损益报表是不是应该重做了?

    没天理了。

    问题似乎出在对“删除”这词的解读上。Dahan给出了这样的例子:

    我说的“删除”其实是指这产品“停售”了。我们以后不再卖这种产品,清掉库存以后不再进货。以后顾客搜索商品或者翻阅目录的时候不会再看见这种商品,但管仓库的人暂时还得继续管理它们。“删除”是个贪方便的说法。

    他接着举了一些站在用户角度的正确解读:


    订单不是被删除的,是被“取消”的。订单取消得太晚,还会产生花费。

    员工不是被删除的,是被“解雇”的(也可能是退休了)。还有相应的补偿金要处理。

    职位不是被删除的,是被“填补”的(或者招聘申请被撤回)。

    在上面这些例子中,我们的着眼点应该放在用户希望完成的任务上,而非发生在某个
    实体身上的技术动作。几乎在所有的情况下,需要考虑的实体总不止一个。

    为了代替IsDeleted标志,Dahan建议用一个代表相关数据状态的字段:有效、停用、取消、弃置等等。用户可以借助这样一个状态字段回顾过去的数据,作为决策的依据。

    删除数据除了破坏数据一致性,还有其它负面的后果。Dahan建议把所有数据都留在数据库里:“别删除。就是别
    删除。”

    RAM是硬盘,硬盘是磁带


    Jim Gray在过去40年中对技术发展有过巨大的贡献,“内存是新的硬盘,硬盘是新的磁带”是他的名言。“实时”Web应用不断涌现,达到海量规模的系统越来越多,这种后浪推前浪的发展模式对软硬件又有何影响? 

    Tim Bray早在网格计算成为热门话题之前,就 讨论过以RAM和网络为中心的硬件结构的优势,可以用这种硬件建立比磁盘集群速度更快的RAM集群。
    对于数据的随机访问,内存的速度比硬盘高几个数量级(即使是最高端的磁盘存储系统也只是勉强达到1,000次寻道/秒)。其次, 随着数据中心的网络速度提高,访问内存的成本更进一步降低。通过网络访问另一台机器的内存比访问磁盘成本更低。就在我写下这段话的时候,Sun的 Infiniband产品线中有一款具备9个全互联非阻塞端口 交换机,每个端口的速度可以达到30Gbit/sec!Voltaire产品的端口甚至更多;简直不敢想象。(如果你想了解这类超高性能网络的最新进展,请关注Andreas Bechtolsheim在Standford开设的课程。)
    各种操作的时间,以2001年夏季,典型配置的 1GHz 个人计算机为标准:
    执行单一指令 1 纳秒 从L1 高速缓存取一个字 2 纳秒 从内存取一个字 10 纳秒 从磁盘取连续存放的一个字 200 纳秒 磁盘寻址并取字 8 毫秒 以太网 2GB/s



    Tim还指出Jim Gray的 
    名言中后半句所阐述的真理:“对于随机访问,硬盘慢得不可忍受;但如果你把硬盘当成磁带来用,它吞吐连续数据的速率令人震惊;它天生适合用来给以RAM为主的应用做日志(logging and journaling)。”  

    时间闪到几年之后的今天,我们发现硬件的发展趋势在RAM和网络领域势头不减,而在硬盘领域则止步不前。Bill McColl提到用于并行计算的 海量内存系统已经出现
    内存是新的硬盘!硬盘速度提高缓慢,内存芯片容量指数上升,in-memory软件架构有望给各类数据密集的应用带来数量级的性能提升。小型机架服务器(1U、2U)很快就会具备T字节、甚至更大量的内存,这将会改变服务器架构中内存和硬盘之间的平衡。硬盘将成为新的磁带,像磁带一样作为顺序存储介质使用(硬盘的顺序访问相当快速),而不再是随机存储介质(非常慢)。这里面有着大量的机会,新产品的性能有望提高10倍、100倍。
    Dare Obsanjo指出 如果不把这句真言当回事,会带来什么样的恶劣后果—— 也就是Twitter正面临的麻烦。论及Twitter的内容管理,Obsanjo说,“如果一个设计只是简单地反映了问题描述,你去实现它就会落入磁盘 I/O的地狱。不管你用Ruby on Rails、Cobol on Cogs、C++还是手写汇编都一样,读写负载照样会害死你。”换言之,应该把随机操作推给RAM,只给硬盘留下顺序操作。  

    Tom White是 Hadoop Core项目的提交者,也是Hadoop项目管理委员会的成员。他对Gray的真言中“硬盘是新的磁带”部分作了更深入地探讨。White在讨论MapReduce编程模型的时候指出,为何对于Hadloop这类工具来说, 硬盘仍然是可行的应用程序数据存储介质:
    本质上,在MapReduce的工作方式中,数据流式地读出和写入硬盘,MapReduce是以硬盘的传输速率不断地对这些数据进行排序和合并。 与之相比,访问关系数据库中的数据,其速率则是硬盘的寻道速率(寻道指移动磁头到盘面上的指定位置读取或写入数据的过程)。为什么要强调这一点?请看看寻道时间和磁盘传输率的发展曲线。寻道时间每年大约提高5%,而数据传输率每年大约提高20%。寻道时间的进步比数据传输率慢——因此采用由数据传输率决定性能的模型是有利的。MapReduce正是如此。
    虽然固态硬盘(SSD)能否改变寻道时间/传输率的对比还有待观察, White文章的跟贴中,很多人都认为 SSD会成为RAM/硬盘之争中的平衡因素。  

    Nati Shalom对 内存和硬盘在数据库部署和使用中的角色作了一番有理有据的评述。 Shalom着重指出用数据库集群和分区来解决性能和可伸缩性的局限。他说,“数据库复制和数据库分区都存在相同的基本问题,它们都依赖于文件系统/硬盘 的性能,建立数据库集群也非常复杂”。他提议的方案是转向In-Memory Data Grid(IMDG),用Hibernate二级缓存或者GigaSpaces Spring DAO之类的技术作支撑,将持久化作为服务(Persistence as a Service)提供给应用程序。Shalom解释说,IMDG
    提供在内存中的基于对象的数据库能力,支持核心的数据库功能,诸如高级索引和查询、事务语义和锁。IMDG还从应用程序的代码中抽象出了数据的拓扑。通过这样的方式,数据库不会完全消失,只是挪到了“正确的”位置。
    IMDG相比直接RDBMS访问的优势列举如下:
    • 位于内存中,速度和并发能力都比文件系统优越得多
    • 数据可通过引用访问
    • 直接对内存中的对象执行数据操作
    • 减少数据的争用
    • 并行的聚合查询
    • 进程内(In-process)的局部缓存
    • 免除了对象-关系映射(ORM)
    你是否需要改变对应用和硬件的思维方式,最终取决于你要用它们完成的工作。但似乎公论认为,开发者解决性能和可伸缩性的思路已经到了该变一变的时候。

    Amdahl定律和Gustafson定律

    这里,我们都以S(n)表示n核系统对具体程序的加速比,K表示串行部分计算时间比例。 

    Amdahl 定律的加速比:S(n) = 使用1个处理器的串行计算时间 / 使用n个处理器的并行计算时间S(n) = 1/(K+(1-K)/n) = n/(1+(n-1)K)Gustafson定律的加速比:S(n) = 使用n个处理器的并行计算量 / 使用1个处理器的串行计算量S(n) = K+(1-K)n 
    有点冷是不是? 

    通俗的讲,Amdahl 定律将工作量看作1,有n核也只能分担1-K的工作量;而Gustafson定律则将单核工作量看作1,有n核,就可以增加n(1-K)的工作量。 

    这里没有考虑引进分布式带来的开销,比如网络和加锁。成本还是要仔细核算的,不是越分布越好。 

    控制算法的复杂性在常数范围之内。 
    展开全文
  • 前言 分布式数据库的数据一致性管理是其最重要的内核技术之一,也是保证分布式数据库满足数据库最基本的ACID特性中的 “一致性”...1.1 数据一致性什么 大部份使用传统关系型数据库的DBA在看到“数据一致性”时,...
  • 1. 当我们在说一致性,我们在说什么? 在分布式环境下,一致性指的是多个数据副本是否能保持一致的特性。 在一致性的条件下,系统在执行数据更新操作之后能够从一致性状态转移到另一个一致性状态。 对系统的一个...
  • 分布式系统的一致性问题(汇总)

    万次阅读 2019-09-02 15:32:19
    保证分布式系统数据一致性的6种方案 问题的起源 在电商等业务中,系统一般由多个独立的服务组成,如何解决分布式调用时候数据的一致性? 具体业务场景如下,比如一个业务操作,如果同时调用服务 A、B、C,需要...
  • 一致性hash算法

    千次阅读 2019-04-27 22:47:14
    一致性hash算法Hash算法的作用Hash算法的冲突一致性hash算法一致性hash算法的原理容错性虚拟节点 Hash 算法也叫做散列算法,他可以让任意长度的数据M映射成为长度固定的值H。 Hash算法的作用 Hash算法的第一个作用...
  • ZooKeeper能保证任何时刻读到的数据绝对一致吗? Zookeeper的特点就是,分布式,高可用,...也就是说可用性和一致性是Zookeeper的关键特性,作为一个消息的中间商,做了一个可靠的信息传递和存储的角色。 但是了解下ZooKeep
  • 事务一致性简述

    千次阅读 2015-11-15 14:35:40
    事务一致性简述
  • 类型一致性和闭合行为   1 类class和类型type  从抽象的角度来理解,最好将类视为类型的实现。也就是说类型包括了类的目标以及类的状态空间和行为。实际上,一个类型可以有多个类,每个类都包括自己独立的内部...
  • Raft 一致性算法论文

    万次阅读 2019-05-17 09:52:13
    本篇博客为著名的 RAFT 一致性算法论文的中文翻译,论文名为《In search of an Understandable Consensus Algorithm (Extended Version)》(寻找一种易于理解的一致性算法)。 Raft 是一种用来管理日志复制的一致性...
  • 一致性Hash算法

    千次阅读 2016-05-03 22:22:06
    一致性哈希算法在1997年由麻省理工学院提出的一种分布式哈希(DHT)实现算法,设计目标是为了解决因特网中的热点(Hot spot)问题,初衷和CARP十分类似。一致性哈希修正了CARP使用的简 单哈希算法带来的问题,使得...
  • 微服务架构下的事务一致性保证

    千次阅读 2019-04-04 14:07:56
    微服务架构中应满足数据最终一致性原则 微服务架构实现最终一致性的三种模式 对账是最后的终极防线。 我们先来看一下第一部分,传统使用本地事务和分布式事务保证一致性 传统单机应用一般都会使用一个...
  • 【算法】Hash一致性算法详解

    千次阅读 2015-10-21 15:25:16
    一致性哈希算法在1997年由麻省理工学院提出的一种分布式哈希(DHT)实现算法,设计目标是为了解决因特网中的热点(Hot spot)问题,初衷和CARP十分类似。一致性哈希修正了CARP使用的简 单哈希算法带来的问题,使得...
  • 最终一致性

    万次阅读 2012-05-14 22:11:45
    在全球范围构建可靠的分布式系统,需要在一致性和可用性之间进行权衡。   最终一致性 Eventually Consistent   作者: Werner Vogels Werner Vogels is vice president and chieftechnology officer at ...
  • 上一篇:单业务的一致性(CAP中的C【Consistency】)-02CAP介绍 1.使用Seata做强一致性分布式事务 还是我们开头提出的问题:如何保证1.1、1.2、1.3要么同时成功,要么同时失败,本小节,使用alibaba seata作为...
  • 这个问题的有趣之处,不在于问题本身(“原子性、一致性的实现机制是什么”),而在于回答者的分歧反映出来的另外一个问题:原子性和一致性之间的关系是什么? 我特别关注了@我练功发自真心 的答案,他正确地指出...
  • 一致性算法分析

    万次阅读 2018-01-18 14:25:47
    目的 :一致性算法的出现是为了解决一致性问题,一致性问题是指对于一组服务器(集群),给定一组操作,需要使用一种协议使得它们的结果最终达成一致,看起来好像是一台服务器一样。 作用 :一致性算法在构建可信赖...
  • 再读分布式一致性算法Raft论文

    千次阅读 2017-07-16 10:21:11
    Raft是一个管理日志副本一致性的算法。相比Paxos结果一样,并且一样高效,但是理解起来更加的容易。Raft将一致性的主要元素分离开来,比如leader选举,log 复制,安全等。同时,也提供了一个新的机制实现cluster ...
  • 分布式一致性协议Raft & Paxos 简单 v.s. 完美
  • 一致性代码和非一致性代码有什么区别?等等这些问题,如果仅仅停留在知其然的级别,很容易会困惑,本文主要说明以上问题的答案和蕴涵在背后的原因。 1.特权级  首先,了解以下操作系统的特权级  1)CPL是存寄
  • 移动端UI一致性解决方案

    万次阅读 多人点赞 2020-11-26 20:00:21
    总第424篇2020年 第48篇外卖UI一致性项目是外卖UI设计团队与研发团队共建的项目,目的是改善用户端体验的一致性,提升多技术方案间组件的通用性和复用率,降低整体视觉改版带来的研发成...
  • 顺序一致性

    千次阅读 2018-11-03 15:22:15
    数据竞争与顺序一致性保证 当程序未正确同步时,就会存在数据竞争。java 内存模型规范对数据竞争的定义如下: 在一个线程中写一个变量, 在另一个线程读同一个变量, 而且写和读没有通过同步来排序。 当代码中...
  • 数据库中原子性,隔离性,一致性如何实现

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 294,464
精华内容 117,785
关键字:

一致性原则是什么意思