「数据库系列四」分布式数据库CAP理论与最终一致性

传统关系型数据库中事务有四个重要的特性，简称ACID，即

原子性 ：事务是一个不可分割的工作单位，事务中的操作要么都成功，如果有一个执行失败，所有的SQL将都被撤销，恢复到事务开始的状态

一致性 ：事务前后数据的完整性必须保持一致。例如转账前AB两账户金额之和是2000元，事务结束后，金额之和仍然是2000元

隔离性：当多个用户并发的访问数据库时，数据库为每一个用户开启的事务之间是隔离的，一个事务不能被其他事务的操作所干扰

持久性 ：持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响，即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。

NoSql出现在关系型数据库之后，主要是为了解决关系型数据库的短板，我们先来看看随着软件行业的发展，关系型数据库面临了哪些挑战：

1、高并发

一个最典型的就是电商网站，例如双11，几亿大军的点击造成在某一时刻的并发量是很高的，传统的关系型数据库肯定已经是不堪重负了，如Oracle的Session数量推荐的才只有500。

2、高效率存储海量数据

大数据时代，数据量已经不是用GB、TB来衡量了，而是EB、ZB了，面对这海量的数据，如何高效率的存储这些数据，关系型数据库无法解决这个问题，以Oracle为例，单机的物理扩展不仅成本高，而且难度也加大了。

3、高可用&高扩展

Oracle即使RAC能扩展数台机器，但数量也是有限。

NoSql的出现即是为了解决这些问题了，但是NoSql并不是用来替代关系型数据库的，因为它本身也有着不可克服的缺陷（当然也不影响总有挑战者，manggo就宣称他们要替代关系型数据库，但是在强一致的情况下是非常困难的）。

CAP理论是Brewer教授提出的：一个分布式系统不能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Tolerance of network Partition）。

一致性：任何一个读操作总是能读取到之前完成的写操作结果，也就是在分布式环境中，多点的数据是一致的。

可用性：每一个操作总是能在确定的时间内返回，也不是系统随时都是可用的。

分区容错性：在出现网络分区（如断网）的情况下，分离的系统也能正常运行。

不能同时满足CAP的原因是因为分布式系统中必须满足P，也就是分区容错性的原因，因为可能出现网络通信失败。假设此时分布式系统中有两台服务器N1 N2，假设N1和N2之间通信的时候网络突然出现故障，有用户向N1发送数据更新请求，那N1中的数据DB0将被更新为DB1，由于网络是断开的，N2中的数据库仍旧是DB0；如果这个时候，有用户向N2发送数据读取请求，由于数据还没有进行同步（一致性），应用程序没办法立即给用户返回最新的数据DB1，怎么办呢？有二种选择，第一，牺牲数据一致性，响应旧的数据DB0给用户；第二，牺牲可用性，阻塞等待，直到网络连接恢复，数据更新操作完成之后，再给用户响应最新的数据DB1。以上就是不能同时满足CAP的原因

CAP的选择策略

而市场上的NoSql则以CAP理论为指导，大多选择实现了CAP理论的两点（如CA（关系型数据库如mysql、AP(nosql数据库manggo)、CP（如zk）），未实现的即其缺陷部分。所以我们经常mysql很少看到分片集群，即使是做集群方案也会十分复杂，而nosql如manggo、es等往往是以集群形式存在，而cp相对来说较少。

常见NoSql的分类

类型	部分代表	特点
列存储	Hbase Cassandra Hypertable	顾名思义，是按列存储数据的。最大的特点是方便存储结构化和半结构化数据，方便做数据压缩，对针对某一列或者某几列的查询有非常大的IO优势。
文档存储	MongoDB CouchDB	文档存储一般用类似json的格式存储，存储的内容是文档型的。这样也就有有机会对某些字段建立索引，实现关系数据库的某些功能。
kv存储	Tokyo Cabinet / Tyrant Berkeley DB MemcacheDB Redis	可以通过key快速查询到其value。一般来说，存储不管value的格式，照单全收。（Redis包含了其他功能）
图存储	Neo4J FlockDB	图形关系的最佳存储。使用传统关系数据库来解决的话性能低下，而且设计使用不方便。
对象存储	db4o Versant	通过类似面向对象语言的语法操作数据库，通过对象的方式存取数据。
xml数据库	Berkeley DB XML	高效的存储XML数据，并支持XML的内部查询语法，比如XQuery,Xpath。

妥协的艺术：最终一致性

为了解决关系型数据库由于一致性导致的可用性降低的问题的解决方案,是基本可用，软形态，最终一致性的缩写，思路是放松对某一时刻一致性的要求来换取可用性和系统带的性能，等该时刻过去之后，再保证最终数据一致性，例如淘宝双11的浏览量，等等这些数据，在0点时刻不关注这些数据，尽可能为可用性服务，保证服务器不崩，等高峰期过后，比如说第二天，再将这些数据同步，完成最终一致性。