分布式系统数据一致性

最新推荐文章于 2024-08-25 22:02:44 发布

zbuger

最新推荐文章于 2024-08-25 22:02:44 发布

阅读量517

点赞数

分类专栏：分布式 java javaweb jvm java

java 同时被 3 个专栏收录

82 篇文章 0 订阅

订阅专栏

jvm java

44 篇文章 0 订阅

订阅专栏

javaweb

41 篇文章 0 订阅

订阅专栏

在前面三篇文章中，介绍了关于分布式系统中数据一致性的问题，这一篇主要介绍CAP定理以及自己对CAP定理的了解。

CAP定理是2000年，由 Eric Brewer 提出来的

Brewer认为在分布式的环境下设计和部署系统时，有3个核心的需求，以一种特殊的关系存在。这里的分布式系统说的是在物理上分布的系统，比如我们常见的web系统。

这3个核心的需求是：Consistency，Availability和Partition Tolerance，赋予了该理论另外一个名字－ CAP。

Consistency：一致性，这个和数据库ACID的一致性类似，但这里关注的所有数据节点上的数据一致性和正确性，而数据库的ACID关注的是在在一个事务内，对数据的一些约束。

Availability：可用性，关注的在某个结点的数据是否可用，可以认为某一个节点的系统是否可用，通信故障除外。

Partition Tolerance：分区容忍性，是否可以对数据进行分区。这是考虑到性能和可伸缩性。

为什么不能完全保证这个三点了，个人觉得主要是因为一旦进行分区了，就说明了必须节点之间必须进行通信，涉及到通信，就无法确保在有限的时间内完成指定的行文，如果要求两个操作之间要完整的进行，因为涉及到通信，肯定存在某一个时刻只完成一部分的业务操作，在通信完成的这一段时间内，数据就是不一致性的。如果要求保证一致性，那么就必须在通信完成这一段时间内保护数据，使得任何访问这些数据的操作不可用。

如果想保证一致性和可用性，那么数据就不能够分区。一个简单的理解就是所有的数据就必须存放在一个数据库里面，不能进行数据库拆分。这个对于大数据量，高并发的互联网应用来说，是不可接受的。

我们可以拿一个简单的例子来说明：假设一个购物系统，卖家A和卖家B做了一笔交易100元，交易成功了，买家把钱给卖家。

这里面存在两张表的数据：Trade表Account表，涉及到三条数据Trade(100),Account A ,Account B

假设 trade表和account表在一个数据库，那么只需要使用数据库的事务，就可以保证一致性，同时不会影响可用性。但是随着交易量越来越大，我们可以考虑按照业务分库，把交易库和account库单独分开，这样就涉及到trade库和account库进行通信，也就是存在了分区，那么我们就不可能同时保证可用性和一致性。

我们假设初始状态

trade(buyer,seller,tradeNo,status) = trade(A,B,20121001,I)

account(accountNo,balance) = account(A,300)

account(accountNo,balance) = account(B,10)

在理想情况下，我们期望的状态是

trade(buyer,seller,tradeNo,status) = trade(A,B,20121001,S)

account(accountNo,balance) = account(A,200)

account(accountNo,balance) = account(B,110)

但是考虑到一些异常情况

假设在trade(20121001,S)更新完成之前，帐户A进行扣款之后，帐户A进行了另外一笔300款钱的交易，把钱消费了，那么就存在一个状态

trade(buyer,seller,tradeNo,status) = trade(A,B,20121001,S)

account(accountNo,balance) = account(A,0)

account(accountNo,balance) = account(B,10)

产生了数据不一致的状态

由于这个涉及到资金上的问题，对资金要求比较高，我们必须保证一致性，那么怎么办，只能在进行trade(A,B,20121001)交易的时候，对于任何A的后续交易请求trade(A,X,X)，必须等到A完成之后，才能够进行处理，也就是说在进行trade(A,B,20121001)的时候，Account(A)的数据是不可用的。

任何架构师在设计分布式的系统的时候，都必须在这三者之间进行取舍。首先就是是否选择分区，由于在一个数据分区内，根据数据库的ACID特性，是可以保证一致性的，不会存在可用性和一致性的问题，唯一需要考虑的就是性能问题。对于可用性和一致性，大多数应用就必须保证可用性，毕竟是互联网应用，牺牲了可用性，相当于间接的影响了用户体验，而唯一可以考虑就是一致性了。

牺牲一致性

对于牺牲一致性的情况最多的就是缓存和数据库的数据同步问题，我们把缓存看做一个数据分区节点，数据库看作另外一个节点，这两个节点之间的数据在任何时刻都无法保证一致性的。在web2.0这样的业务，开心网来举例子，访问一个用户的信息的时候，可以先访问缓存的数据，但是如果用户修改了自己的一些信息，首先修改的是数据库，然后在通知缓存进行更新，这段期间内就会导致的数据不一致，用户可能访问的是一个过期的缓存，而不是最新的数据。但是由于这些业务对一致性的要求比较低，不会带来太大的影响。