浅谈一些机制问题

1.CAS机制

        CAS即Compare And Swap（比较并交换），它一共包含三个数据第一个是原本数据，第二个是原本数据的副本，第三个是数据时修改后的值，CAS是一个无锁机制，但在进行修改的时候是一个原子操作，会保证在修改的时候不会有其他线程进行干扰。它在进行修改的时候会将原本数据的副本与原本数据进行比较，如果副本的值与原本数据值不一致则是现在修改操作执行前有线程进行了修改，那么这次修改则不会进行，若一直则会进行，这种机制虽然可以提高并发量是一个无锁机制，但会有ABA问题，即当我一个数据第一次修改是想把A->B,但在这次操作的中间发生了两次修改A->B,B->A，那么这次修改仍会进行，这样就会造成ABA问题，我想修改的是A->B但我可能会丢失了B->A这次修改的某些数据。为了解决ABA问题我们引入了版本控制机制

2.版本控制机制

        版本控制机制即在CAS机制上加上了一个版本，使得每次修改都会存在一个版本号，当我进行修改的时候我会先获取最新的版本号，然后在修改的时候会比较我获得的版本号和最新的版本号是否一致，一致则进行修改，否则不进行修改。java中已经存在很多版本控制机制的类了例如AtomicStampedReference

3.MVCC多版本并发控制机制

        即读写不会产生冲突，它会记录每一行数据的多个版本，采用的是以空间换时间，为了实现MVCC机制，采用了undo log版本链和readview。

        当我们进行insert操作的时候会在undo log中记录一个主键id当事务进行回滚是就会删除这个主键的数据，即会进行相反操作。

        在数据库表中每一行都会有三个隐藏字段row_id,trx_id,roll_pointer,row_id即主键，如果存在主键该值就是主键的值，若是没有主键则mysql会按照字段顺序找一个非空唯一索引整形字段成为主键，若是找不到那么row_id就会变为自增主键。trx_id当一个事务开始前都会自动被分配一个事务id，roll_pointer回滚指针，事务对当前行进行修改的时候，会将旧数据写入undo log中，然后新数据写入当前行，回滚指针就会指向对应的undo log中的数据，然后多个事务对同一个数据进行修改，就会有多个undo log数据，那么就会形成undo log版本链。

        readview,理解这个之前需要理解快照读和当前读，快照读就是可以读取不同版本的数据，当前读就是读取最新数据，而在使用快照读或者事务第一次进行快照读的时候就会生成一致性视图readview，readview就是用来判断哪些版本的数据是可见的，它有四个参数m_ids，包含所有未提交事务的id，min_trx_id,m_ids中最小的事务id,max_trx_id下一个即将被分配的事务id，不是m_ids中最大的id,creator_trx_id创建此视图的事务id，当事务版本号小于min_trx_id那么说明该事物已经提交了，即可见，如果trx_id>max_trx_id说明该事务id是在生成视图之后发生的，那么对于当前事务是不可见的，若在大于最小小于最大的时候则要判断是否在m_ids中，若在此中说明还未提交是不可见的，若不在此中说明已经提交是可见的。

        当undo log中一个事务的头结点是不可见的那么就会通过roll_pointer找到上一个undo log数据，直到找到可见的，若是整个链表没有找到可见的，那么表示查不到这个数据

        MVCC机制适用于隔离级别为read committed和repeatable read这两个隔离级别，因为uncommitted中不会加锁，对于所有事务版本都是可见的所以不需要MVCC机制，而在可串行化中，都是顺序执行的，完全用不到MVCC机制

4.fail-fast和fail-safe机制

           fail-fast: 快速失败机制，发生在集合类中，当集合进行遍历的时候，若有其他线程对集合中的数据进行了修改，那么就会发生fail-fast快速失败机制，报ConcurrentModificationException异常，这个就需要去看集合遍历的源码了，这边简要介绍一下，先要了解两个东西一个是modCount和expectedModCount,第一个是集合中的一个成员变量，记录了当前集合被修改的次数，第二是是iterator迭代器中的一个变量，记录调用迭代器时集合的修改此处，当我们迭代进行next()方法时会去比较这两个值是否一致，当我们修改集合的时候会对modCount进行加一但迭代器中的不会所以会报错，但我们例如ConcerrentHashMap这类集合它进行修改的时候不是对原有集合直接进行修改而是先会生成一个副本对这个副本进行修改然后再赋值给原集合，遍历的时候也是，会生成一个副本进行遍历，但遍历的时候如果修改了数据是不可见的，这就是fail-safe机制安全失败机制

5.CAP理论

        C：一致性（强一致性）；A：可用性；P：分区容错性

        一致性就是指当发生网络故障或者节点故障时，为了保证强一致性，那么就要不断的去重试，确保所有的节点的数据是一致的，这样就会保证不了可用性。

        可用性就是指可以及时的给与用户反馈，而确保了可用性，那么系统就不能进行长时间阻塞，那么强一致性就无法保障。

        分区容错性是指当发生网络故障导致某个节点出现故障了，其余的节点仍是可用的，网络天然是不可靠的，只能通过硬件去提高可靠性，当你使用了网络那么就必须保证分区容错性，除非没有进行网络传输

        CAP认为分布式系统中最多只能满足CAP中的任意两个无法全部满足。因为在分布式系统中，网络分区和节点故障是无法避免的，所以当发生网络分区导致节点数据不一致的情况下我们要么保证可用性，允许节点继续处理请求并返回响应给用户，要么就停机等待网络分区恢复。

        当我们使用CA时，适用于小型的集中式系统，当不考虑分区时，我们只有一个分区，那么数据不需要进行同步那么肯定是一致的，而由于我们不需要写入到其他副本，那么不用进行传输，那么可用性也是可以保障的，当我们增加分区时，使用强一致性，那么就要写入到其他副本中，增加了同步时间和同步失败的概率，会导致可用性变差，当我们使用弱一致性，那么我们就会使用异步去同步数据，那么可能造成同步失败和数据丢失的概率，导致强一致性变差。

        当我们使用AP时，适用于对数据实时性要求比较高的系统，不考虑一致性，分区越多，那么用户就能就近访问，提高响应速度，放弃一致性，数据写入主节点后就能立即返回，通过异步进行同步数据。

        当我们使用CP时，适用于对数据一致性要求比较高的系统，当我们放弃可用性时，我们就可以保证多个分区之间的强一致性，可以无限等待数据变成一致。