acid和cap的杂谈

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