CAP理论（摘）

CAP理论（摘）

先解释一下软件编程中常见的一些概念：
抽象先于具象。

这个抽象并非虚无的抽象，而是指事物尚未分化为具象之前的那个前体存在。

当那个前体存在分化成具象存在之后，前体存在就退化为背景，成为一种抽象。

结构是关联与互动的复合体。

接口是结构的耦合点。

架构是从无结构到有结构的过程。

重构是从旧结构到新结构的过程。

也就是说，结构是架构的结果，架构是结构化的过程。

常听人说语言是工具，这是错误的。

语言不是工具，但它和工具都是大脑的延伸。

语言是介于智力与工具之间的衔接物。

就好比，人类语言是人与人之间的沟通媒介，是人与工具之间的衔接物，而编程语言，不过是将人类语言换成了另外一种符号系统，故编程语言可以看成是人脑与电脑的沟通媒介。

世界万物，皆有层次性。

最开始只有程序员。

架构师、项目经理、产品经理都是从程序员逐步分化出来的，架构师是项目最顶层的那个人，必须熟悉各个层次的需求，而不再仅仅是
程序层面的。

而凡高层次存在者，皆以对结构的调控与整合为其核心能力。

这里的结构调整，涉及各个层次，比如人员结构，成本结构，技术结构，语言结构等等。

即是说，复杂的工程项目架构不仅仅只是程序的架构，还会涉及人员、流程、管理等各层次的架构。

cap理论指的是三个层面事物的性质，三个层面指数据、系统、网络，简述如下：

一致性：指数据的一致性。

可用性：指系统的可用性。

容错性：指网络的容错性。

此三层层层嵌套包含，环环相扣，稳定性依次降低，而灵活性与复杂性依次上扬，因此出错率也依次提升。

越底层的越简单，也越重要，越具有决定性。

网
络和系统错了，还可以修补，而数据要是错了，就没法挽回了。

这其实和数据库的发展史也是一致和同步的。

所以分布式的系统，允许偶尔存在网络问题，但需要保
证可用性。

集中式系统，允许偶尔存在可用性问题，但需要保证一致性。

话说天下大势，合久必分分久必合。

而这世间的事物，也是以一种分化与构合的方式逐步交替演化而来。

nosql的出现，源于数据存储空间与数据访问时间的矛盾。

传统数据库的存储与访问是集中在一起的。

即是说，数据存在什么地方，就去什么地方访问。

集中模式的优点是数据稳定，生命周期长，可靠，强关系，缺点是空间扩展性有限。

集中模式的代表是关系数据库。

社会的进一步分化，使得IT系统也开始分化。

数据库也逐渐从关系数据库向不同领域不同层次分化。

网民的行为从最开始的只读模式，逐渐分化为读多写少的模式。

随着访问量提升，出现了IO密集型访问(此时主要是读取密集型)，从而导致读取时间变慢。

为提升性能，发展了数据库缓存技术，主要是对数据库的读取 *** 作进行分离。

而随着web2.0的进一步发展，网民的生产力进一步提升，存储总量开始增加。

此时虽然仍然是读多写少的模式，但写入量已经大大提升。

原有的缓存技术不能缓解写入压力，而且原有的空间也受硬盘限制，因此开始出现分库分表，实现读写分离。

集中模式的数据库就这样开始逐渐分化：由一个集中的、稳定的、强关系的结构，朝一个分化的、容错的、弱关系的结构发展。

数据的存储空间与数据访问时间也进一步分离。

即原来是数据存在什么地方，就去什么地方访问。

现在是数据还是存在老地方(硬盘)，但是访问却在另一个地方(比如内存，或另一个服务器)。

其目的，就在于缩短IO路径或分离IO，实现高效访问。

存储空间的分化，导致写入的分化，实现空间换时间的效果。

这种扩展分为两种模式：

如果横向分离(同一层次，空间分离)，则可实现诸如主从复制、分库分表等效果，使得读写分离，IO提升。

