Cap

分布式系统赫赫有名的 CAP 定理，示意分布式系统只能同时满足 CAP 三个个性中的两个，其中 C-Consistency 强一致性，A-Avaliability 可用性，P-Partition Torrelation 分区容忍性，以下听我缓缓道来分区 Partition 和 分区容忍 Partition Torrelation 是两个不同的概念，我刚开始也是傻傻分不清，这里先谈谈分区问题。因为网络的不牢靠以及程序的不稳定性，分布式系统中会有概率产生局部结点的断开，解体，脱离零碎。假如咱们的数据以分片的模式存储在分布式系统的各个节点，一旦产生分区问题就会造成局部数据分片的失落，整个零碎就无奈提供残缺的数据服务，当然咱们无法忍受这种状况产生。最无效的方法是给每个数据分片设置正本分片，备份到其余节点上，分区问题一经呈现，正本分片也能长期作为主分片持续提供服务，保障了零碎服务的完整性，这时零碎就有了分区容错的能力，也叫分区容忍性<放个图片>数据备份冗余的水平越高，零碎的分区容忍性越高，极其状况下每个节点都保留了残缺的数据，即便分布式系统只剩下一个节点，也能提供残缺的数据服务（但存储老本，同步老本太高）分区问题是概率必然呈现的，所以要优先保证系统的分区容忍性P，那么依据 CAP 定理，分布式系统只能抉择满足 A 或 C，以下别离进行解释Availability 可用性，示意零碎每时每刻都能提供服务，不能停机Consistency 强一致性，示意零碎在提供服务的时间段内需保证数据强一致性因为 P 的原理数据存在正本，当用户更新某个数据后，为了保障强一致性，零碎必须暂停服务，把更新后的数据同步到正本分片，再开启服务，而暂停服务这个操作显然违反了 A 可用性。如果优先保障 A 可用性，那么数据更新同步的时间段就无奈满足强一致性了。通常状况下，数据正本只用于备份和容灾，个别不对外提供服务，所以大部分的分布式系统都会优先选择 AP，尽管不能保障强一致性，但数据同步胜利后还是能达到最终统一的状态。

一个分布式系统外面，节点组成的网络原本应该是连通的。然而可能因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。数据就分布在了这些不连通的区域中。这就叫分区。当你一个数据项只在一个节点中保留，那么分区呈现后，和这个节点不连通的局部就拜访不到这个数据了。这时分区就是无奈容忍的。进步分区容忍性的方法就是一个数据项复制到多个节点上，那么呈现分区之后，这一数据项就可能散布到各个区里。容忍性就进步了。然而，要把数据复制到多个节点，就会带来一致性的问题，就是多个节点下面的数据可能是不统一的。要保障统一，每次写操作就都要期待全副节点写胜利，而这期待又会带来可用性的问题。总的来说就是，数据存在的节点越多，分区容忍性越高，但要复制更新的数据就越多，一致性就越难保障。为了保障一致性，更新所有节点数据所须要的工夫就越长，可用性就会升高。 作者：知乎用户链接：https://www.zhihu.com/questio...起源：知乎著作权归作者所有。商业转载请分割作者取得受权，非商业转载请注明出处。 定义CAP 原理：分布式系统无奈同时确保一致性（Consistency）、可用性（Availability）和分区容忍性（Partition），设计中往往须要弱化对某个个性的需要。一致性、可用性和分区容忍性的具体含意如下：一致性（Consistency）：任何事务应该都是原子的，所有正本上的状态都是事务胜利提交后的后果，并放弃强统一；可用性（Availability）：零碎（非失败节点）能在无限工夫内实现对操作申请的应答；分区容忍性（Partition）：零碎中的网络可能产生分区故障（成为多个子网，甚至呈现节点上线和下线），即节点之间的通信无奈保障。而网络故障不应该影响到零碎失常服务。CAP 原理认为，分布式系统最多只能保障三项个性中的两项个性。比拟直观地了解，当网络可能呈现分区时候，零碎是无奈同时保障一致性和可用性的。要么，节点收到申请后因为没有失去其它节点的确认而不应答（就义可用性），要么节点只能应答非统一的后果（就义一致性）。因为大部分时候网络被认为是牢靠的，因而零碎能够提供统一牢靠的服务；当网络不牢靠时，零碎要么就义掉一致性（少数场景下），要么就义掉可用性。留神：网络分区是可能存在的，呈现分区状况后很可能会导致产生“脑裂”景象。利用场景既然 CAP 三种个性不可同时失去保障，则设计零碎时候必然要弱化对某个个性的反对。弱化一致性对后果一致性不敏感的利用，能够容许在新版本上线后过一段时间才最终更新胜利，期间不保障一致性。例如网站动态页面内容、实时性较弱的查问类数据库等，简略分布式同步协定如 Gossip，以及 CouchDB、Cassandra 数据库等，都为此设计。弱化可用性对后果一致性很敏感的利用，例如银行取款机，当系统故障时候会拒绝服务。MongoDB、Redis、MapReduce 等为此设计。Paxos、Raft 等共识算法，次要解决这种状况。在 Paxos 类算法中，可能存在着无奈提供可用后果的情景，同时容许多数节点离线。弱化分区容忍性事实中，网络分区呈现概率较小，但很难完全避免。两阶段的提交算法，某些关系型数据库以及 ZooKeeper 次要思考了这种设计。实际中，网络能够通过双通道等机制加强可靠性，实现高稳固的网络通信。

