1.a：表示原子性，事务中如果有多个修改操作，会把这些操作记录日志，如果失败则根据日志回滚；
2.c：一致性，表示数据要正确，例如A往B转了一百块，A账户要少一百块，B账户要多一百块；例如扣完了库存，要新增一个流水和库存剩余要更改；
也就是数据要始终保证是正确的。而CAP里面的C，也是一致性，从表面上看是各个节点的数据要一致，但是本质上还要保证数据的正确性，
节点的数据不一致了，A节点显示用户账户有10块钱，B节点显示用户有5块钱，这显然是也是数据不正确，只是这种不正确可能是短暂的，
等缓存过了，等数据同步过来了，等了几秒钟后才会正确。
3.i：隔离性，其实有原子性，数据串行执行理论上不会产生错误的数据了，但是如果并行执行机会使得事务相互影响，需要将事务全部或者局部串行化，
保证数据不会出错。
优惠券平台，redis和DB不同步，这是因为设计系统追求的是可用性，在redis挂掉的时候，接口仍然可以运行，牺牲了一致性，后期通过消息加上JOB的补偿
达到了最终的一致性。而优惠券平台事务之间的隔离，也就是直接在事务上加上全局锁（不是局部串行），使得同一个交易变成串行执行，防止数据产生
覆盖更新，也是为了数据的一致性。
参考： https://www.zhihu.com/question/30272728
cap中：
1.c:表示节点数据一致性，在分布市中一致性表示每个节点都需要有一致的数据返回；
2.a:可用性，如果追求强一致性，可用性就会牺牲，强一致性意味着数据要同步修改，同时没有被修改的节点处于不可访问的状态，很显然可用性就低了
3.p:分区容忍性，当本来放在一处的数据现在容忍他例如经过sharding放在不同的地方（扩展），就产生了分区，也就是容忍了分区，
分区在传统acid里面意味着，我的原子性比较难做，例如需要两段式提交，容易产生acid里面的不一致，也就是保证cap里面的一致性就难了，
总结：数据不一致，因为节点之间数据没有及时同步，也因为分区后数据分散在多个点，容易不一致，
如果数据只在一个节点可以访问，就有单点问题，也就可用性差了了
如果不能容忍分区，意味着系统不能把数据分散存放，他的扩展能力不行，性能就上不去，
如果容忍了，容易不一致，这里不一致表示acid里面的不一致，数据落在不同的节点上，做事务就设计分布式事务了
如果有单点，容易不可用，如果j
点多了，容易不一致。
参考： http://www.cnblogs.com/hxsyl/p/4381980.html