精华内容
下载资源
问答
  • 3.3.1 Cache一致性的基本概念

    千次阅读 2013-07-22 16:27:29
    PCI设备对可Cache的存储器空间进行DMA读写的操作的过程较为复杂,有关Cache一致性的话题可以独立成书。而不同的处理器系统使用的Cache Memory的层次结构...在多数处理器系统中,使用了以下概念描述Cache一致性的实现过

    PCI设备对可Cache的存储器空间进行DMA读写的操作的过程较为复杂,有关Cache一致性的话题可以独立成书。而不同的处理器系统使用的Cache Memory的层次结构和访问机制有较大的差异,这部分内容也是现代处理器系统设计的重中之重。

    本节仅介绍在Cache Memory系统中与PCI设备进行DMA操作相关的,一些最为基础的概念。在多数处理器系统中,使用了以下概念描述Cache一致性的实现过程。

    1 Cache一致性协议

    多数SMP处理器系统使用了MESI协议处理多个处理器之间的Cache一致性。该协议也被称为Illinois protocolMESI协议在SMP处理器系统中得到了广泛的应用。MESI协议使用四个状态位描述每一个Cache行。

    •  M(Modified)位。M 位为1 时表示当前Cache 行中包含的数据与存储器中的数据不一致,而且它仅在本CPUCache 中有效,不在其他CPUCache 中存在拷贝,在这个Cache行的数据是当前处理器系统中最新的数据拷贝。当CPU对这个Cache行进行替换操作时,必然会引发系统总线的写周期,将Cache行中数据与内存中的数据同步。
    •  E(Exclusive)位。E 位为1 时表示当前Cache行中包含的数据有效,而且该数据仅在当前CPUCache中有效,而不在其他CPUCache中存在拷贝。在该Cache行中的数据是当前处理器系统中最新的数据拷贝,而且与存储器中的数据一致。
    •  S(Shared)位。S 位为1 表示Cache行中包含的数据有效,而且在当前CPU和至少在其他一个CPU中具有副本。在该Cache行中的数据是当前处理器系统中最新的数据拷贝,而且与存储器中的数据一致。
    • I(Invalid)位。I 位为1 表示当前Cache 行中没有有效数据或者该Cache行没有使能。MESI协议在进行Cache行替换时,将优先使用I位为1Cache行。

    MESI协议还存在一些变种,如MOESI协议和MESIF协议。基于MOESI协议的Cache一致性模型如3?5所示,该模型基于AMD处理器使用的MOESI协议。不同的处理器在实现MOESI协议时,状态机的转换原理类似,但是在处理上仍有细微区别。


    MOESI协议引入了一个O(Owned)状态,并在MESI协议的基础上,进行了重新定义了S状态,而EMI状态和MESI协议的对应状态相同。

    •  O位。O位为1表示在当前Cache 行中包含的数据是当前处理器系统最新的数据拷贝,而且在其他CPU中一定具有该Cache行的副本,其他CPUCache行状态为S。如果主存储器的数据在多个CPUCache中都具有副本时,有且仅有一个CPUCache行状态为O,其他CPUCache行状态只能为S。与MESI协议中的S状态不同,状态为OCache行中的数据与存储器中的数据并不一致。
    •  S位。在MOESI协议中,S状态的定义发生了细微的变化。当一个Cache行状态为S时,其包含的数据并不一定与存储器一致。如果在其他CPUCache中不存在状态为O的副本时,该Cache行中的数据与存储器一致;如果在其他CPUCache中存在状态为O的副本时,Cache行中的数据与存储器不一致。

    在一个处理器系统中,主设备(CPU或者外部设备)进行存储器访问时,将试图从存储器系统(主存储器或者其他CPUCache)中获得最新的数据拷贝。如果该主设备访问的数据没有在本地命中时,将从其他CPUCache中获取数据,如果这些数据仍然没有在其他CPUCache中命中,主存储器将提供数据。外设设备进行存储器访问时,也需要进行Cache共享一致性。

    MOESI模型中,“Probe Read”表示主设备从其他CPU中获取数据拷贝的目的是为了读取数据;而“Probe Write”表示主设备从其他CPU中获取数据拷贝的目的是为了写入数据;“Read Hit”和“Write Hit”表示主设备在本地Cache中获得数据副本;“Read Miss”和“Write Miss”表示主设备没有在本地Cache中获得数据副本;“Probe Read Hit”和“Probe Write Hit”表示主设备在其他CPUCache中获得数据副本。

    本节为简便起见,仅介绍CPU进行存储器写和与O状态相关的Cache行状态迁移,CPU进行存储器读的情况相对较为简单,请读者自行分析这个过程。

    CPU对一段存储器进行写操作时,如果这些数据在本地Cache中命中时,其状态可能为ESM或者O

    •  状态为E或者M时,数据将直接写入到Cache中,并将状态改为M
    •  状态为S时,数据将直接写入到Cache中,并将状态改为M,同时其他CPU保存该数据副本的Cache行状态将从S或者O迁移到I(Probe Write Hit)
    •  状态为O时,数据将直接写入到Cache中,并将状态改为M,同时其他CPU保存该数据副本的Cache行状态将从S迁移到I(Probe Write Hit)

    CPU A对一段存储器进行写操作时,如果这些数据没有在本地Cache中命中时,而在其他CPU,如CPU BCache中命中时,其状态可能为ESM或者O。其中CPU A使用CPU B在同一个Cache共享域中。

    •  Cache行状态为E时,CPU B将该Cache行状态改为I;而CPU A将从本地申请一新的个Cache行,将数据写入,并该Cache行状态更新为M
    •  Cache行状态为S时,CPU B将该Cache行状态改为I,而且具有同样副本的其他CPUCache行也需要将状态改为I;而CPU A将从本地申请一个Cache行,将数据写入,并该Cache行状态更新为M
    •  Cache行状态为M时,CPU B将原Cache行中的数据回写到主存储器,并将该Cache行状态改为I;而CPU A将从本地申请一个Cache行,将数据写入,并该Cache行状态更新为M
    •  Cache行状态为O时,CPU B将原Cache行中的数据回写到主存储器,并将该Cache行状态改为I,具有同样数据副本的其他CPUCache行也需要将状态从S更改为ICPU A将从本地申请一个Cache行,将数据写入,并该Cache行状态更新为M

    Cache行状态可以从M迁移到O。例如当CPU A读取的数据从CPU B中命中时,如果在CPU BCache行的状态为M时,将迁移到O,同时CPU B将数据传送给CPU A新申请的Cache行中,而且CPU ACache行状态将被更改为S

    CPU读取的数据在本地Cache中命中,而且Cache行状态为O时,数据将从本地Cache获得,并不会改变Cache行状态。如果CPU A读取的数据在其他Cache中命中,如在CPU BCache中命中而且其状态为O时,CPU B将该Cache行状态保持为O,同时CPU B将数据传送给CPU A新申请的Cache行中,而且CPU ACache行状态将被更改为S

    在某些应用场合,使用MOESI协议将极大提高Cache的利用率,因为该协议引入了O状态,从而在发送Read Hit的情况时,不必将状态为MCache回写到主存储器,而是直接从一个CPUCache将数据传递到另外一个CPU。目前MOESI协议在AMDRMI公司的处理器中得到了广泛的应用。

    Intel提出了另外一种MESI协议的变种,即MESIF协议,该协议与MOESI协议有较大的不同,也远比MOESI协议复杂,该协议由IntelQPI(QuickPath Interconnect)技术引入,其主要目的是解决“基于点到点的全互连处理器系统”的Cache共享一致性问题,而不是“基于共享总线的处理器系统”的Cache共享一致性问题。

    在基于点到点互连的NUMA(Non-Uniform Memroy Architecture)处理器系统中,包含多个子处理器系统,这些子处理器系统由多个CPU组成。如果这个处理器系统需要进行全机Cache共享一致性,该处理器系统也被称为ccNUMA(Cache Cohenrent NUMA)处理器系统。MESIF协议主要解决ccNUMA处理器结构的Cache共享一致性问题,这种结构通常使用目录表,而不使用总线监听处理Cache的共享一致性。

    MESIF协议引入了一个F(Forware)状态。在ccNUMA处理器系统中,可能在多个处理器的Cache中存在相同的数据副本,在这些数据副本中,只有一个Cache行的状态为F,其他Cache行的状态都为SCache行的状态位为F时,Cache中的数据与存储器一致。

    当一个数据请求方读取这个数据副本时,只有状态为FCache行,可以将数据副本转发给数据请求方,而状态位为SCache不能转发数据副本。从而MESIF协议有效解决了在ccNUMA处理器结构中,所有状态位为SCache同时转发数据副本给数据请求方,而造成的数据拥塞。

    ccNUMA处理器系统中,如果状态位为F的数据副本,被其他CPU拷贝时,F状态位将会被迁移,新建的数据副本的状态位将为F,而老的数据副本的状态位将改变为S。当状态位为FCache行被改写后,ccNUMA处理器系统需要首先Invalidate状态位为S其他的Cache行,之后将Cache行的状态更新为M

    独立地研究MESIF协议并没有太大意义,该协议由Boxboro-EX处理器系统[1]引入,目前Intel并没有公开Boxboro-EX处理器系统的详细设计文档。MESIF协议仅是解决该处理器系统中Cache一致性的一个功能,该功能的详细实现与QPIProtocal Layer相关,QPI由多个层次组成,而Protocal LayerQPI的最高层。

    MESIF协议QPI互连技术有兴趣的读者,可以在深入理解“基于目录表的Cache一致性协议”的基础上,阅读Robert A. Maddox, Gurbir Singh and Robert J. Safranek合著的书籍“Weaving High Performance Multiprocessor Fabric”以了解该协议的实现过程和与QPI互连技术相关的背景知识。

    值得注意的是,MESIF协议解决主要的问题是ccNUMA架构中SMP子系统与SMP子系统之间Cache一致性。而在SMP处理器系统中,依然需要使用传统的MESI协议。Nehelem EX处理器也可以使用MOESI协议进一步优化SMP系统使用的Cache一致性协议,但是并没有使用该协议。

    为简化起见,本章假设处理器系统使用MESI协议进行Cache共享一致性,而不是MOESI协议或者MESIF协议。

    2 HIT#HITM#信号

    SMP处理器系统中,每一个CPU都使用HIT#HITM#信号反映HOST主桥访问的地址是否在各自的Cache中命中。当HOST主桥访问存储器时,CPU将驱动HITM#HIT#信号,其描述如3?1所示。

     3?1 HITM#HIT#信号的含义

    HITM#

    HIT#

    描述

    1

    1

    表示HOST主桥访问的地址没有在CPUCache中命中。

    1

    0

    表示HOST主桥访问的地址在CPUCache中命中,而且Cache的状态为S(Shared)或者E(Exclusive),即Cache中的数据与存储器的数据一致。

    0

    1

    表示HOST主桥访问的地址在CPUCache中命中,而且Cache的状态为M(Modified),即Cache中的数据与存储器的数据不一致,在Cache中保存最新的数据拷贝。

    0

    0

    MESI协议规定这种情况不允许出现,但是在有些处理器系统中仍然使用了这种状态,表示暂时没有获得是否在Cache命中的信息,需要等待几拍后重试。

     

    HIT#HITM#信号是FSB中非常重要的两个信号,各个CPUHIT#HITM#信号通过“线与方式”直接相连[2]。而在一个实际FSB中,还包括许多信号,本节并不会详细介绍这些信号。

    3 Cache一致性协议中使用的Agent

    在处理器系统中,与Cache一致性相关的Agent如下所示。

    •  Request AgentFSB总线事务的发起设备。在本节中,Request Agent特指HOST主桥。实际上在FSB总线上的其他设备也可以成为Request Agent,但这些Request Agent并不是本节的研究重点。Request Agent需要进行总线仲裁后,才能使用FSB,在多数处理器的FSB中,需要对地址总线与数据总线分别进行仲裁。
    • Snoop AgentsFSB总线事务的监听设备。Snoop AgentsCPU,在一个SMP处理器系统中,有多个CPU共享同一个FSB,此时这些CPU都是这条FSB上的Snoop AgentsSnoop Agents监听FSB上的存储器读写事务,并判断这些总线事务访问的地址是否在Cache中命中。Snoop Agents通过HIT#HITM#信号向FSB通知Cache命中的结果。在某些情况下,Snoop Agents需要将Cache中的数据回写到存储器,同时为Request Agent提供数据。
    •  Response AgentFSB总线事务的目标设备。在本节中,Response Agent特指存储器控制器。Response Agent根据Snoop Agents提供的监听结果,决定如何接收数据或者向Request Agent设备提供数据。在多数情况下,当前数据访问没有在Snoop Agents中命中时,Response Agent需要提供数据,此外Snoop Agents有时需要将数据回写到Response Agent中。

    4 FSB的总线事务

    一个FSB的总线事务由多个阶段组成,包括Request PhaseSnoop PhaseResponse PhaseData Phase。目前在多数高端处理器中,FSB支持流水操作,即在同一个时间段内,不同的阶段可以重叠,如3?6所示。

    3.3.1 Cache一致性的基本概念 - maoxingbing - 毛毛虫的爹


    在一个实际的FSB中,一个总线事务还可能包含Arbitration PhaseError Phase。而本节仅讲述3?6中所示的4个基本阶段。

    •  Request PhaseRequest Agent在获得FSB的地址总线的使用权后,在该阶段将访问数据区域的地址和总线事务类型发送到FSB上。
    • Snoop PhaseSnoop Agents根据访问数据区域在Cache中的命中情况,使用HIT#HITM#信号,向其他Agents通知Cache一致性的结果。有时Snoop Agent需要将数据回写到存储器。
    • Reponse PhaseResponse Agent根据RequestSnoop Phase提供的信号,可以要求Request Agent重试(Retry),或者Response Agent延时处理(Defer)当前总线事务。在FSB总线事务的各个阶段中,该步骤的处理过程最为复杂。本章将在下文结合PCI设备的DMA读写执行过程,说明该阶段的实现原理。
    •  Data Phase。一些不传递数据的FSB总线事务不包含该阶段。该阶段用来进行数据传递,包括Request AgentResponse Agent写入数据;Response AgentRequest Agent提供数据;和Snoop Agent将数据回写到Response Agent

    下文将使用本小节中的概念,描述在PCI总线中,与Cache相关的总线事务,并讲述相关的FSB的操作流程。



    [1] Boxboro-EX处理器系统由多个Nehalem EX处理器组成,而Nehalem EX处理器由两个SMP处理器系统组成,一个SMP处理器系统由4CPU组成,而每一个CPU具有2个线程。其中SMP处理器系统之间使用QPI进行连接,而在一个SMP处理器内部的各个CPU仍然使用FSB连接。

    [2] HIT#HITM#信号是Open Drain(开漏)信号,Open Drain信号可以直接相连,而不用使用逻辑门。

    展开全文
  • 一致性哈希概念与Python的简单实现

    千次阅读 2014-11-05 20:55:10
    很早就接触了一致性哈希这概念,不过一直

    好像从开始接触Zookeeper的时候就知道了有一致性哈希这东西。。。。不过倒是一直都没有去了解这到底是个啥东西。。。只是知道它在分布式系统设计中有十分重要的作用。。。。


    好了,接下来用举例子的方式来说一下一致性哈希到底有啥用吧。。。场景如下:

    当前有4台服务器组成的分布式缓存系统,这里对于一个Key,通过哈希的方式,将其保存到某一台服务器上。。。


    对于一般的哈希算法,我们首先会想到用一些哈希算法来获取Key的哈希值,例如MD5啥的。。。接着进行一次取模的操作,通过余数来确定将这个Key保存到哪一台服务器上。。。

    嗯,这种方法确实很简单。。。不够缺存在很大的问题:

    当系统中某一台服务器退出了之后,那么对于所有Key的哈希分布都得重新来过,以前的缓存也就基本失效了。。。

    同时:

    如果在系统中加入新的服务器,所有的Key的哈希分布也都失效了。。。


    接下来就可以引入一致性哈希了。。。它就是用于解决这种问题的了。。。

    这里无耻的盗一张图:



    这里的关键就是,不光是要对缓存的key进行哈希,同时也需要服务器也提供一个key进行哈希,然后将其分布在一个闭圆上,在决定一个key的分布的时候,这里通过找到第一个大于这个key的哈希值的服务器就行了。。。

    这样在当一台服务器退出之后,或者有新的服务器加入进来之后,只会影响一部分的key的哈希分布,不至于导致所有的key的哈希分布都失效。。。。


    另外,如果服务器比较少的情况下,一般都会引入虚拟节点的概念。。也就是一个服务器在圆上对应多个节点。。。


    当然这个只是对一致性哈希比较皮毛的理解。。。对于其在分布式系统中其他的高端用法也不太清楚。。不过好在以后不用怕再遇到这概念了。。

    这里还简单的实现了一个简单的一致性哈希算法。。。用Python写的:

    # -*- coding: utf-8 -*-
    import hashlib
    
    class YHash(object):
        def __init__(self, nodes=None, n_number=3):
            """
            :param nodes:           所有的节点
            :param n_number:        一个节点对应多少个虚拟节点
            :return:
            """
            self._n_number = n_number   #每一个节点对应多少个虚拟节点,这里默认是3个
            self._node_dict = dict()    #用于将虚拟节点的hash值与node的对应关系
            self._sort_list = []        #用于存放所有的虚拟节点的hash值,这里需要保持排序
            if nodes:
                for node in nodes:
                    self.add_node(node)
    
        def add_node(self, node):
            """
            添加node,首先要根据虚拟节点的数目,创建所有的虚拟节点,并将其与对应的node对应起来
            当然还需要将虚拟节点的hash值放到排序的里面
            这里在添加了节点之后,需要保持虚拟节点hash值的顺序
            :param node:
            :return:
            """
            for i in xrange(self._n_number):
                node_str = "%s%s" % (node, i)
                key = self._gen_key(node_str)
                self._node_dict[key] = node
                self._sort_list.append(key)
            self._sort_list.sort()
    
        def remove_node(self, node):
            """
            这里一个节点的退出,需要将这个节点的所有的虚拟节点都删除
            :param node:
            :return:
            """
            for i in xrange(self._n_number):
                node_str = "%s%s" % (node, i)
                key = self._gen_key(node_str)
                del self._node_dict[key]
                self._sort_list.remove(key)
    
        def get_node(self, key_str):
            """
            返回这个字符串应该对应的node,这里先求出字符串的hash值,然后找到第一个小于等于的虚拟节点,然后返回node
            如果hash值大于所有的节点,那么用第一个虚拟节点
            :param :
            :return:
            """
            if self._sort_list:
                key = self._gen_key(key_str)
                for node_key in self._sort_list:
                    if key <= node_key:
                        return self._node_dict[node_key]
                return self._node_dict[self._sort_list[0]]
            else:
                return None
    
        @staticmethod
        def _gen_key(key_str):
            """
            通过key,返回当前key的hash值,这里采用md5
            :param key:
            :return:
            """
            md5_str = hashlib.md5(key_str).hexdigest()
            return long(md5_str, 16)
    
    
    fjs = YHash(["127.0.0.1", "192.168.1.1"])
    print fjs.get_node("fjs32121")

    展开全文
  • 设计到系统,其中绕不开的就是数据一致性,从本地事务,到后来的分布式事务,都能够有效的保证数据一致性。但是在微服务架构中,这两种方式都不是最好的选择。1. 使用本地事务和分布式事务保证一致性在传统的单击...

    原文转自:EAII企业架构创新研究院《微服务架构下的数据一致性保证(一)》,行文结构与原文略有不同。

    从2014年开始,微服务逐渐进入大家的实现,被认为是下一代实现信息化的有效手段。设计到系统,其中绕不开的就是数据一致性,从本地事务,到后来的分布式事务,都能够有效的保证数据一致性。但是在微服务架构中,这两种方式都不是最好的选择。

    1. 使用本地事务和分布式事务保证一致性

    在传统的单击应用中,最简单、最直接、最普遍的会使用一个关系型数据库,通过关系型数据库的事务保证数据的一致性。这种事务有四个基本要素:ACID。

    • A(Atomicity,原子性):整个事务中的所有操作,要么全部完成,要么全部失败,不可能停滞在中间某个环节。事务在执行过程中发生错误,会被回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。
    • C(Consistency,一致性):一个事务可以封装状态改变(除非它是一个只读的)。事务必须始终保持系统处于一致的状态,不管在任何给定的时间并发事务有多少。
    • I(Isolation,隔离性):隔离状态执行事务,使它们好像是系统在给定时间内执行的唯一操作。如果有两个事务,运行在相同的时间内,执行相同的功能,事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。这种属性有时称为串行化,为了防止事务操作间的混淆,必须串行化或序列化请求,使得在同一时间仅有一个请求用于同一数据。
    • D(Durability,持久性):在事务完成以后,该事务对数据库所作的更改便持久的保存在数据库之中,并不会被回滚。

    在传统的本地事务中,为了保证数据一致性,我们只需要先开始一个事务,然后进行新增、修改、删除等操作,然后提交事务,如果发生异常就回滚。简简单单,就能够站在各大数据库厂商的肩膀上,实现数据一致性。

    本地事务

    随着组织规模不断扩大、业务量不断增加,单机应用已不足以支撑庞大的业务量和数据量。这个需要对应用和数据进行拆分。就出现了需要同时访问多个数据库的情况。这个时候就需要分布式事务来保证数据一致性,也就是常说的两阶段提交协议(2PC,Two Phase Commitment Protocol)。在这个协议中,最关键的点就是,多个数据库的活动,均由一个事务协调器的组件来控制。具体的分为5个步骤:

    • 应用程序调用事务协调器中的提交方法
    • 事务协调器将联络事务中涉及的每个数据库,并通知它们准备提交事务(这是第一阶段的开始)
    • 接收到准备提交事务通知后,数据库必须确保能在被要求提交事务时提交事务,或在被要求回滚事务时回滚事务。如果数据库无法准备事务,它会以一个否定响应来回应事务协调器。
    • 事务协调器收集来自各数据库的所有响应。
    • 在第二阶段,事务协调器将事务的结果通知给每个数据库。如果任一数据库做出否定响应,则事务协调器会将一个回滚命令发送给事务中涉及的所有数据库。如果数据库都做出肯定响应,则事务协调器会指示所有的资源管理器提交事务。一旦通知数据库提交,此后的事务就不能失败了。通过以肯定的方式响应第一阶段,每个资源管理器均已确保,如果以后通知它提交事务,则事务不会失败。

    2PC

    在传统的系统架构中,通常使用的是数据库来作为资源管理器,数据的一致性通过事务来保证,即使实在分布式事务中,也能够利用数据库的事务来实现数据一致性。

    但是在微服务架构中,数据访问变得复杂。通常情况下,数据都是各个微服务私有的,只能通过API的方式访问数据。这种方式可以实现微服务之间的松耦合,使彼此独立的微服务更容易的进行扩展。但是带来的一个问题就是,不清楚各自底层的数据存储(不一定是关系型数据库),无法通过统一的事务协调器来完成数据一致性。

    简单的说,传统的本地事务或分布式事务不适合微服务架构。

    2. 微服务架构中的最终一致性

    在分布式系统架构中有一个CAP理论:任何分布式系统只可同时满足一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)中的两点,没法三者兼顾。对于分布式系统来说,分区容错性是基本要求,否则就失去了价值。因此,就只能在可用性和一致性之间做出选择。如果选择提供一致性需要付出在满足一致性之前阻塞其他并发访问的代价。这可能持续一个不确定的时间,尤其是在系统已经表现出高延迟时或者网络故障导致失去连接时。依据目前的成功经验,可用性一般是更好的选择,但是在服务和数据库之间维护数据一致性是非常根本的需求,微服务架构中选择满足最终一致性。

    最终一致性是指系统中的所有数据副本经过一段时间后,最终能够达到一致的状态。

    这里所说的一段时间,也要是用户可接受范围内的一段时间。

    从一致性的本质来看,就是在一个业务逻辑中包含的所有服务要么都成功,要么都失败。那我们又该如何选择方向,来保证成功还是保证失败呢?就是就需要根据业务模式做出选择。实现最终一致性有三种模式:可靠事件模式、业务补偿模式、TCC模式。

    2.1 可靠事件模式

    可靠事件模式属于事件驱动架构,当某件重要事情发生时,例如更新一个业务实体,微服务会向消息代理发布一个事件。消息代理会向订阅事件的微服务推送事件,当订阅这些事件的微服务接收此事件时,就可以完成自己的业务,也可能会引发更多的事件发布。

    下面举个简单的例子

    1.订单服务创建一个订单,发布一个“创建订单”事件

    创建订单

    2.支付服务消费“创建订单”事件,待支付完成后发布一个“支付成功”事件

    支付成功

    3.订单服务消费“支付成功”事件,订单状态更新为待出库。

    待出库

    从而就实现了完整的业务流程。

    这个过程可能导致出现不一致的地方在于:

    1. 某个服务在更新了业务实体后发布事件却失败
    2. 虽然服务发布事件成功,但是消息代理未能正确推送事件到订阅的微服务
    3. 接受事件的微服务重复消费了事件

    可靠事件模式在于保证可靠事件投递和避免重复消费。可靠事件投递定义为:每个服务原子性的业务操作和发布事件,消息代理确保事件传递至少一次。避免重复消费要求服务实现幂等性,如支付服务不能因为重复收到事件而多次支付。

    2.2 业务补偿模式

    在描述业务补偿模式之前,先先定义两个概念:

    • 业务异常:业务逻辑产生错误的情况,比如账户余额不足、商品库存不足等。
    • 技术异常:非业务逻辑产生的异常,如网络连接异常、网络超时等。

    补偿模式使用一个额外的协调服务来协调各个需要保证一致性的微服务,协调服务按顺序调用各个微服务,如果某个微服务调用异常(包括业务异常和技术异常)就取消之前所有已经调用成功的微服务。

    我们通过一个例子来说明补偿模式,一家旅行公司提供预订行程的业务,可以通过公司的网站提前预订飞机票、火车票、酒店等。

    假设一位客户规划的行程是:(1)上海-北京6月19日9点的某某航班,(2)某某酒店住宿3晚,(3)北京-上海6月22日17点火车。在客户提交行程后,旅行公司的预订行程业务按顺序串行的调用航班预订服务、酒店预订服务、火车预订服务。最后的火车预订服务成功后整个预订业务才算完成。

    整个预订业务完成

    如果火车票预订服务没有调用成功,那么之前预订的航班、酒店都得取消。取消之前预订的酒店、航班即为补偿过程。

    火车票预订服务没有调用成功

    需要注意的是酒店的取消预订、航班的取消预订同样不能保证一定成功,所以补偿过程往往也同样需要实现最终一致性,需要保证取消服务至少被调用一次和取消服务必须实现幂等性。

    我们应该尽可能通过设计避免采用补偿方式,比如上面的例子中,在预订火车票失败的时候可以提示客户更改其他的时间。

    2.3 TCC模式(Try-Confirm-Cancel)

    一个完整的TCC业务由一个主业务服务和若干个从业务服务组成,主业务服务发起并完成整个业务活动,TCC模式要求从服务提供三个接口:Try、Confirm、Cancel。

    TCC模式

    • Try:完成所有业务检查,预留必须业务资源
    • Confirm:真正执行业务,不作任何业务检查,只使用Try阶段预留的业务资源,Confirm操作满足幂等性
    • Cancel:释放Try阶段预留的业务资源,Cancel操作满足幂等性

    整个TCC业务分成两个阶段完成:

    两个阶段

    第一阶段:主业务服务分别调用所有从业务的try操作,并在活动管理器中登记所有从业务服务。当所有从业务服务的try操作都调用成功或者某个从业务服务的try操作失败,进入第二阶段。

    第二阶段:活动管理器根据第一阶段的执行结果来执行confirm或cancel操作。如果第一阶段所有try操作都成功,则活动管理器调用所有从业务活动的confirm操作。否则调用所有从业务服务的cancel操作。

    需要注意的是第二阶段confirm或cancel操作本身也是满足最终一致性的过程,在调用confirm或cancel的时候也可能因为某种原因(比如网络)导致调用失败,所以需要活动管理支持重试的能力,同时这也就要求confirm和cancel操作具有幂等性。

    3. 总结

    前面提到的三种模式,几乎能够很好的解决网络故障或调用超时等基本问题。但在当今复杂的环境中,很多服务需要依赖外部系统,在这些业务场景中,就需要周期性的进行校验操作,比如支付系统和银行的对账过程。

    还需要顺带的提一下,技术能够解决问题,但不能解决所有问题,很多情况下,需要首先保证业务流程准确,然后在技术解决不了的情况下,仍然需要人工干预。

    主页:http://www.howardliu.cn/
    博客:微服务架构下的数据一致性:概念及相关模式

    展开全文
  • 如何理解数据库事务中的一致性概念? 数据库事务,4个属性,ACID,C就是Consistency,一致性,但是教科书式的定义说明,让人有点不清楚。谁能摆事实,讲道理,解释一下何为事务一致… 显示全部 ...

    如何理解数据库事务中的一致性的概念?

    数据库事务,4个属性,ACID,C就是Consistency,一致性,但是教科书式的定义说明,让人有点不清楚。谁能摆事实,讲道理,解释一下何为事务一致…
    关注者
    119
    被浏览
    19279

    10 个回答

    要想真正弄清楚这个问题,那是必须要把数据库理论中的事务机制从头开始看起,牵扯的内容比较多。
    当然,如果只是想粗略的了解下,我就来举个例子吧——当然不可能太严谨。
    假设我们10个人,每人有一个账号,里面有钱,可以转来转去,这组成了一个小型的数据系统,那么什么叫数据一致性?这是由你自己来定义的,比较通用的就是:这10个人的账号金额总数不变——满足这一条件,就叫数据一致,不满足,就叫数据不一致,或者在分布式的环境下,有一个数据在几个地方都保存了,那么任何时候,这几个地方的数据都必须相同,这也叫一致性。
    现在我们就这个简单的一致性规则:10个人的账号金额总数不变。假设初始的时候每个人账号里有一万,A账号往B账号里转5000,这时候数据库要执行两行代码:
    A:减去5000
    B:加上5000
    在执行完第一行代码的时候,这时候数据是不满足一致性条件的!必须要执行完第二行代码,数据才恢复到一致性的状态!换而言之,数据库中的数据是经常处于不一致的状态,这是不可避免的,因此我们提出了事务的概念,用于检测数据库中的数据是否处于一致性状态——如果数据库中有没有执行完的事务,那就是不一致的,否则,就是一致的。
    上面的例子只是最简单的情况,实际的运用中要复杂得多,比如前面提到的分布式系统:某个数据存在了三个服务器上,现在要更新,就必须保证三个服务器上全都更新好,如果有一个没有成功,那么其他两个也应该维持不变,这又涉及到网络通信等问题,非常的折腾。
    ——————————————————————————————————————
    评论中有提到了原子性,其实原子性与一致性是两个完全不同的概念,当然他们的联系也很紧密。
    还是用上面的这个例子:
    为了保证一致性(即10个人 的账号金额总数不变),那在我写代码的时候,如果写了代码:
    A=A-5000;
    那就必须要写上
    B=B+5000,或者是C=C+5000,这样的代码才能保证了数据库的一致性状态。
    那什么是原子性?
    就是将上面的两行代码合成为一个事务,要么全做,要么全不做。
    比如我写了两行代码:
    A=A+2000;
    B=B+3000;
    如果这两行代码看成是一个事务,并且在某一时刻全执行完了,那么这个事务的原子性满足了,但却没有满足数据库的一致性。

    12 条评论

    sharpshooter
    sharpshooter1 年前
    回答的可以。
    sharpshooter
    sharpshooter1 年前
    如果数据库中有没有执行完的事务,那就是不一致的,否则,就是一致的。
    王慧Rs
    王慧Rs1 年前
    那这和原子性不就是一个意思了么?
    几米憧憬
    几米憧憬11 个月前
    谢谢,这个回答我给101分
    wlooong
    wlooong11 个月前
    不赞同这个答案 这分明就是原子性
    明月清风
    明月清风8 个月前
    数据库的一致性原来是自己定义的,终于理解了!谢谢答主!
    种冠鹏
    种冠鹏4 个月前

    我认为基本概念弄错了。如果按照答主的举的事务操作(不太恰当的例子)为:A=A+2000;B=B+3000;执行成功以后,从一个一致性状态到另一个一致性状态,就说明保证了数据一致性,如果在执行的过程中,发生了进程中断,导致A与B变成其他不可知的数据(此时没回滚),才说明数据不一致。数据一致性,指的是必须保证从一个一致性状态到另一个一致性状态。另外,事务中数据一致性与多副本(文中说的分布式系统那段)一致性,就是ACID和CAP中的C,不能划等号。另外,3副本的问题,答主说的是强同步复制问题,其实超过一半的数据更新成功,是可以返回成功的,看Paxos或者raft。喷完了,学生猿,请随意拍砖。

    纳兰
    纳兰 (作者) 回复种冠鹏4 个月前

    能否再详细定义一下,什么是一致性状态?否则的话是循环定义。

    种冠鹏
    种冠鹏回复纳兰 (作者)4 个月前

    不严格的说,从起始状态(空)开始,同一份数据的不同副本(所有或者超过半数)均相同,说明处于一致性状态。严格的讨论(非定义)关于一致性状态,请移步:ACID - Wikipedia 中 Consistency: The consistency property ensures that any transaction will bring the database from one valid state to another. 还有CAP theorem - Wikipedia中 Consistency: Every read receives the most recent write or an error 。关于状态之间的迭代或者变迁,请移步: 知乎 - 知乎 其中回答者

    LynnCui是phxpaxos的核心开发者,回答的很详细。还有工程实现部分我看的是phxpaxos。原理介绍:微信自研生产级paxos类库PhxPaxos实现原理介绍 ,源码:tencent-wechat/phxpaxos 。这次不喷了,但是作为学生猿,还是请随意拍砖。因为填坑才是进步…

    纳兰
    纳兰 (作者)4 个月前

    你要区分两个概念,分布式情况下的数据一致性,与集中式情况下的数据一致性。

    分布式情况下的数据一致性应该分歧不大,只不过是定义严格或者不严格而已。

    而对于集中式的情况,因为数据就只存储在服务器,没有数据副本的概念,所以这个时候,数据一致性就需要你自己来定义,你所说的acid链接里的valid状态,其实由你自己来定义。

    更一般的说,数据一致性通常指关联数据之间的逻辑关系是否正确和完整。而数据存储的一致性模型则可以认为是存储系统和数据使用者之间的一种约定。如果使用者遵循这种约定,则可以得到系统所承诺的访问结果。

    纳兰
    纳兰 (作者)4 个月前

    非常高兴你的讨论,因为有这样的疑惑是很正常的,在我上课的时候,这其实也一直是一个难点。

    先简单说下,“一个事务中A的余额和B的余额同时增长10%”这样的情况,是否保持了一致性,要看你的定义,如果我对一致性的定义是“A与B的余额总和不变”,那么一致性就被破坏,系统处于不一致和状态,而如果你对一致性的定义是“A与B增加的幅度相同”,那么一致性就没有被破坏,系统还是处于一致性的状态。或者说,数据库管理系统根本就不知道一致性是个啥东西,这都是用户通过代码来进行定义的。

    其实深入的讨论下有关事务的概念,就会明白这个一致性的定义了——如果不使用事务,那么在数据库执行多条语句的时候,有可能中间会出现问题而导致只执行了部分语句,因此,我们在这多条语句前面加上begin transaction,最后加上end transaction,这就是很清楚的标明了,在这些语句执行前,系统是处于一致性状态的,而在这些语句执行后,系统也是处于一致性状态的,至于这个一致性状态的定义,则是由用户通过这些语句来表达的。那么如果语句执行完成了,事务提交,这时候数据库系统就认为又到了一个一致性状态,而如果出现问题,系统则将操作回滚,返回初始状态,因为这也是一个一致性状态。而如果出现故障重启等事件时,数据库管理系统在重启后就会分析日志,将所有begin/end全都有的事务跳过或重做,而只有begin没有end的事务则undo,从而保证数据库在可用的时候都是一致性状态。

    种冠鹏
    种冠鹏回复纳兰 (作者)4 个月前

    OK,结题!

    原子性:记录之前的版本,允许回滚

    一致性:事务开始和结束之间的中间状态不会被其他事务看到

    隔离性:适当的破坏一致性来提升性能与并行度 例如:最终一致~=读未提交。

    持久性:每一次的事务提交后就会保证不会丢失

    讲数据库事务一致性怎么能不提数据库的ACID特性。
    首先介绍事务,什么是事务,事务就是DBMS当中用户程序的任何一次执行,事务是DBMS能看到的基本修改单元。

    事务是指对系统进行的一组操作,为了保证系统的完整性,事务需要具有ACID特性,具体如下:
    1. 原子性(Atomic)
    一个事务包含多个操作,这些操作要么全部执行,要么全都不执行。实现事务的原子性,要支持回滚操作,在某个操作失败后,回滚到事务执行之前的状态。
    回滚实际上是一个比较高层抽象的概念,大多数DB在实现事务时,是在事务操作的数据快照上进行的(比如,MVCC),并不修改实际的数据,如果有错并不会提交,所以很自然的支持回滚。
    而在其他支持简单事务的系统中,不会在快照上更新,而直接操作实际数据。可以先预演一边所有要执行的操作,如果失败则这些操作不会被执行,通过这种方式很简单的实现了原子性。

    2. 一致性(Consistency)
    一致性是指事务使得系统从一个一致的状态转换到另一个一致状态。事务的一致性决定了一个系统设计和实现的复杂度。事务可以不同程度的一致性:
    强一致性:读操作可以立即读到提交的更新操作。
    弱一致性:提交的更新操作,不一定立即会被读操作读到,此种情况会存在一个不一致窗口,指的是读操作可以读到最新值的一段时间。
    最终一致性:是弱一致性的特例。事务更新一份数据,最终一致性保证在没有其他事务更新同样的值的话,最终所有的事务都会读到之前事务更新的最新值。如果没有错误发生,不一致窗口的大小依赖于:通信延迟,系统负载等。
    其他一致性变体还有:
    单调一致性:如果一个进程已经读到一个值,那么后续不会读到更早的值。
    会话一致性:保证客户端和服务器交互的会话过程中,读操作可以读到更新操作后的最新值。

    3. 隔离性(Isolation)
    并发事务之间互相影响的程度,比如一个事务会不会读取到另一个未提交的事务修改的数据。在事务并发操作时,可能出现的问题有:
    脏读:事务A修改了一个数据,但未提交,事务B读到了事务A未提交的更新结果,如果事务A提交失败,事务B读到的就是脏数据。
    不可重复读:在同一个事务中,对于同一份数据读取到的结果不一致。比如,事务B在事务A提交前读到的结果,和提交后读到的结果可能不同。不可重复读出现的原因就是事务并发修改记录,要避免这种情况,最简单的方法就是对要修改的记录加锁,这回导致锁竞争加剧,影响性能。另一种方法是通过MVCC可以在无锁的情况下,避免不可重复读。
    幻读:在同一个事务中,同一个查询多次返回的结果不一致。事务A新增了一条记录,事务B在事务A提交前后各执行了一次查询操作,发现后一次比前一次多了一条记录。幻读是由于并发事务增加记录导致的,这个不能像不可重复读通过记录加锁解决,因为对于新增的记录根本无法加锁。需要将事务串行化,才能避免幻读。
    事务的隔离级别从低到高有:
    Read Uncommitted:最低的隔离级别,什么都不需要做,一个事务可以读到另一个事务未提交的结果。所有的并发事务问题都会发生。
    Read Committed:只有在事务提交后,其更新结果才会被其他事务看见。可以解决脏读问题。
    Repeated Read:在一个事务中,对于同一份数据的读取结果总是相同的,无论是否有其他事务对这份数据进行操作,以及这个事务是否提交。可以解决脏读、不可重复读。
    Serialization:事务串行化执行,隔离级别最高,牺牲了系统的并发性。可以解决并发事务的所有问题。
    通常,在工程实践中,为了性能的考虑会对隔离性进行折中。

    4. 持久性(Durability)
    事务提交后,对系统的影响是永久的。

    记得在做MySQL培训时,也碰到过这个问题,我的理解如下:
    定义:一致性:C,Consistency,事务必须是使数据库从一个一致性状态变到另一个一致性状态。(教科书式的定义说明)
    理解by我:在事务T开始时,此时数据库有一种状态,这个状态是所有的MySQL对象处于一致的状态,例如数据库完整性约束正确,日志状态一致等,当事务T提交后,这时数据库又有了一个新的状态,不同的数据,不同的索引,不同的日志等,但此时,约束,数据,索引,日志等MySQL各种对象还是要保持一致性(正确性)。 这就是 从一个一致性的状态,变到另一个一致性的状态。也就是事务执行后,并没有破坏数据库的完整性约束(一切都是对的)。

    MySQL数据库innodb的事务,是通过redo log(innodb log),undo log,锁机制,来维护这个一致性的。

    一家之言,欢迎拍砖!

    1 条评论

    知乎用户知乎用户1 年前
    在事务T开始时,此时数据库有一种状态,这个状态是所有的MySQL对象处于一致的状态,例如数据库完整性约束正确,日志状态一致等,当事务T提交后,这时数据库又有了一个新的状态,不同的数据,不同的索引,不同的日志等,但此时,约束,数据,索引,日志等MySQL各种对象还是要保持一致性(正确性)。

    作者:韩忠康
    链接:如何理解数据库事务中的一致性的概念? - 韩忠康的回答
    来源:知乎
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
    答主说的这个“一致性”还是没理解,,数据,索引,日志等MySQL各种对象“抑制”指的是什么
    一致性就是如果你做个银行数据库的话,无论怎么转账,钱的总数都不变。

    讲道理

    定义:数据库一致性(Database Consistency)是指事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。

    数据库状态如何变化?每一次数据变更就会导致数据库的状态迁移。如果数据库的初始状态是C0,第一次事务T1的提交就会导致系统生成一个SYSTEM CHANGE NUMBER(SCN),这是数据库状态从C0转变成C1。执行第二个事务T2的时候数据库状态从T1变成T2,以此类推,执行第Tn次事务的时候数据库状态由C(n-1)变成Cn。

    定义一致性主要有2个方面,一致读和一致写。

    一致写:事务执行的数据变更只能基于上一个一致的状态,且只能体现在一个状态中。T(n)的变更结果只能基于C(n-1),C(n-2), ...C(1)状态,且只能体现在C(n)状态中。也就是说,一个状态只能有一个事务变更数据,不允许有2个或者2个以上事务在一个状态中变更数据。至于具体一致写基于哪个状态,需要判断T(n)事务是否和T(n-1),T(n-2),...T(1)有依赖关系。

    一致读:事务读取数据只能从一个状态中读取,不能从2个或者2个以上状态读取。也就是T(n)只能从C(n-1),C(n-2)... C(1)中的一个状态读取数据,不能一部分数据读取自C(n-1),而另一部分数据读取自C(n-2)。

    摆事实

    一致写:
    定义100个事务T(1)...T(100)实现相同的逻辑 update table set i=i+1,i的初始值是0,那么并发执行这100个事务之后i的值是多少?可能很容易想到是100。那么怎么从一致性角度去理解呢?

    数据库随机调度到T(50)执行,此时数据库状态是C(0),而其它事务都和T(50)有依赖关系,根据写一致性原理,其它事务必须等到T(50)执行完毕后数据库状态变为C(1)才可以执行。因此数据库利用锁机制阻塞其它事务的执行。直到T(50)执行完毕,数据库状态从C(0)迁移到C(1)。数据库唤醒其它事务后随机调度到T(89)执行,以此类推直到所有事务调度执行完毕,数据库状态最终变为C(100)。

    一致读:
    还是上面的例子,假设T(1)...T(100)顺序执行,在不同的时机执行select i from table,我们看到i的值是什么?
    1. T(1)的执行过程中。数据库状态尚未迁移,读到的i=0
    2. T(1)执行完毕,T(2)的执行过程中,数据库状态迁移至C(1),读到的i=1

    不知道有没有回到LZ的问题。

    原子性:无论一个事务里有多少执行步骤,这所有的步骤合起来是一个最小的执行单元,要么不做,要么全做,不存在只做到一半情况。比如银行转账,转出跟转入这两个包含在一个事务里的动作就是原子的。要么不转出也不转入,转出了就要转入。

    一致性:事务执行前与执行后数据内在的逻辑始终是成立的。比如转账前与转账后两人存款的总和始终不变。

    隔离性:虽说事务是原子的,要么不做,要么全做,不存在做一半的情况。但是从代码实现上来说,事务里的步骤还是一步一步执行的,还是存在事务做到一半的情况。比如转账,代码怎么写?就两行代码,是先转出扣钱,再转入加钱。两行代码中间,也就是转出之后,转入之前,此时数据是不一致的。那怎样始终保证数据一致?那就用一个类似自欺欺人的办法,让转账这个事务在完成之前对别人都不可见,事务完成之前别人看到的都是转账前的状态,看不到转账步骤中间不一致的状态,所谓”隔离”。

    持久性:事务做完了就是做完了,就生效了。就像钱转给别人后当前这比转账交易就结束了,不可能再倒回来。

    举个反例就清楚了:A向B转账100元,操作1:A账号减去100;操作2:B账号加上100,执行操作1后,进程中断,操作2没有执行,但是A的账户少了100元,B又没加上100元。从一个一致性状态到了一个不一致的状态。如果不能保证数据的一致性,也就是说操作结果不准确,那该操作就无意义了。为了保证一个事务不受其他事务的影响,一般通过设置事务的隔离级别和回滚机制保驾护航。关于事务的隔离级别:数据库中隔离性的四种级别详解与例子-争取一文全懂 - 知乎专栏

    自己的理解:

    一致性:同生共死。

    展开全文
  • ElasticSearch教程——数据一致性

    千次阅读 2018-09-28 16:53:51
    一致性概念 在分布式环境下,一致性指的是多个数据副本是否能保持一致的特性。 在一致性的条件下,系统在执行数据更新操作之后能够从一致性状态转移到另一个一致性状态。 对系统的一个数据更新成功之后,如果所有...
  • Oracle 事务ACID基本概念(原子性、一致性、隔离性、持久性)
  • 1,一致性协议 两阶段提交协议与Raft协议、Paxos协议 ①两阶段提交协议 在分布式系统中,每个节点虽然可以知晓自己的操作时成功或者失败,却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时,为了...
  • 关于事务的一致性,《数据库系统概念》中是这样描述的 第二段说的三个特性是指原子性、隔离性、持久性。 就算这样,相信大家也是懵懵的,我也是,所以才会写下这篇博客。 看到别的博客说,一致性是事务的最终...
  • 一致性成本和非一致性成本

    千次阅读 2020-08-25 09:59:50
    对于质量成本中的一致性成本与非一致性成本的区别。一图看懂
  • 分布式哈希和一致性哈希是分布式存储和p2p网络中说的比较多的两个概念了。介绍的论文很多,这里做一个入门性质的介绍。  分布式哈希(DHT)  两个key point:每个节点只维护一部分路由;每个节点只存储一部分数据...
  • Oracle 概念(Oracle 10.2)13、数据一致性和并发性这一章描述了Oracle如何维护多用户数据库环境中的数据一致性问题。本章包含下列主题:u 多用户环境中的数据并发性和一致性介绍u Oracle如何管理数据并发性和...
  • 浅析数据一致性

    万次阅读 2016-02-19 15:27:38
    什么是数据一致性?  在数据有多分副本的情况下,如果网络、服务器或者软件出现故障,会导致部分副本写入成功,部分副本写入失败。这就造成各个副本之间的数据不一致,数据内容冲突。 实践中,导致数据不一致的情况...
  • 日常开发中并发与一致性的一些坑

    千次阅读 2019-08-02 23:52:40
    前言列举日常工作开发中最容易犯的并发错误,并基于这些错误,跟大家聊聊并发与一致性。并发与一致性概念并发与并行有什么区别?并发: 是指同一个时间段内多个任务同时都在执行,并...
  • 总线矩阵:业务过程和维度的交点; 一致性维度:同一集市的维度表,内容相同或包含; 一致性事实:不同集市的同一事实,需保证口径一致,单位统一。
  • ZooKeeper能保证任何时刻读到的数据绝对一致吗? Zookeeper的特点就是,分布式,高可用,...也就是说可用性和一致性是Zookeeper的关键特性,作为一个消息的中间商,做了一个可靠的信息传递和存储的角色。 但是了解下ZooKeep
  • 分布式系统的一致性问题(汇总)

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

    千次阅读 2019-05-18 18:35:13
    一致性hash算法是什么? 一致性hash算法,是麻省理工学院1997年提出的一种算法,目前主要应用于分布式缓存当中。 一致性hash算法可以有效地解决分布式存储结构下动态增加和删除节点所带来的问题。 在Memcached、Key-...
  • NoSQL一致性分析

    千次阅读 2016-10-18 17:09:08
    1. 什么是数据库一致性数据库一致性与事务ACID特性中的一致性不同,或者可以说ACID中的一致性是维护数据库一致性的一个子集,我们可以简单把数据库一致性理解为正确性或完整性,用来保证关联数据之间的逻辑关系是否...
  • 分布式一致性hash算法

    千次阅读 2018-01-01 11:44:40
    写在前面  在学习Redis的集群内容时,看到这么一句话:Redis并没有使用一致性hash算法,而是引入哈希槽的概念。而分布式缓存Memcached则是使用分布式一致性hash算法来实现分布式存储。所以就专门学习了一下什么是...
  • 一致性锁定读 与 一致性非锁定读 产生的原因 在mysql数据库中,有一个行锁的概念。行锁有两种类型:共享锁(s),排它锁(x);x锁和s锁是不能互相兼容的,而s锁与s锁是可以互相兼容的;在mysql的设计中,在写操作的...
  • Redis集群的数据一致性

    万次阅读 2019-04-11 16:54:54
    Redis 集群没有使用一致性hash, 而是引入了哈希槽的概念。 Reds 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个节点负责一部分hash槽。这种结构很容易添加或者删除节点,并且...
  • 分布式系统基本概念 异常类型 1 服务器down机(随时发生、内存数据丢失(因此需要考虑数据持久化)、down机重启之后要恢复内存信息) 2 网络异常(消息丢失、消息乱序(UDP)或者网络包数据错误...一致性 副本是分
  • Raft 一致性算法论文

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

    万次阅读 2019-04-11 16:02:45
    在分布式系统中,分布式一致性是一个非常重要的概念,它是指分布式系统的各个服务器都保持一个统一的状态(数据)。但是在分布式系统中,通常由于网络,系统状态等原因会导致某些服务不可用或者不可靠。这就需要一种...
  • 最终一致性

    万次阅读 2012-05-14 22:11:45
    在全球范围构建可靠的分布式系统,需要在一致性和可用性之间进行权衡。   最终一致性 Eventually Consistent   作者: Werner Vogels Werner Vogels is vice president and chieftechnology officer at ...
  • 分布式系统可用性与一致性

    千次阅读 2017-06-23 09:55:27
    可用性(Availability)和一致性(Consistency)是分布式系统的基本问题,先有著名的CAP理论定义过分布式环境下二者不可兼得的关系,又有神秘的Paxos协议号称是史上最简单的分布式系统一致性算法并获得图灵奖,再有...
  • 浅谈数仓一致性维度

    千次阅读 2020-11-20 07:00:00
    1、一致性维度的概念 维度建模的数据仓库中,有一个概念叫Conformed Dimension,中文一般翻译为“一致性维度”。一致性维度是Kimball的多维体系结构中的三个关键性概念之...
  • springboot 怎么保证数据读写一致性

    千次阅读 2019-08-27 18:21:45
    springboot 怎么保证数据读写一致性,springboot 怎么保证数据读写一致性,springboot 怎么保证数据读写一致性,springboot 怎么保证数据读写一致性 , 除了tranctional注解,还有什么方式吗 ...
  • 副本( replica/copy)指在分布式系统中为数据或服务提供的冗余。分为数据副本和服务副本,对于数据副本指在不同的节点上持久化同一份数据,当出现某一个节点的存储的数据丢失时,可以从副本上读...副本的一致性:分布式

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 522,610
精华内容 209,044
关键字:

一致性的概念