Normalization/Denormalization范式化设计Normalization 概念设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。 Normalization 优点节省存储空间，并减少不必要的更新Normalization 缺点查询缓慢：⼀个完全范式化设计的数据库会经常⾯面临“查询缓慢”的问题，因为数据库越范式化，就需要 Join 越多的表几种范式第一范式：1NF（First Normal Form）消除非主属性对键的部分函数依赖 第二范式：2NF（Second Normal Form）消除非主要属性对键的传递函数依赖 第三范式：3NF（Third Normal Form）消除主属性对键的传递函数依赖 BC范式：BCNF（Boyce-Codd Normal Form）主属性不依赖于主属性 反范式化设计Denormalization 概念数据 “Flattening”，不使用关联关系，⽽而是在文档中保存冗余的数据拷贝 Denormalization 优点读取性能好，查询快，无需 join 操作Denormalization 缺点浪费空间一条数据的改动，可能会引起很多数据的更新小结关系型数据库一般优先考虑范式化设计非关系型数据库一般优先考虑反范式化设计范式化设计节省了存储空间，但是存储空间却越来越便宜；范式化简化了更新，但是数据“读”取操作可能更多反范式化设计数据库会通过压缩尽量减少空间占用，如 Elasticsearch 通过压缩 _source 字段，减少磁盘空间的开销数据库事务事务的概念数据库事务（Database Transaction，简称“事务”）是数据库管理系统执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。这个过程中的所有操作要么都成功，要么都不成功。 ACIDACID 是事务的四个特性，指的是atomicity，原子性；consistency，一致性；isolation，隔离性；durability，持久性。 原子性（Atomicity）指所有在事务中的操作要么都成功，要么都不成功，所有的操作都不可分割，没有中间状态。一旦某一步执行失败，就会全部回滚到初始状态。 一致性（Consistency）指的是逻辑上的一致性，即所有操作是符合现实当中的期望的。具体参考下一节 隔离性（Isolation）即不同事务之间的相互影响和隔离的程度。比如，不同的隔离级别，事务的并发程度也不同，最强的隔离状态是所有的事务都是串行化的（serializable）（即一个事务完成之后才能进行下一个事务），这样并发性也会降到最低，在保证了强一致性的情况下，性能也会受很大影响，所以在实际工程当中，往往会折中一下。 持久性（Durability）可以简单地理解为事务执行完毕后数据不可逆并持久化存储于存储系统当中 CAPCAP 理论主要是针对分布式存储系统的，C 是指 Consistency 一致性，A 是指 Availability 可用性，P 是指Partition tolerance 分区容忍性。CAP 定理认为分布式系统中这三个特性最多只能同时满足两个特性。 一致性（Consistency）指在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本） 可用性（Availability）在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性） 分区容忍性（Partition tolerance）即当节点之间无法正常通信时，就产生了分区，而分区产生后，依然能够保证服务可用，那么我们就说系统是分区容忍的。显然如果节点越多，且备份越多，分区容忍度就越高（因为即便是其中一个或多个节点挂了，仍然有其它节点和备份可用）。 理解一致性（此 C 非 彼 C）实际上我们通常说的数据库事务的一致性和分布式系统的一致性并不是一个概念。这里可以区分成“内部一致性”和“外部一致性”。“内部一致性”搞数据库的人很少这么说，一般就直接说一致性，更准确的说是“Consistency in ACID”（“事务 ACID 属性中的一致性”）；“外部一致性”是针对分布式系统而言的，分布式领域提及的 Consistency 表示系统的正确性模型，著名的也是臭名昭著的 CAP 理论中的 C 就是这个范畴的。这主要是由于分布式系统写入和读取都可能不在同一台机器上，而这必然会有一段时间导致不同机器上所存的数据不一致的情况，这就是所谓的“不一致时间窗口”。 ...

