7.1.2 NoSQL数据库概述-2在线视频

第一个CAP理论

首先我们来看一下

分布式事务和分布式数据库不一致的原因

还有分布式环境底下三个核心的一个需求

一个CAP里的一个核心

这个是我们在c区理论的四个方面

第一个我们分布式事务

分布式事务

实际上是一个分布式的操作序列

被操作的数据可以分布在不同节点上

分布式事务也要求满足四个特征

第一个特征 原子性

一致性

隔离性

持久性

一致性

实际上要求我们所有的操作结果

在事务处理前和事务处理后

整个数据库时保存一个一致的状态

我们的原子性要求数据库的操作

实际上只有两种状态

第一种是完成

第二种是什么都没做

隔离性 表示我们这个数据

的事物是独立完成的

持久性 在数据库操作完成以后

整个数据保持一致性

在分布式环境底下

在我们的因为网络服务器软件都可能有故障

所以说就会出现数据的不一致性

我们看一下不一致性的原因有哪些

第一个我们数据项在分布式环境底下

有多个副本如何保证多个副本数据的一致性

第二个

单点网络故障如何通知所有的节点

某一个节点出故障了

我们的事务是否还继续下去

第三点

通讯网络的故障

在数据的通讯过程中出错以后

如何来保证事务在正常的进行

第四点

在我们分布式提交的过程

分布式提交可以有两阶段提交

三阶段提交

不同的阶段都可能发生问题

都可能会影响数据的一致性

下面我们看一下分布式数据

三个核心的需求

CAP对应一致性

可用性和分区容忍性

一致性

他的要求是我们分布式系统

存在很多个备份

数据存在多份数据

要求我们的多份数据

在事务完成之后

都要保持一致性的结果

每个备份的数据都必须是一致的

可用性

要求我们客户在进行访问的时间

在规定的时间必须得到响应

分区容忍性

如果系统只在一个节点运行

这个事要不成功

如果一个事务在多个节点运行

整个系统

就存在着所有的节点必须反馈

是否可以一个节点反馈

另外一个节点等到

在某一个时间再进行同步

这个就叫分区容忍性

好

有了这些我们来看一下CAP理论的核心

一个分布式系统不可能同时

很好地满足我们的一致性

可用性和分区容错性这三个需求

最多只能同时满足两个

第一个是满足一致性和可用性的系统

第二个是CP

满足一致性和分区容忍性的系统

第三个AP

满足可用性和分区容忍性的系统

这三点是我们CAP的核心

下面我们通过一个例子来体现一下

我们CAP的基本思想

这个例子里面

两个网络节点共享一个数据V

初始值为V0

有两个算法

算法A在节点1

算法B在结点2

算法A要求我们V写入新的值

算法B读出V的新值

整个算法有三个步骤

第一 算法A写入新的V1

节点1发出信息V1给节点2

算法B 读出V1并进行操作

三个步骤来完成这个操作

可能

我们分析一下节点1

和节点2数据不一样的原因有哪些

我们看一下

如果网络断开

节点1和节点2包含的数据

就是不一致的

第二个方面

如果网络的协议是异步消息

可能出现延迟

在延迟的这个过程中

可能会也是两个数据是不一致的

第三个

如果网络是同步消息的话

同样等待的问题

等待超时问题也会出现

使两个结果不一致

所以说CAP思想

让A B都是高可用的

并且让所有的节点

所有的网络分区

都在面临这们的问题情况下

使V值保持一致

所以说我们CAP的目的

就是为了探索不同应用的一致性

和可用性之间的一个平衡

在网络会和其他原因的情况下

我们通过牺牲一定的一致性

来换取更高的性能和扩展性

在有分隔发生

选择可用性集中关注分隔的恢复

需要分隔前后中期的处理策略

及合适的补偿机制

我们要决定选择哪种方式

我们可以放弃P

也放弃分区容忍
我们可以放弃P

也放弃分区容忍

放弃A

放弃一致性

放弃C

放弃可用性

实际上我们下面的一个选择

就是我们BASE

BASE就是基本可用

就是系统能够基本运行

能够一直提供服务

第二个是软状态

也叫柔性事务

软状态可以理解为无连接的

而硬状态是面向连接的

就是系统不要求一直保持强一致性

第三个是最终一致性

系统在某个时刻达到最终一致性

所以说我们BASE的定义

是CAP中的AP的衍生

在分布式环境底下BASE是数据的属性

强调基本可用

按功能来划分数据库

下面来看一下BASE的特点

我们在我们的事务里头保证事务的

ACID特性

就是原子性 一致性 隔离性和持久性

但是在我们用BASE采取悲观保守的方法

我们特点是弱一致性

和可用性优先

采用乐观的方法

适应变化并且简单快捷

对数据不断增长的系统

大数据环境下系统的可用性

及分区容忍性的要求要高于强一致性

所以说我们就提出了最终一致性的一个模型

我们一种是强一致性

要求无论更新在哪一个版本上执行

之后所有的操作都必须获得最新的数据

弱一致性

用户读到某个数据对系统特定数据的更新

需要一段时间

称这段时间为不一致性窗口

最终一致性

是弱一次性的一个特例

保证用户最终能够读到某操作

对数据特定的数据的更新

下面最终一致性的两个角度

一个角度是从客户端来关注最终的一致性

让客户感觉到我的数值的数据最终都是对的

另一个是从服务器的角度来关注

更新如何复制分布到整个系统里头

保证所有的数据在服务器上是一致的

从服务器的角度来关注整个系统的数据

是一致性的

最终保证整个数据在服务器上所有的系统

最终实现更新后的一致性

最终一致性的模型我们有五个

我们看一下有因果一致性

这种保证无因果关系的数据

读写不保证一致性

第二个是读已之所写一致性

用户自己总能读到更新后的数据

第三个会话一致性

把读取存储系统的进程限制在一个会话内

第四个单调一致性

是后续的操作都不会返回

到数据之前的值

第五个单调写一致性

来自同一个进程的更新操作

按照时间顺序

也叫做时间轴一致性

我们最终一致性

实际上来保证一致性和可用性的

选择的一个问题

很多的web实时系统对读一致性的要求很高

有些场合对写一致性的要求并不高

所以我们允许实现最终一致性

很多的web系统并不要求高的实时性

所以像我们的社交网络类型的网站

这样子我们就可以

通过弱一致性

最终一致性来保证系统的功能

还有海量大数据的存储管理

需要对我们的数据进行关系数据库进行补充

最终我们这些

来总结一下我们这些所有的CAP理论

和我们的BASE理论

是作为我们NOSQL的一个基础

所以NOSQL基础就是要遵从

CAP的理论高性能 高可用性和高扩展性

还有分布式计算 低成本

半结构化数据没有复杂关系

最后没有标准化

有限的查询能力

本节学习到此为止