Redis_NoSql分布式数据库CAP原理

　　前文简单介绍了NoSql数据库的四大分类以及常用的数据库技术，本文简单介绍分布式数据库CAP原理。

一、传统的CAID是什么

　　1. A（Atomicity）原子性：事务里的所有操作要么全部做完，要么都不做，事务成功的条件是事务中的所有操作都成功，只要有一个操作失败，整个事务失败，需要回滚。

　　2. C（Consistency）一致性：数据库要一直处于一致的状态，事务的运行不会改变数据库原本一致性的约束。

　　3. I（Isolation）隔离性：并发事务之间互不影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。

　　4. D（Durability）持久性：一旦事务提交以后，它所做的修改是永久性的保存在数据库上，即使出现宕机也不会丢失。

二、CAP是什么

　　1. C（Consistency）强一致性：任何一个读操作总是能读取到之前完成的写操作结果，也就是在分布式环境中，多点的数据是一致的。

　　2. A（Availability）可用性：每一个操作总是能够在确定的时间内返回，也就是系统随时都是可用的。

　　3. P（Partition tolerance）分区容忍性：在出现网络分区(比如断网)的情况下，分离的系统也能正常运行。

三、CAP的3进2

　　CAP理论的核心是：一个分布式系统不可能同时满足一致性，可用性和分区容忍性三个需求，最多只能较好的满足两个。因此根据CAP原理将NoSql数据库分成满足CA原则、满足CP原则和满足AP原则的三大类。

　　CA - 单点集群，满足一致性和可用性的系统，通常可扩展性上不太强大。传统Oracle数据库

　　CP - 满足一致性，分区容错的系统，通常性能不是特别高。大多数网站架构的选择

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

注意：分布式架构的时候必须做出取舍。一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。因此牺牲C换取P，这是目前分布式数据库产品的方向

　　CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。

　　一致性与可用性的决择

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

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

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

四、BASE是什么

　　BASH就是为了解决关系数据库一致性引起的问题而引起可用性降低而提出的解决方案。

　　基本可用（Basically Available）

　　软状态（Soft state）

　　最终一致（Eventually consistent）

　　它的思想是通过让系统放松对某一时刻数据一致性的要求来换取整个伸缩性和性能上的改观。为什么这么说呢，缘由就在于大型系统往往由于地域分布和极高性能要求，不能采用分布式事务来完成这些指标，想要获取这些指标，我们必须采用另外一种方式来完成，这里BASE就是解决这个问题的办法。

五、分布式+集群简介

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

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