6.3CAP 原理与 NoSQL 数据库架构

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）:系统中的所有副本，经过一段时间的同步后，最终能够达到一个一致的状态， 因此最终一致性的本质是需要系统保证数据能够达到一致，而不需要实时保证系统数据的强一致性。