【总结】ACID、Data Replication、CAP与BASE

1，ACID

• 在传数据库系统中，事务具有ACID 4个属性
• • 原子性（Atomicity）：事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行
  • 一致性（Consistent）：在事务开始和完成时，数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改，以保持数据的完整性；事务结束时，所有的内部数据结构（如B树索引或双向链表）也都必须是正确的
  • 隔离性（Isolation）：数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的，反之亦然
  • 持久性（Durable）：事务完成之后，它对于数据的修改是永久性的，即使出现系统故障也能够保持
• 单个节点的事务：数据库都是通过并发控制（两阶段封锁，two phase locking或者多版本，multiversioning）和恢复机制（日志技术）保证事务的ACID特性
• 跨多个节点的分布式事务：通过两阶段提交协议（two phase commiting）来保证事务的ACID
• 数据库系统是伴随着金融业的需求而快速发展起来：对于金融业，可用性和性能都不是最重要的，而一致性是最重要的，用户可以容忍系统故障而停止服务，但绝不能容忍帐户上的钱无故减少。而强一致性的事务是这一切的根本保证

2，Data Replication

• 数据复制(data replication)属于分布式计算的范畴，它并不仅仅局限于数据库
• 多副本构成的分布式数据库系统中， 其事务特性与单个数据库系统的差别主要表现在原子性和一致性两个方面
• • 在原子性方面， 要求同一分布式事务的所有操作在所有相关副本上要么提交， 要么回滚， 即除了保证原有的局部事务的原子性，还需要控制全局事务的原子性
  • 在一致性方面，多副本之间需要保证单一副本一致性
• 主从( Priamry / Copy)方式
• • 一般是系统中仅仅指定一个Primary节点接受更新请求 ， 在事务操作执行完毕后， 在事务提交前或后将操作广播到其他Copy节点
  • Primary / Copy方式并发控制较为简单， 由Primary本地的事务控制即可实现， 事务的原子性的实现也较为简单， 一般由Primary节点作为协调节点来实现
  • 缺陷也显而易见： 仅仅单个节点提供Update请求处理能力， 对于Update密集类型的应用， 如OLTP， 容易形成单点性能瓶颈
• 更新所有( Update-Anywhere ) 方式
• • 处理过程稍微复杂， 系统中的任何副本具有相同的地位，都可以接收Update请求 ，在检测事务冲突、事务提交前或后将各个节点的Update传播到其他副本节点
  • 通过多点提高事务吞吐率， 但随之而来的是多个分布式事务之间复杂的并发控制和原子性问题

• 从事务提交的时间点看， 可以分为积极 (Eager)和消极(Lazy) 两类
• • 积极 (Eager) ：
  • • 在事务提交前传播更新
    • 前者即通常无谓的同步复制(synchronous replication)
    • 优点是可以保证一致性(一般通过两阶段提交协议)，但是开销较大，可用性不好，带来了更多的冲突和死锁等问题
    • Lazy+Primary/Copy的复制协议在实际生产环境中是非常实用的，MySQL的复制实际上就属于这种
  • 消极(Lazy)：
  • • 在提交之后才将事务操作传播到其他副本
    • 无谓的异步复制(asynchronous replication)
    • 优点是可以提高响应速度， 但牺牲了一致性 ，一般实现该类协议的算法需要增加额外的补偿机制

3，CAP

• Consistency（一致性）
• • 一致性是说数据的原子性，这种原子性在经典的数据库中是通过事务来保证的，当事务完成时，无论其是成功还是回滚，数据都会处于一致的状态。在分布式环境中，一致性是说多个节点的数据是否一致
• Availability（可用性）
• • 可用性是说服务能一直保证是可用的状态，当用户发出一个请求，服务能在有限时间内返回结果
• Partition Tolerance（分区容错性）
• • Partition是指网络的分区。可以这样理解，一般来说，关键的数据和服务都会位于不同的IDC（Internet Data Center：互联网数据中心）
• CAP理论
• • 一个分布式系统不可能同时满足一致性，可用性和分区容错性这三个需求，三个要素中最多只能同时满足两点
  • 对于分布式数据系统而言，分区容错性是基本要求，否则就不称其为分布式系统
  • 不要把精力浪费在设计如何能同时满足三者的完美分布式系统上，而是应该进行权衡取舍。这也意味着分布式系统的设计过程，也就是根据业务特点在C（一致性）和A（可用性）之间寻求平衡的过程，要求架构师真正理解系统需求，把握业务特点

4，BASE

• BASE来自于互联网的电子商务领域的实践，它是基于CAP理论逐步演化而来，核心思想是即便不能达到强一致性(Strong consistency)，但可以根据应用特点采用适当的方式来达到最终一致性(Eventual consistency)的效果。BASE的含义：
• • Basically Available：基本可用
  • Soft-state：软状态/柔性事务，即状态可以有一段时间的不同步
  • Eventual consistency：最终一致性
• BASE是反ACID的，它完全不同于ACID模型，牺牲强一致性，获得基本可用性和柔性可靠性并要求达到最终一致性
• CAP、BASE理论是当前在互联网领域非常流行的NoSQL的理论基础，BASE思想的主要实现有
• • 按功能划分数据库
  • Sharding碎片

• 现在NOSQL运动丰富了拓展了BASE思想，可按照具体情况定制特别方案，比如忽视一致性，获得高可用性等等，NOSQL应该有下面两个流派：
• • key-value存储，如Amaze Dynamo等，可根据CAP三原则灵活选择不同倾向的数据库产品
  • 领域模型 + 分布式缓存+ 存储 （Qi4j和NoSql运动），可根据CAP三原则结合自己项目定制灵活的分布式方案，难度高
  • 共同点
  • • 都是关系数据库SQL以外的可选方案，逻辑随着数据分布，任何模型都可以自己持久化，将数据处理和数据存储分离，将读和写分离，存储可以是异步或同步，取决于对一致性的要求程度
  • 不同点
  • • NOSQL之类的key-value存储产品是和关系数据库头碰头的产品BOX，可以适合非Java如PHP RUBY等领域，是一种可以拿来就用的产品，
    • 领域模型 + 分布式缓存+ 存储是一种复杂的架构解决方案，不是产品，但这种方式更灵活

• 提供一种领域模型 + 分布式缓存+存储 + JMS异步的BASE解决方案图
• • 图中，领域模型带着逻辑和数据被分布式缓存如Ehcache +Terracotta分布到多台机器中运行，当领域模型需要驱动架构功能时，通过JMS驱动，而JMS也是一个集群无单点风险的架构，同时一个分布式事务架构，通过JMS分布式事务和关系数据库能够保证持久数据一致性，不过模型中数据和关系数据库中的数据一致性就不是高度实时的，这个方案属于一种低延迟low latency
  • 由于业务数据装在领域模型中，关系数据库只是用来做存储，这属于一种Not Only SQL