作者GoldenDB·2020-03-16 14:37

产品经理·中兴通讯

GoldenDB在CAP上的取舍

字数 3426阅读 4790评论 0赞 0

说到这个问题，我们必须要重新的再回顾一下CAP的基本概念。

# CAP基本概念
**一致性**（:在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一直的状态。无论业务怎么访问同一个值，只要系统能返回，总能得到一样的值，如果不能保证一致性，那么就不要返回。
**可用性**（：可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。这里的重点是"有限时间内"和"返回结果"。值得一提的是，对可用性很多人都会有一个误区，认为数值正确系统才是可用的，实际上可用性只是强调了返回值，只要能返回，不管值是否正确，系统都是可用的。这一点，和我们通常上说的可用可能是有一点区别。

**分区容错性**（：分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。我们总在说分区在分布式系统中是不可避免的，原因在于通讯总会有超期的情况。反之：如果没有发生超期的情况，P就是不存在，不需要在CA中做出选择。说的直白点，就是通讯好的时候，CA是可以兼顾的，并不需要2选1.

# CAP取舍的典型场景

既然一个分布式系统无法同时满足一致性、可用性、分区容错性三个特点，所以我们就需要抛弃一样。

那么我们来看看一下以下这些场景，都是抛弃了哪一样。

**场景1**：分布式通讯良好，没有超时的情况。

**场景2**：主节点等于5，从节点等于3。进程A访问主节点得到5，进程B访问从节点得到3.

**场景3**：主节点等于5，从节点等于3。进程A在访问主节点的时候，访问出错，没有得到任何值。

**场景4**：主节点等于5，从节点等于3。进程A访问主节点得到5，进程B在访问从节点的时候，系统发现主从节点不一致，然后取了主节点的值5进行了返回。
![](/home/attachment/202003/16/1237277_158434047833744.png)

现在公布答案，

**场景1**：刚才说了通讯良好的时候，并未出现P，此时CA可以兼顾，因此，系统满足CA。

**场景2**：虽然说进程B访问到了错误的值，但是根据概念，此时系统是可用的，因此是AP。

**场景3**：也很简单，出现了P，系统不可用了，因此系统状态是CP.

**场景4**：这是我重点想说的场景，此时出现了分区，我们说存在P；AB进程都可以返回值，因此A也满足，与此同时，我们发现AB进程返回的值还都是一致的，因此C也是满足的。矛盾就出现了，不是一直在说CAP不能同时满足吗？

我认为，此时我们其实是放弃了P，虽然说很明显此时主从节点出现了分区，但是系统已经发现了从节点问题，取消了他的读权限，客户端无法从从节点读到3的取值。换句话说，在没有恢复正常之前，从节点已经被放弃了，系统只有主节点可以读写，此时的系统，更像是一个单机数据库+备份节点（不可读写）。因此，我不认为此时存在分期的情况，系统只是AC。

进一步的，如果系统存在着一主多从的情况，而从节点的功能只是一个备胎，应用不会在从节点进行读或者写，那么此时此刻，大家觉得这个系统是CAP是如何进行取舍的？

CA:放弃分区容错性，加强一致性和可用性，其实就是传统的单机数据库，如果读写都是主节点，即使有很多从节点，我认为这也是CA.

AP:放弃一致性（这里说的是强一致性），追求分区容错性和可用性，这是很多分布式系统设计的选择，特别是很多NOSQL的系统，是这样选择。

CP:放弃可用性，追求一致性和可用性，这会导致系统不可访问。

对于GoldenDB来说，并没有简单的做三选一的选择，GoldenDB在不同的状态，对CAP的选择各不相同。

# 应用一致性的要求

不同的应用对数据库的一致性的要求是不一样的，这里举几个例子。

**场景1**：AB同时在买最后一张火车票，分布式构架的情况下，AB是否可以同时买到？

**场景2**：网购的库存量，这个值是否是一个准确值。

有些系统，既要快速地响应用户，同时还要保证系统的数据对于任意客户端都是真实可靠的，就像火车站售票系统。

有些系统，虽然向用户展示了一些可以说是"错误"的数据，但是在整个系统使用过程中，一定会在某一个流程上对系统数据进行准确无误的检查，从而避免用户发生不必要的损失，就像网购系统。

对于金融场景，特别是银行核心交易的场景，更加接近于火车票的场景，更加的强调实时一致性。

# 一致性的级别

总得来说，我们无法找到一种能够满足分布式系统所有系统属性的分布式一致性解决方案。因此，如何既保证数据的一致性，同时又不影响系统运行的性能，是每一个分布式系统都需要重点考虑和权衡的。于是，一致性级别由此诞生：

**1、强一致性**

这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大。

**2、弱一致性**

这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不久承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态

**3、最终一致性**

最终一致性是弱一致性的一个特例，系统会保证在一定时间内，能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来，是因为它是弱一致性中非常推崇的一种一致性模型，也是业界在大型分布式系统的数据一致性上比较推崇的模型。

# 事务一致性

我们说分布式数据库存在两种一致性，数据一致性和事务一致性。

那么什么是事务一致性呢？

我们先来看什么是数据一致性，一个分布式系统假如说只有2个节点，一主A一从A’，数据完全一样，这样的场景下对2个节点的读写，就是我们讨论的是数据一致性的范畴。

如果我们对一个数据库进行水平的切片，男士的数据放一个节点A,女士的数据放一个节点B。

同时，还有一个A’节点作为A的从节点，B’节点作为B的从节点。那么A和A’之间的关系，我们说是数据一致性的范畴，如果有一个男士x向一个女士y转账，在转账的过程中，2个账户总和的一致性，我们说这是事务的一致性。很明显，如果我们不做任何处理，xy的总和在过程中一定会发生变化，得到错误的值。

所以，数据一致性说的是发生在主从复期间的事。

事务一致性说的是发生在水平分片交易发生的期间的事情。这是两个维度的一致性。

GoldDB和其他数据库最大的区别就在全局事务的强一致性，在事务的处理过程中增加了全局一致ID（gtid）进行事务的锁定和跟踪，保证事务全体提交或者回滚，而在事务提交过程中不允许读写（放弃可用性）。

# 读写分离

前面我们讨论过，在A和A’的场景下，如果读写都在A节点，而A’节点只是作为备份，这样的数据库严格来说只能算是一个单机数据库。

实际上，业界大多数的数据库都不会采用双写的方案，一般对A’进行写操作。

如果在某种场景下，允许对A’进行读的操作，我们说这样的场景就叫做读写分离。读写分离可以提升读的性能，比如一主三备的情况下，可以有4个节点同时处理读操作。但是增加了从节点不一致数据的可能性。

实际上无论是Golden或者还是OB或者还是别的数据库，默认的模式都是在A进行读写，大家都会宣称自己是强一致性，实际上市数据的强一致性。当然，这些系统肯定也是支持读写分离配置的。这并不是主要的差别所在。

# GoldenDB对CAP的选择

以上我们介绍了不少场景，针对这些不同的场景，来看看GoldenDB对CAP的选择。
![](/home/attachment/202003/16/1237277_158434050180655.png)

# 小结

CAP理论明确了分布式系统的局限性，也即在分区的情况下，可用性和一致性只能保证一个。目前一些常见的互联网分布式数据库都是优先满足可用性，对于我们的系统来说，为了满足金融交易类场景，一致性是第一选择。GoldenDB通过高低水位解决、快同步、分组技术缩短事务提交时间，减少事务提交时，相关数据不可用的时间窗口。

GoldenDB

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

GoldenDB在CAP上的取舍

添加新评论0 条评论

作者其他文章

相关文章

相关问题

相关资料