写点什么

6.3CAP 原理与 NoSQL 数据库架构

用户头像
张荣召
关注
发布于: 2020 年 11 月 01 日

1.CAP原理

问题: 分布式系统,可用性(A),一致性(C),分区耐受性(P)三者之间的关系?

解析: 一致性C(Consistency):数据一致性-每次读取的数据都应该是最近写入的数据或者返回一个错误

           (Every read receives the most recent write or an error),而不是过期数据。即数据一致性。



           可用性A(Available):每次请求都可以得到一个响应,而不是返回一个错误或者失去响应。不过这个响应不需要保证数据时最近写入的。(Every request receives (non-error) response,without the guarantee that it contains the most recent wirte).也就是说系统需要一直都是可以正常使用的,不会引起调用者异常。但是不保证响应的数据时最新的。



           分区耐受性P(Partition tolerance):因为网络原因,部分服务器节点之间消息丢失或者延迟了,系统依然应该是可以操作的 (The system continues to operate despite an arbitrary number of message being dropped (or delayed) by the network between nodes).分区耐受性在分布式系统中,是必然发生的。



原理:1.CAP:当网络分区失效发生的时候,我们要么取消操作,这样数据就是一致的,但是系统却不可用;要么继续写入,但是数据一致性得不到保证。

          2.对一个分区系统而言,网络失效一定会发生,也就是说,分区耐受性是必须要保证的,那么在可用性和一致性上就必须二选一。

          3.当网络分区失效,也就是网络不可用时,如果选择了一致性,系统就可能返回一个错误码或者干脆超时,即系统不可用;

             如果选择的可用性,那么系统总是可以返回一个数据,但是不保证这个数据时最新的。

          4.所以,关于CAP原理,更准确的说法,在分布式系统必须要满足分区耐受性的前提下,可用性和一致性无法同时满足。

2.CAP原理与数据一致性冲突

解析:三个服务器节点构成服务器集群----用户数据存储。三个服务器节点通过网络连接在一起。

          当网络失效(即分区耐受性P)发生时,节点A和节点B通讯失效;节点C宕机下线,节点A和节点C通信失效,节点B和节点C通信失效。

          1.客户端1发起更新操作:update item set price=75.00 where id=55;==>将数据写入节点B

                 ====>客户端2获取的结果select * from items where id=55;====>price=75.00

          2.客户端3发起更新操作:update item set price=99.00 where id=55;==>将数据写入节点A

                ====>客户端4获取的结果select * from items where id=55; ===>price=99.00

如果满足系统是可用的(数据更新操作都可以成功,数据访问操作都可以成功),系统都可以返回值,但是返回值是不一致的。

             ===>即当分区耐受性P发生时,如果保证可用性A,就无法满足一致性C。



            当网络失效(即分区耐受性P)发生时,节点A和节点B通讯失效;节点C宕机下线,节点A和节点C通信失效,节点B和节点C通信失效。

          1.客户端1发起更新操作:update item set price=75.00 where id=55;==>将数据写入节点B

             ====>客户端2获取的结果select * from items where id=55; ====>price=75.00

          2.客户端1更新了节点B,但是节点A和节点B通讯失效, 此时如果允许客户端3更新节点A,数据无法同步而造成不一致。

==>为了保证节点B和节点A数据的一致性,节点A被修改,A和B通讯失效,节点B不再对外提供服务。

       客户端3的更新操作,(A和B通讯失效)返回一个错误值或超时,即系统更新操作不可用。

       客户端4的读取操作(A和B通讯失效,一旦读取,数据不一致,返回一个错误值或超时),即系统读取操作不可用。

       ===>如果满足系统是数据一致性,系统操作不可用。

       ===>即当分区耐受性P发生时,如果保证一致性C,就无法满足可用性A。



3.最终一致性

互联网应用:关注点:分区耐受性,高可用。CAP中追求PA架构,数据的一致性要求降低,强一致性降低为最终一致性。

  

解析:0.原始状态:服务器1和服务器2,产品ID=55的价格=105.00。客户端B,C读取105.00

          1.客户端A更新操作后,产品ID=55的价格=99.0.  客户端B读取99.0.

          2.服务器1==(同步)==>服务器2, 同步期间,服务器2还没有得到最新的更新结果。

          3.客户端C的读取结果:id=55的产品的价格=105.00.

          4.同步完成:服务器1===>服务器2.最终数据达到一致。

          5.客户端C读取结果id=55产品价格=99.0.   客户端A和客户端C最终结果一致。

          ====>用户最终获取数据的一致性。

4.最终一致写冲突

简单冲突处理策略:根据时间戳,最后写入覆盖。



5.客户端冲突解决



解析:客户端解决冲突。节点A和节点B不知道数据逻辑,客户端获取数据后,发现有冲突,客户端做出判断和选择。

6.投票解决冲突(Cassandra)



7.Cassandra分布式架构

写:节点6计算,数据还应该写入那些服务器,然后向多个服务器扩散。

读:节点6计算,那些服务器有数据,从多个服务器读取数据。

投票获取最终数据。返回给用户。

实现最终返回给用户的数据是一致的。



但是集群中,数据可能是不一致的。(网络失效导致数据写入的不一致。)----符合CAP原理:在高可用的情况下,尽可能保证数据的一致性。

(对最终返回给用户结果的一致性,并不保证服务器集群中数据的一致性---网络失效时,数据写入可能不一致。)

8.Hbase架构

解析:Hbase 低层存储HFile: Hadoop分布式文件系统HDFS。  Hbase存储由Hadoop存储的。数据复制和高可用有Hadoop来支撑。

          Hbase焦点解决数据的分布式存储。可用性由HDFS来解决。

          HMaster:负责数据分片,路由选择。

          HRegionServer:真正的服务器实例。通过HRegionServer读写数据。

          HRegion:HRegionServer内部多个逻辑分区。

读操作:应用程序读取数据(形式:key-value),HMaster根据key计算出目标HRegionServer。然后到目标HRegionServer服务器读取数据。

             对Key进行分区,key区段与HRegionServer有对应关系。

             如果HMaster宕机,无法通过Key选取HRegionServer。有多个主HMaster服务器保证高可用。

             多个HMaster如果一致对外提供服务?zookeeper。

Zookeeper:负责选择主HMaster。-----一段时间内,只有一个主服务器对外提供服务。



9.ACID  VS BASE  (酸------碱)

      ACID:

A原子性(Atomicity):事务要么全部完成,要么全部取消。如果事务崩溃,状态回到事务之前(事务回滚)。

      C一致性(Consistency):只有合法数据(依照关系约束和函数约束)才能写入数据库。

       I隔离性(Isolation):两个事务T1和T2同时运行,事务T1和T2最终结果是相同的,不管T1和T2谁先结束,隔离性主要依靠锁实现。

       D持久性(Duration):一旦事务提交,不管发生什么(崩溃或者出错),数据要保存在数据库中。

      BASE:

B基本可用(Basically Avaliable):系统出现不可预知故障时,允许损失部分可用性,如响应时间上的损失或者功能上的损失。

        S软状态(Soft Sate):允许系统中的数据存在中间状态,并认为该中间的状态的存在不会影响系统的整体可用性,即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

        E最终一致性(Eventually Consistent):系统中的所有副本,经过一段时间的同步后,最终能够达到一个一致的状态, 因此最终一致性的本质是需要系统保证数据能够达到一致,而不需要实时保证系统数据的强一致性



用户头像

张荣召

关注

还未添加个人签名 2018.05.02 加入

还未添加个人简介

评论

发布
暂无评论
6.3CAP原理与NoSQL数据库架构