CAP+Base初步了解

    说到分布式就一定要了解CAP原理，那么什么是CAP原理呢？

1.CAP原理是什么？
C（Consistency ）强一致性：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
A（Availablity ）可用性： 在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性），简单来说，就是网站不能处于一种不能使用的状态

P（Partition-torlerance ）分区容忍性： 以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性，分区容错性这三个需求，最多只能同时较好的满足两个。但是由于当前的网络肯定会出现延迟丢包等问题，因此我们必须要满足分区容错性，只能在强一致性和可用性之间权衡

因此，根据CAP原理将nosql数据库分成了满足CA原则，满足CP原则和满足AP原则三大类
CA-单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大 ,传统的数据库都是满足CA原则的
CP-满足一致性，分区容忍性的系统，通常性能不是特别高 ，是大多数网站结构的选择
AP-满足可用性，分区容忍性的系统，通常可能对一致性要求低一些  ，Mongodb、Redis等则是满足了AP原则

因此，在分布式架构时必须要做出取舍。
当然对于，CAP原理，也有好多IT工作者对此提出了质疑，大家可以看一下纯粹的码农的文章——CAP原理

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

1.数据库事物一致性需求

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

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

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

    在这情况下，就有了“读己之所写”一致性这个概念。比方说，我在朋友圈发了一条动态，首先要保证自己能看到，然后朋友圈的小伙伴们可能会在几秒或者十几秒时候也能看到这条动态，这种情况下，满足的是最终一致性，于是就有了BASE理论

那，什么是BASE理论？
    BASE理论就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。

BASE其实是下面三个小术语的缩写：
       1.基本可用（Basically Available）
        指分布式系统在出现故障的时候，允许损失部分可用性，保证核心可用。但不等价于不可用。比如：搜索引擎0.5秒返回查询结果，但由于故障，2秒响应查询结果；网页访问过大时，部分用户提供降级服务等。
       2.软状态（Soft state）

       软状态是指允许系统存在中间状态，并且该中间状态不会影响系统整体可用性。即允许系统在不同节点间副本同步的时候存在延时 
       3.最终一致（Eventually consistent）

       系统中的所有数据副本经过一定时间后，最终能够达到一致的状态，不需要实时保证系统数据的强一致性。最终一致性是弱一致性的一种特殊情况

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

关于分布式和集群

简单来说：

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

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