雷兽的数据库CAP乱谈之（一）阐述

今天有人问我cap，找了https://my.oschina.net/lilw/blog/169776这片文字，

下面是cap那篇文字的解释：

所谓CAP理论，即：

Cosistency       数据的一致性

Availability      高可用性

Tolerance to newowrk Partitions    分区容忍性

一个数据存储系统不可能同时满足上述三个特性，只能同时满足其两个特性，也就是： CA,CP,AP。可以这么说，当前所有的数据存储解决方案，都可以归类的上述三种类型。

CA  满足数据的一致性和高可用性，但没有可扩展性，如传统的关系型数据，基本上满足是这个解决方案，如ORACLE , MYSQL 的单节点，满足数据的一致性和高可用性。

CP  满足数据的一致性和分区性，如Oracle RAC ，Sybase 集群。虽然Oracle RAC具备一点的扩展性，但当节点达到一定数目时，性能（也即可用性）就会下降很快，并且节点之间的网络开销很在在，需要实时同步各节点之间的数据。

AP 在性能和可扩展性方面表现不错，但在数据一致性方面会用牺牲，各节点的之间数据同步没有哪么快，但能保存数据的最终一致性。当前热炒的NOSQL大多类是典型的AP类型数据库。

以上是原文内容；

我却觉这解释有点不完全敢苟同，按照这篇文字第一条ca组合下的描述，这个高可用性我认为应该是鲁棒性，

我跟这个所谓数据库的鲁棒性，就是比如在同一个实例同一个库的数据库，不管你是单表还是多表join，想怎么读怎么写都不是问题，我认为说这是可用性，很是牵强，因为

 cap百度百科的解释如下：

分布式系统的CAP理论：理论首先把分布式系统中的三个特性进行了如下归纳：
● 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

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

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

在那篇文字里提到ca只有单节点如何，很明显单节点根本不可能保证故障后还可读写，所以可用性是分布式的可用性，不是各种都支持的可用性，也就是我说的鲁棒性；很多人不知道在数据分片以后哪些能做哪些不能做，这就是分布式下相对于单实例数据库有诸多鲁棒性的限制；

 

下面阐述我个人理解的正文：

cap  是数据分散存储 不在同一个实例里的时候的 产生的问题
我这里说的cap既可能是sql下所谓的 可以叫 伪分布式集群的cap，当然还包括nosql集群的cap，
让后其实还讲到了在大的分布式意义下 某个小规模下的非分布式  也就是分片节点本身  数据100%冗余 全库冗余的情况下  也就是只有一个分片；

首先 在上面说的这种整个集群单一分片的情况下  分多种情况  比如包括  主从 主备  多主
主从就是线上备份   从默认不能写  但是主挂了不自动切换  原始的各种数据库同步技术就是这种了  你是否利用从库来做读的加速 是你自己处理
主备 是主从加上了自动切换  
多主 差不多相当于是把主备的方式反过来  同时也让备同步到主 双向考虑
这里还有个问题就是 同步复制还是异步复制

异步复制以及同步复制发送延迟过大造成了本质上的异步的瞬间问题点的时候
简单的可以认为是分布式数据存储时候的最简单最基本的静态状态下，这是我自己的话，也就是指整个数据库集群 就只有一个分片  每个节点100%数据冗余的情况，暂且把这种情况叫做静态的分布式数据库集群模式

在这种静态中的cap （以下字母我就不分了 反正 内容就是那三个：数据一致性，高可用，分区容忍性）

数据一致性 应该是同内容的镜像分片之间的数据一致与否的问题 就是异步复制 和 同步复制延时过大   这个问题在很多事务级同步的sql方案里不存在了  但是并非100%不会出现

高可用  这个分布式里的数据还是容器都一样  跟上面那个一样同一份数据或者同一个功能节点是否有冗余 是否高可用自动切换  这里为了鲁棒性  其实应该默认和数据一致性同在  只有主备节点数据实时同步  并不会有数据一致性问题   才真正有高可用的意义，其实目前很多高可用方案 其实并非如此  具体技术  就要自己去了解

 

分区容忍性 这个在静态角度看好像并不存在

 

鲁棒性  在这种静态情况下  能够做到最接近单一节点的鲁棒性

然后动态来看  就是数据不在一个物理分片上了  就是认为  基本做不了高性能的join的这种情况 或者说 模式

数据一致性  因为不光是全数据镜像   还有同一个事务上下文在不同实例时候 因为普通事务无法维系   而产生的问题  通常 这个分布式数据系统都做不到 或者不能良好做到 比如mysql的 xa协议分布式事务  sqlserver的 基于dtc 分布式事务  这些性能 有限 随扩展后 性能下降更加明显  而在nosql里 基本就压根不支持跨节点事务  因为支持了这个   节点扩展 问题就非常严重了  也就是数据一致性降低了可分片的空间和意义

 

高可用 某个节点的可用性  还是要在一致性  也就是同步复制还是异步复制中寻找平衡   可以想象 你怎么在保证redis每秒20w tps （redis单线程set 有set就当是tps吧）   然后再保证有一个从节点能100%的同步复制   不掉数据？理论上可行  但是很多现实情况下  做不到

分区容忍性  其实是分布式的基础吧  这里我要说的是 oltp olap 问题   分区容忍性其实几乎100%的跟olap不合  至少挺难的  oltp简单一些 归结一点就是  单数据实例上各种操作的鲁棒性 在分区情况下 接近完全丧失

 

鲁棒性 在这种模式的情况下 鲁棒性就大大降低了  不能跨节点join  甚至做个排序分页 都未必能简单高效的完成  但是可以应对设计良好的大吞吐 oltp 基本最高性能的只有单表查询 或者按key查询

 

所以  cap 还有鲁棒性r（Robust，注意这里的鲁棒性已经不是Robust的原意，而是方便无脑不会出问题的意思）的认识，加上对一种集群技术、方式方案组合都必须考虑清楚。