分布式数据一致性和CAP理论、BASE理论

74 阅读 0 评论 49 点赞

我是靠谱客的博主迷人黑猫，最近开发中收集的这篇文章主要介绍分布式数据一致性和CAP理论、BASE理论，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

现在很多的系统都是采用分布式架构，在分布式系统中需要解决的就是数据的复制，例如节点之间的复制，读写分离之间的复制（之前公司的网站采用的就是订单的写和读是分开的不再一个数据库中，这样的优点就是用户可以快速下单，缺点就是对订单的后续操作会有延迟）

简单讲：数据一致性就是指在对一个副本数据进行更新的时候必须确保能够更新其他的副本，否则不同副本之间的数据将会导致不一致

一致性级别：

强一致性：符合用户直觉要求系统写入什么读出来什么，用户体验较好但实现起来对系统的性能影响大

弱一致性：保证某个级别时间后，数据能够达成一致

最终一致性：是弱一致性的一个特例，业界推崇的一个

CAP 理论：

Consistency(一致性)

对某个指定客户端来说读操作能够返回最新的写的结果

Avaliability(可用性)

非故障的节点在合理的的时间内返回合理的响应（不是错误或者超时的响应）

Partition Tolerance(分区容错性)

当网络出现分区后系统能够继续履行职责（返回正确的结果）

CAP理论：

在一个分布式系统（指相互连接并且共享数据的节点的集合）中，当涉及到读写的操作时，只能保证一致性，可用性，

分区容错性三者中的两者，另外一个必须被牺牲

CAP细节：

CAP关注的颗粒度是数据，而不是整个系统

比如用户的账号数据（ID和密码）和用户信息数据（昵称、兴趣、爱好等），账号数据会选择CP而信息数据会选择AP。所以在CAP落地实践时，我们要按照业务数据的不同进行分类，而不是一个系统用一个策略

CAP是忽略网络延迟的

网络延迟是不可避免的，如果业务上必须保持严格的一致性只能单点写入

正常运行情况下，不存在AP和CP的选择，可以同时满足CA

理论上说的取舍是当网络分区（P）发生的时候我们要对（A）和（C）进行取舍，如果正常下网络没有发生分区，也就是（P）不存在的时候，我们还是要保证C和A的

放弃并不等于什么都不做，需要为分区恢复后做准备

在系统正常运行中一般的系统都会保证99.99%的可用性，所以发生网络分区的时候是非常少的我们可以在分区期间做一些操作，分区故障消除后，完成数据达到CA状态

BASE理论

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。接下来看一下BASE中的三要素：

1、基本可用

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性----注意，这绝不等价于系统不可用。比如：

（1）响应时间上的损失。正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒

（2）系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面

2、软状态

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

3、最终一致性

最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

总的来说，BASE理论面向的是大型高可用可扩展的分布式系统，和传统的事物ACID特性是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性和BASE理论往往又会结合在一起。

参考：《从零开始学架构》

https://www.cnblogs.com/szlbm/p/5588543.html