ACID：关系型数据库中事务的4个属性：
Atomicity，原子性，整个事务的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间的某个环节。事务在执行过程中出错，会回滚到事务开始前的状态，就像没发生一样。
Consistency，一致性，在事务开始之前和结束之后，数据的完整性没有被破换。
所谓数据完整性，是指数据是正确无误的，没有歧义的。如果数据存在自相矛盾，不相容的地方，则其完整性被破坏了。
Isolation，隔离性，两个事务的执行是互不干扰的，一个事务不能看到其他事务运行时中间某一时刻的数据。
Durability，持久性，事务结束之后，该事务对数据库所做的修改会持久地保存在数据库中，不会被回滚。
CAP理论：分布式系统中只能同时满足CAP中的两个：
Consistency，一致性，有两方面含义。
一方面是指无论何时何地访问这个数据，都会得到相同的结果，即保证行为的一致。比如，A写入一个数据，那么下次读时应该能看到上次写的数据，否则就出现了不一致。
另一方面是指数据在分布式系统中，不存在歧义，即保证数据的一致。比如，数据的多个副本都是相同的，否则就出现了歧义。
Availability，可用性，是指分布式系统时刻能够提供服务，不存在暂停服务的时刻。
Partition Tolerance，分区容忍性，是指数据不受分布式的影响，即使某个节点失效，也不会出现数据错误、失效等问题。
可以看出，同时满足CAP是不可能的。
如想保证一致性和可用性，那么就不能再分布式。因为分布式会破坏一致性或者可用性中的一者，也就是说一定会破坏两者的组合。
如想保证分布式和一致性，那么就必须在系统运行的某个时刻，暂停服务，进行数据同步，这就破坏了可用性。
如想保证分布式和可用性，那么系统时刻不停机，就没有机会进行数据同步，也就破坏了一致性。
BASE：分布式系统与关系型数据库相对的3个属性：
Basically Availability，基本可用性，这个称呼可能有些歧义，应该翻译为“主要可用性”，实际上BASE的目的就是舍去Consistency，而得到Availability，因此，这里应理解为一切以可用性为主。
Soft State，软状态，是指系统介于stateful和stateless之间，只维护一定的信息，作为高速缓存，这些信息实际上可以通过一定的计算重新得到(如从周围节点收集信息汇总)，因此即使丢失也无所谓。当系统出错时，可以迅速恢复状态。
Eventually Consistency，最终一致性，为弱一致性的一种特例，是指系统中多副本之间并不是时刻保持一致的(言外之意，不同用户，或者同一用户的不同时刻，可能会读到不一致的数据)，但系统最终会在某个时刻变得一致(如经过数据同步)。
从用户(Client)看到的角度讲：
强一致性(Strong Consistency)，保证对a修改之后(事务完成之后)，任何用户马上就能看到a的最新值。
弱一致性(Weak Consistency)，对a修改后，不保证所有用户都能看到最新值。最终一致性是弱一致性的特例。
从系统内部(Server)的角度讲：
一致性的意思是，在分布式系统中，数据之间必须相容，不存在有歧义的地方。如多个副本的内要容相同，或者有多个版本但版本之间不冲突。又如不能同时存在这三条导致矛盾的记录：a>b,b>c,a<c。
可以看出，在系统内部，数据不一定是严格一致的，只要保证用户看到的是一致的即可。
Dynamo提供采用NRW模型来描述一致性：
N 数据副本的总数
R 每次读取的副本数
W 每次写的副本数
系统要想向外提供强一致性，则保证R+W>N即可，也即R集合和W集合存在交集，这样用户在读时，至少能得到一个最新的记录，进而通过版本号/时间戳/Vector Clock来决定选择哪一个记录。
否则，若系统只能保证R+W<=N，则它就是弱一致性的。
在同时向多个节点同步数据时，通常采用两阶段提交协议(Two Phase Commit)，该协议分两个阶段，第一阶段为准备阶段(Prepare)，master向所有的slave发送写请求，slave收到请求后，做一定的操作(如判断是否有冲突)，然后向master回复是否同意写请求，master收到所有回复后，再判断是否进行提交。最后，进入提交阶段(Commit)，master向所有slave发送提交请求，slave收到后正式将修改持久化。
Dynamo在写W个副本时，采用了改进的2PC，即如果准备阶段W中有节点没有响应，则尝试W之外的节点，保证收到W个节点的响应，才会进入提交阶段。
HDFS在同步写多个副本时，也采用了改进的2PC，即先以pipeline的方式，向多个副本写数据，其过程中只要有一个节点写失败，则整个写操作失败，只有当所有节点都成功后(后面的节点会向前级联反馈)，发起者才决定写成功(向NameNode提交)。