如果纵向分离(不同层次，过程分离)，则可实现数据库缓存、分布式缓存等效果，也能读写分离，IO提升。

redis首先是一个整体，其次是纵向分离的产物(由硬盘分离成硬盘+内存)，然后才是横向分离(分布式)。

它从内部是一分为二，将存储空间分为两块，将存储过程分为两步。

而memcached+mysql是两个东西，从外部将两者合二为一。

因此在契合度上，redis必然更有优势。

由于空间分离，数据也开始分离。

冷数据下沉，热数据上浮，而为了保持数据的一致和同步，必须保证在分离的同时，使得两者保持联系，以便于即时更新数据。

从整体上来说，redis是一个整体，其整体效果和连贯性要大于M+M的组合效果。

redis的数据同步在内部完成，是直接同步；而M+M必须借助中间件完成，是间接同步。

从结构上来说，redis的磁盘存储数据要比mysql简单，而内存结构却比memcached多样和灵活。

从扩展性来说，由于redis的底盘简单而稳定，使其有着良好的扩展性，而上层的复杂性使redis可以适应于更多复杂的业务场景。

原来业内认为M+M的问题是：

1，扩展时维护麻烦；

2，存在数据不一致现象；

3，大容量数据下命中率下降。

而redis基本没有上述问题，因此，redis有逐渐取代memcached的趋势。

mysql后来推出了一个memcached插件，对外提供与memcached协议兼容的接口，使得两者终于结为一个统一的整体了。

可以把memcached插件看成是mysql的一部分，因此我们从nosql的角度来看，mysql也可以视为是nosql的一种。

由于memcached插件朝mysql靠拢，使得memcached插件同时还得受制于mysql，即：memcached插
件和mysql更紧密更统一的同时，其生命周期和生存空间受到mysql的制约，一荣俱荣一损俱损，一旦mysql挂了它也得挂。

因此memcached
插件的推出，使得memcached呈现一种收缩的态势，扩展性受到mysql的限制。

从整体上来说，memcached插件的整体性和连贯性使得redis的优势已经被削弱。

从结构上来说，memcached插件可以天然的利用mysql自身的存储和复制，因此存储方面要强于redis，而上层的内存结构和 *** 作方式等依然弱于redis。

从扩展性来说，memcached插件和mysql结合紧密，由于底盘mysql本身的厚重性，扩展性受限制，使得memcached插件的分布式能力弱化了一些。

综上：

越集中的系统，架构越保守越封闭，稳定性越高，联系越紧密，伸缩性和扩展性必然受到制约。

越开放的系统，架构越分化越创新，稳定性越低，联系越松散，伸缩性和扩展性必然逐步扩大。

系统在开放和分离的同时，为了保证子系统内部的统一和连贯，必然要求子系统内部之间保持联系。

这使得现代系统和架构朝分布式和网络化的方向发展，以一种整体的多系统的连续的方式朝外扩散，一如宇宙的膨胀一般。

从逻辑结构上(而非诞生先后)来说，这种扩展趋势可以简单示例如下：

mysql --> mysql+handlersocket插件 --> mysql+memcached插件 --> mysql+memcachedb --> mysql+memcached

由上可见，系统存储架构从一个强联系的整体，朝一个弱联系的个体分化开去，内存应用一步一步朝独立的方向发展，逐步摆脱mysql的制约，向往极
端的自由和灵活，直到memcached完全和mysql隔离，时间和空间不再受mysql限制，必须靠第三方工具进行间接联系，使得扩展性达到极致。

由于系统分化使系统之间的联系进一步弱化，势必要求系统之间采用更加复杂的联系方式。

分化的越厉害，中间节点越多，联系方式就越加复杂，稳定性越低，故障自然越多，维护成本越大。

而redis则以一种相对简单和分散的方式，使得这一过程得以继续延续下去。

因此为什么redis能比M+M更好用，原因是：一是结构简单，二是硬盘与内存合为一体。

由于结构简单，所以方便扩展；又由于硬盘与内存合为一体，所以使数据也能同步扩展，维护更简单。