CAP原则 (阿里)

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

 

CAP原则又称CAP定理，指的是在一个 分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

一致性（C）：在 分布式系统中的全部数据备份，在同一时刻是否一样的值。（等同于全部节点访问同一份最新的数据副本）

可用性（A）：在集群中一部分节点故障后， 集群总体是否还能响应 客户端的读写请求。（对数据更新具有高可用性）

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

CAP原则的精髓就是要么AP，要么CP，要么AC，可是不存在CAP。若是在某个分布式系统中数据无副本， 那么系统必然知足强一致性条件， 由于只有独一数据，不会出现数据不一致的状况，此时C和P两要素具有，可是若是系统发生了网络分区情况或者宕机，必然致使某些数据不能够访问，此时可用性条件就不能被知足，即在此状况下得到了CP系统，可是CAP不可同时知足。必然致使某些数据不能够访问，此时可用性条件就不能被知足，即在此状况下得到了CP系统，可是CAP不可同时知足  [1] 。

所以在进行分布式架构设计时，必须作出取舍。当前通常是经过分布式缓存中各节点的最终一致性来提升系统的性能，经过使用多节点之间的数据异步复制技术来实现集群化的数据一致性。一般使用相似 memcached 之类的 NOSQL 做为实现手段。虽然 memcached 也能够是分布式集群环境的，可是对于一份数据来讲，它老是存储在某一台 memcached 服务器上。若是发生网络故障或是服务器死机，则存储在这台服务器上的全部数据都将不可访问。因为数据是存储在内存中的，重启 服务器，将致使数据所有丢失。固然也能够本身实现一套机制，用来在分布式 memcached 之间进行数据的同步和持久化，可是实现难度是很是大的  [2]  。

可用的抉择

编辑

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而因为网络硬件确定会出现延迟丢包等问题，因此分区容错性是咱们必须须要实现的。因此咱们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。对于web2.0网站来讲，关系数据库的不少主要特性却每每无用武之地。

1. 数据库事务一致性需求
   　　不少web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求并不高。容许实现最终一致性。
2. 数据库的写实时性和读实时性需求
   　　对关系数据库来讲，插入一条数据以后马上查询，是确定能够读出来这条数据的，可是对于不少web应用来讲，并不要求这么高的实时性，比方说发一条消息之 后，过几秒乃至十几秒以后，个人订阅者才看到这条动态是彻底能够接受的。
3. 对复杂的SQL查询，特别是多表关联查询的需求
   　　任何大数据量的web系统，都很是忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，特别是SNS类型的网站，从需求以及产品设计角 度，就避免了这种状况的产生。每每更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

与NoSQL的关系

编辑

传统的关系型数据库在功能支持上一般很宽泛，从简单的键值查询，到复杂的多表联合查询再到事务机制的支持。而与之不一样的是，NoSQL系统一般注重性能和扩展性，而非事务机制（事务就是强一致性的体现）。
　　传统的SQL数据库的事务一般都是支持ACID的强事务机制。A表明原子性，即在事务中执行多个操做是原子性的，要么事务中的操做所有执行，要么一个都不执行；C表明一致性，即保证进行事务的过程当中整个数据库的状态是一致的，不会出现数据花掉的状况；I表明隔离性，即两个事务不会相互影响，覆盖彼此数据等；D表示持久化，即事务一旦完成，那么数据应该是被写到安全的，持久化存储的设备上（好比磁盘）。
　　NoSQL系统仅提供对行级别的原子性保证，也就是说同时对同一个Key下的数据进行的两个操做，在实际执行的时候是会串行的执行，保证了每个Key-Value对不会被破坏。

与BASE的关系

编辑

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写。

BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即便没法作到强一致性（Strong consistency），但每一个应用均可以根据自身的业务特色，采用适当的方式来使系统达到最终一致性（Eventual consistency）。接下来咱们着重对BASE中的三要素进行详细讲解。基本可用：指分布式系统在出现不可预知故障的时候，容许损失部分可用性。

注意，这毫不等价于系统不可用，如下两个就是“基本可用”的典型例子：

响应时间上的损失：正常状况下，一个在线搜索引擎须要0.5秒内返回给用户相应的查询结果，但因为出现异常（好比系统部分机房发生断电或断网故障），查询结果的响应时间增长到了1~2秒。

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

弱状态：也称为软状态，和硬状态相对，是指容许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的总体可用性，即容许系统在不一样节点的数据副本之间进行数据同步的过程存在延时。

最终一致性：强调的是系统中全部的数据副本，在通过一段时间的同步后，最终可以达到一个一致的状态。所以，最终一致性的本质是须要系统保证最终数据可以达到一致，而不须要实时保证系统数据的强一致性。

分布式系统

编辑

分布式系统（distributed system）是创建在网络之上的软件系统。正是由于软件的特性，因此分布式系统具备高度的内聚性和透明性。所以，网络和分布式系统之间的区别更多的在于高层软件（特别是操做系统），而不是硬件。在一个分布式系统中，一组独立的计算机展示给用户的是一个统一的总体，就好像是一个系统似的。系统拥有多种通用的物理和逻辑资源，能够动态的分配任务，分散的物理和逻辑资源经过计算机网络实现信息交换。系统中存在一个以全局的方式管理计算机资源的分布式操做系统。一般，对用户来讲，分布式系统只有一个模型或范型。在操做系统之上有一层软件中间件（middleware）负责实现这个模型。一个著名的分布式系统的例子是万维网（World Wide Web），在万维网中，全部的一切看起来就好像是一个文档（Web页面）同样。

在计算机网络中，这种统一性、模型以及其中的软件都不存在。用户看到的是实际的机器，计算机网络并无使这些机器看起来是统一的。若是这些机器有不一样的硬件或者不一样的操做系统，那么，这些差别对于用户来讲都是彻底可见的。若是一个用户但愿在一台远程机器上运行一个程序，那么，他必须登录到远程机器上，而后在那台机器上运行该程序。