原子性很容易理解，也就是说事务里的所有操作要么全部做完，要么都不做，事务成功的条件是事务里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚。比如银行转账，从A账户转100元至B账户，分为两个步骤：1)从A账户取100元;2)存入100元至B账户。这两步要么一起完成，要么一起不完成，如果只完成第一步，第二步失败，钱会莫名其妙少了100元。

　　2、C (Consistency) 一致性

　　一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。

　　3、I (Isolation) 独立性

　　所谓的独立性是指并发的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。比如现有有个交易是从A账户转100元至B账户，在这个交易还未完成的情况下，如果此时B查询自己的账户，是看不到新增加的100元的

　　4、D (Durability) 持久性

　　持久性是指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失。

　　2. CAP是什么

　　C:Consistency(强一致性)

　　A:Availability(可用性)

　　P:Partition tolerance(分区容错性)

　　3. CAP三个只能满足两个!!!(CAP的3进2)

　　CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。

　　而由于当前的网络硬件肯定会出现延迟丢包等问题，所以

　　分区容忍性是我们必须需要实现的。

　　所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。

　　===============================================================

　　C:强一致性 A：高可用性 P：分布式容忍性

　　CA 传统Oracle数据库

　　AP 大多数网站架构的选择

　　CP Redis、Mongodb

　　注意：分布式架构的时候必须做出取舍。

　　一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。

　　因此牺牲C换取P，这是目前分布式数据库产品的方向

　　===============================================================

　　一致性与可用性的决择

　　对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地

　　数据库事务一致性需求

　　很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低， 有些场合对写一致性要求并不高。允许实现最终一致性。

　　数据库的写实时性和读实时性需求