NoSQL——事务和数据完整性管理

RDBMS的ACID在单个服务器或节点上没有问题，但是一旦分不到多个节点上就开始出现问题了。

想要一致的，有条理的解决在分布式系统中实现类ACID保证的难题，就需要理解下面三个因素在分布式系统中如何受影响（CAP）

1. 一致性
   1. 一致性表示原子性和隔离性，即一致的读写，并发能看到有效的一致的数据状态，在CAP中，一致性纸没有满足约束的数据不会被持久化。
      
2. 可用性
   1. 即在需要时可以提供服务。即使是轻微的延迟或者堵塞也是不可用，这是许多应用程序都可以在可用性上做妥协，是一个可选的权衡选项。
      
3. 分区容忍性
   1. 即容错性，是衡量系统在部分成员不可用情况下继续提供服务的能力。
      

这是Brewer定理的说三大支柱，简单说就是不可能同时实现三个，二是必须做出权衡，牺牲一个换取另外两个。

1. 妥协可用性：系统支持备份，快速复制，错误恢复等保证数据的一致性，这就意味着在很短的一段时间里可能还会处于不可用状态，轻微的不可用状态并不是灾难性的。
2. 妥协分区容忍性：最好不要。
3. 妥协一致性：分为强一致性和弱一致性。弱一致性包括没有一致性和最终一致性。

MongoDB没有规定一致性模型，但是默认强一致性。某些情况下MongoDB可以配置为最终一致性。MongoDB可以提供更高的可用性和分区容忍性，其中一种是采用单个主机作为唯一的写节点，多个从节点读取。

CouchDB的最终一致性模型依赖于两个重要的属性：

• 多版本并发控制（MVCC）
• 复制

CouchDB每个文档都有版本，更新都会被标记唯一修订号，是高可用的分布式系统，通过放宽一致性支持可用性。

多版本并发可以解决数据更新冲突问题。复制帮助完成最终一致性。复制时只有修改的会复制，出错也能恢复。，如果复制失败可以从停止的地方重新继续开始，避免了多余的重启。CouchDB集群通常构成主主节点，每个节点就可以独立服务请求，从而同时增强可用性和响应性。