在分布式数据库中CAP原理CAP+BASE

传统的ACID

A (Atomicity) 原子性

一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

C (Consistency) 一致性

事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。如果事务成功地完成，那么系统中所有变化将正确地应用，系统处于有效状态。如果在事务中出现错误，那么系统中的所有变化将自动地回滚，系统返回到原始状态。

I (Isolation) 隔离性

指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看到中间状态的数据。

D (Durability) 持久性

指的是只要事务成功结束，它对数据库所做的更新就必须永久保存下来。即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。

CAP

C:Consistency（强一致性）

A:Availability（可用性）

P:Partition tolerance（分区容错性）

CAP的3选2原则

CAP理论在分布式存储系统中,最多只能实现亮点.

现在存在的问题是:网络硬件会出现延迟丢包等问题,所有分区容忍行(分区容错性)是必须要实现的.因此我们只能在一致性(C)和可用性(A)之间权衡,**没有NoSQL系统能同时保证CAP这3点.

CA:传统Oracle数据库

AP:大多数网站架构的选择

CP:Redis.Mongodb

注意:分布式架构的时候必须做出取舍.

要在一致性(C)和可用性(P)之前取一个平衡点,现在大多数Web应用,其实并不需要强一致性.因此舍强一致性(C),取分区容错性(P),这是目前分布式数据库产品的方向.

一致性(C)与可用性(A)的决择

对于Web 2.0网站来说，关系数据库的很多主要特性却往往无用武之地

数据库事务一致性需求

　　很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低， 有些场合对写一致性要求并不高。允许实现最终一致性。

数据库的写实时性和读实时性需求

　　对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说发一条消息之 后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。

对复杂的SQL查询，特别是多表关联查询的需求

　　任何大数据量的Web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，特别是 SNS 类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三大类：

CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。

CP - 满足一致性，分区容忍必的系统，通常性能不是特别高。

AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。

BASE

BASE:为了解决关系数据库强一致性的问题而引起的可用性降低而提出的解决方案.

基本可用（Basically Available）

软状态（Soft state）

最终一致（Eventually consistent）

为什么使用BASE?

它的思想:是通过让系统减压,对某时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。原因就在于大型系统往往由于地域分布和极高性能的要求，不可能采用分布式事务来完成这些需求.

分布式+集群简介

分布式系统（distributed system）

由多台计算机和通信的软件组件通过计算机网络连接（本地网络或广域网）组成。分布式系统是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。分布式系统可以应用在在不同的平台上如：Pc、工作站、局域网和广域网上等。

简单来讲：

1. 分布式：不同的多台服务器上面部署不同的服务模块（工程），他们之间通过Rpc/Rmi之间通信和调用，对外提供服务和组内协作。

2. 集群：不同的多台服务器上面部署相同的服务模块，通过分布式软件进行统一的调度，对外提供服务和访问。