cap原则

CAP原则 分布式–CAP原则 CAP理论是指分布式系统架构中通常只能够满足CAP三个指标中的两个，而不能同时满足CAP三个指标。 C（Consistency）：一致性 一致性指的是All nodes see the same data at the same time，也就是说所有节点在同一时间看到的数据必须是一模一样的 ，比如足球比赛中，当比分发生了改变，客户端A看到的比分是1:0，而客户端B看到的比分还是0:0；又比如在银行系统中，通过微信进行银行卡转账，卡上余额从100变成了0，但是在支付宝中查看银行卡余额还是100，这显然就破坏了数据的一致性。 A（Avalilability）：可用性 可用性指的是Reads and writes always succeed，也就是说无论是读操作还是写操作，始终是成功的，也就是服务一直可用，不存在服务失败或者用户操作失败的情况 。比如说用户发起提现操作，过了会显示提现失败；在进行转账的时候提示了需要等2天后才能到账，显然就破坏了可用性，因为用户的一系列操作换来的是提现失败，转账延迟才能到账，而不是立马响应到账。 P（ Partition Toleranc）：分区容错性 分区容错性指all nodes look like one node，也就是说多个节点的运行看起来就像是一个节点在运行一样，一个节点宕机不可用，其他节点还可以正常运行

在弄清楚这个问题之前，我们先了解一下什么是分布式的CAP定理。 根据百度百科的定义，CAP定理又称CAP原则，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），最多只能同时三个特性中的两个，三者不可兼得。 一、CAP的定义 Consistency (一致性)： “all nodes see the same data at the same time”,即更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致，这就是分布式的一致性。一致性的问题在并发系统中不可避免，对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。 Availability (可用性): 可用性指“Reads and writes always succeed”，即服务一直可用，而且是正常响应时间。好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。 Partition Tolerance (分区容错性): 即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。 分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。 而由于当前的网络硬件肯定会出现延迟丢包等问题，所以 分区容忍性是我们必须需要实现的。 所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。 ======================================================================================================================= C:强一致性 A：高可用性 P：分布式容忍性 CA 传统Oracle数据库 AP 大多数网站架构的选择 CP Redis、Mongodb 注意：分布式架构的时候必须做出取舍。 一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。 因此牺牲C换取P，这是目前分布式数据库产品的方向 ======================================================================================================================= 一致性与可用性的决择 对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地 数据库事务一致性需求 　　很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，

关系型数据库与非关系型数据库及其特性： RDBMS(Relational Database Management System 关系型数据库) ：mysql/oracle/sqlServer等 ========》ACID特性 NOSQL(Not Only SQL 非关系型数据库)：redis/mongdb等 ========》 CAP特性 ACID：A(Atomicity)原子性、C(Consistency)一致性、I(Isolation)独立性、D(Durability)持久性 CAP：C(Consistency)强一致性、A(Availability)可用性、P(Partition tolerance)分区容错性 CAP三进二原则： 在任何一个分布式系统中都无法同时满足CAP，只能三个里面选择两个 CAP介绍及其对应产品： NoSQL CA：单点集群，满足一致性，可用性的系统，通常在扩展性上不太强大（产品：RDBMS） CP：满足一致性，分区容忍性的系统，通常性能不是特别高（产品：MongoDB/HBase/Redis） AP：满足可用性，分区容忍性的系统，通常可能对一致性要求更低一些（产品：CouchDB/Cassandra/DvnamoDB） CAP理论就是说在分布式系统中，最多只能实现上面两点；而由于当前的网络硬件肯定会出现延迟丢包问题，所以 分区容忍必须要实现

根据百度百科的定义，CAP定理又称CAP 原则 ，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），最多只能同时三个特性中的两个，三者不可兼得。 一、CAP的定义 Consistency (一致性)： “all nodes see the same data at the same time”,即更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致，这就是分布式的一致性。一致性的问题在并发系统中不可避免，对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。 Availability (可用性): 可用性指“Reads and writes always succeed”，即服务一直可用，而且是正常响应时间。好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。 Partition Tolerance (分区容错性): 即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。 分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了

在弄清楚这个问题之前，我们先了解一下什么是分布式的CAP定理。 根据百度百科的定义，CAP定理又称CAP原则，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），最多只能同时三个特性中的两个，三者不可兼得。 一、CAP的定义 Consistency (一致性)： “all nodes see the same data at the same time”,即更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致，这就是分布式的一致性。一致性的问题在并发系统中不可避免，对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。 Availability (可用性): 可用性指“Reads and writes always succeed”，即服务一直可用，而且是正常响应时间。好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。 Partition Tolerance (分区容错性): 即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。 分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体

历史优质文章： 可能是最漂亮的Spring事务管理详解 面试中关于Java虚拟机（jvm）的问题看这篇就够了 Java NIO 概览 分布式系统设计理念 分布式系统架构的第一原则是不要分布！这句话看似矛盾实则揭露了分布式系统的很多特征。 分布式系统的目标与要素 分布式系统的目标是提升系统的整体性能和吞吐量另外还要尽量保证分布式系统的容错性（假如增加10台服务器才达到单机运行效果2倍左右的性能，那么这个分布式系统就根本没有存在的意义）。 即使采用了分布式系统，我们也要尽力运用并发编程、高性能网络框架等等手段提升单机上的程序性能。 分布式系统设计两大思路：中心化和去中心化 1）中心化设计： 两个角色： 中心化的设计思想很简单，分布式集群中的节点机器按照角色分工，大体上分为两种角色： “领导” 和 “干活的” 角色职责： “领导”通常负责分发任务并监督“干活的”，发现谁太闲了，就想发设法地给其安排新任务，确保没有一个“干活的”能够偷懒，如果“领导”发现某个“干活的”因为劳累过度而病倒了，则是不会考虑先尝试“医治”他的，而是一脚踢出去，然后把他的任务分给其他人。其中微服务架构 Kubernetes 就恰好采用了这一设计思路。 中心化设计的问题 ： 中心化的设计存在的最大问题是“领导”的安危问题，如果“领导”出了问题，则群龙无首，整个集群就奔溃了。但我们难以同时安排两个“领导”以避免单点问题

分布式理论（一） CAP 理论 一． CAP 理论前言 CAP 原则又称为 CAP 理论，主要思想是在任何一个分布式系统中都无法同时满足 CAP 。 C （ Consistency ）：表示一致性，所有的节点同一时间看到的是相同的数据。 A （ Avaliablity ）：表示可用性，不管是否成功，确保一个请求都能接收到响应。 P （ Partion Tolerance ）：分区容错性，系统任意分区后，在网络故障时，仍能操作。 如上所述，正如 Gilbert 认为， 一致性 其实就是关系型数据库所讲的 ACID ，一个用户请求要么是成功，要么是失败的，不能有处于一个中间状态；一旦一个事务完成，将来所有事务都必须基于这个完成后的状态；未完成的事务不会互相影响；一旦一个事务完成，就是持戒的。 可用性 其实就是对于一个系统而言，所有的请求都应该 “成功”并且收到“响应”。 分区容错性 其实就是指分布式系统的容错性，一个节点出现了故障，不影响整个集群的正常使用。 二． CAP 理论介绍 如图，在一个网络中， N1 和 N2 即分布式系统中的两个节点，他们都共享数据块 V ，其中有一个值是为 V0 。 l 在满足一致性的时候， A 中的 V0 应该和 B 中的 V0 保持一致的，即 V0=V0 l 在满足可用性的时候，无论请求访问 A 或者是 B 都应该得到响应。 l 在满足分区可用性的时候