CAP 理论是分布式系统设计中的一个重要理论，虽然它为系统设计提供了非常有用的依据，但是也带来了很多误解。本文将从 CAP 诞生的背景说起，然后对理论进行解释，最后对 CAP 在当前背景下的一些新理解进行分析，澄清一些对 CAP 的误解。 CAP 理论诞生的背景CAP 理论的是在“数据一致性 VS 可用性”的争论中产生。CAP 的作者 Brewer 在 90 年代的时候就开始研究基于集群的跨区域系统（实质上是早期的云计算），对于这类系统而言，系统可用性是首要目标，因此他们采用了缓存或者事后更新的方式来优化系统的可用性。尽管这些方法提升了系统的可用性，但是牺牲了系统数据一致性。 Brewer 在 90 年代提出了 BASE 理论（基本可用、软状态、最终一致性），这在当时还不怎么被接受。因为大家还是比较看重 ACID 的优点，不愿意放弃强一致性。因此，Brewer 提出了 CAP 理论，目的就是为了开阔分布式系统的设计空间，通过“三选二”的公式，解放思想，不要只抓着一致性不放。 理解了 CAP 诞生的背景，我们才能更加深入的理解 CAP 理论，以及它带来的启示。“三选二”的观点虽然帮助大家开拓了设计思路，但是也带来了很多误解。下面我们会逐一分析，首先来看一下 CAP 理论的解释。 CAP 理论的经典解释CAP 定理是分布式系统设计中最基础，也是最为关键的理论。它指出，分布式数据存储不可能同时满足以下三个条件。 一致性（Consistency）：每次读取要么获得最近写入的数据，要么获得一个错误。可用性（Availability）：每次请求都能获得一个（非错误）响应，但不保证返回的是最新写入的数据。分区容忍（Partition tolerance）：尽管任意数量的消息被节点间的网络丢失（或延迟），系统仍继续运行。CAP 定理表明，在存在网络分区的情况下，一致性和可用性必须二选一。当网络发生分区（不同节点之间的网络发生故障或者延迟较大）时，要么失去一致性（允许不同分区的数据写入），要么失去可用性（识别到网络分区时停止服务）。而在没有发生网络故障时，即分布式系统正常运行时，一致性和可用性是可以同时被满足的。这里需要注意的是，CAP 定理中的一致性与 ACID 数据库事务中的一致性截然不同。ACID 的 C 指的是事务不能破坏任何数据库规则，如键的唯一性。与之相比，CAP 的 C 仅指单一副本这个意义上的一致性，因此只是 ACID 一致性约束的一个严格的子集。 CAP 理论看起来难理解，其实只要抓住一个核心点就能推导出来，不用死记硬背。在出现网络分区的时候， 如果系统不允许写入，那么意味着降低了系统的可用性，但不同分区的数据能够保持一致，即选择了一致性。如果系统允许写入，那么意味着不同分区之间的数据产生不一致，系统可用性得到保障，即选择可用性。CAP 的新理解CAP 经常被误解，很大程度上是因为在讨论 CAP 的时候可用性和一致性的作用范围往往都是含糊不清的。如果不先定义好可用性、一致性、分区容忍在具体场景下的概念，CAP 实际上反而会束缚系统设计的思路。首先，由于分区很少发生，那么在系统不存在分区的情况下没什么理由牺牲 C 或 A。其次，C 与 A 之间的取舍可以在同一系统内以非常细小的粒度反复发生，而每一次的决策可能因为具体的操作，乃至因为牵涉到特定的数据或用户而有所不同。最后，这三种性质都可以在程度上都可以进行度量，并不是非黑即白的有或无。可用性显然是在 0% 到 100% 之间连续变化的，一致性分很多级别，连分区也可以细分为不同含义，如系统内的不同部分对于是否存在分区可以有不一样的认知。 ...