CAS
其实CAS是用于乐观锁的一种实现，具体过程是“读-改-写”：
（1）读取数据版本号（时间戳）;
（2）对数据进行修改;
（3）对数据进行回写，查看数据版本号，如果版本号没有变化，那么成功写入，如果数据版本号变化了，那么写入失败，放弃此次修改。（最后一点的版本号比较-写入，应该是原子性的，这利用linux的atomic_t或者自己用锁都可实现。）
(atomic_cmpxchg是由cmpxchg指令完成的。它把旧值同atomic_t类型的值相比较，如果相同，就把新值存入atomic_t类型的值中，返回atomic_t类型变量中原有的值。)
CAS其实是利用了同一台机器上的时间戳的大小是可以表示事件发生的因果关系（不同的机器上是不可以的，在上面的时间戳部分有说明）。
由上面我们可以知道，由于时间戳可以表示不同机器上操作的偏序关系，要定义一种全序才能解决并发冲突的问题，由此，CAS定义了一种“先写入胜利”的关系。发现了没，CAS用的是“先”，又出现了先后，又要用时间来解决，但是很幸运。因为在同一台机器上事件是可以通过时间戳确定事件发生的因果（先后）顺序的，所以只要保证不同机器上没有相同的数据副本被操作（主从结构就可以满足），就可保证同一个数据的操作只可能发生在同一台机器上。而时间戳本身自带的偏序关系（happen before）在任何情况下都是成立的。这样通过时间戳，我们就可以解决并发冲突了，定义了一种全序关系。
由上面，我们可以知道，CAS利用的是回滚的方式解决并发冲突。
VECTOR CLOCK
其实vector clock也是这个道理，vector clock是利用时间戳定义一个偏序关系，目的只是用于检测并发冲突。由于其定义的关系是偏序，所以冲突发生时，其没有解决办法，只能交由客户端（提出请求的客户）进行裁决。
矢量时钟实际上是一个(node,counter)对列表(即(节点，计数器)列表)。矢量时钟是与每个对象的每个版本相关联。通过审查其向量时钟，我们可以判断一个对象的两个版本是平行分枝或有因果顺序。如果第一个时钟对象上的计数器在第二个时钟对象上小于或等于其他所有节点的计数器，那么第一个是第二个的祖先，可以被人忽略。否则，这两个变化被认为是冲突，并要求协调。
算法执行是允许所有写入的机器维护一个counter，每次每次本机器上的事件发生会使vlaue+1并把本次操作携带，同步到其他节点，其他节点收到同步后，会将事件修改的数据进行进行版本更新。只有当所有节点上的操作A的counter都小于对应节点上操作B的counter的时候才认为他们具有明确的happen-before,否则视为冲突.
网上的一个例子：
（机器号，版本号）
1.“用户A在N1节点上设置x=100” ------------ 节点N1生成向量<(N1,1)>
2.“用户A在N1节点上设置x=200” ------------ 节点N1生成向量<(N1,2)>
3.“N1将x=200传播到N2” ----------- 节点N2生成向量<(N1,2)>
4.“N1将x=200传播到N3” ----------- 节点N3生成向量<(N1,2)>
5.“用户A在N2节点上设置x=300” ------------ 节点N2生成向量<(N1,2), (N2,1)>
6.“用户B在N3节点上设置x=400” ----------- 节点N3生成向量<(N1,2), (N3,1)>
此时各个节点的向量
N1： <(N1,2)>
N2：<(N1,2), (N2,1)>
N3：<(N1,2), (N3,1)>
此处，N2和N3是不可比较的，因为他们有并行冲突！即，N2上面的所有操作的counter（版本号），不都小于或大于N3节点上所有操作的counter。
上面就是向量时钟的的工作过程，其实，上面的过程也是利用了同一台机器上事件是可以通过时间戳确定事件发生的因果（先后）顺序的。我们只关心同一台机器上发生事件的先后关系，因为时间戳本身是表示不了不同机器上的并发时间的关系。如果不同机器之间有事件并发发生（注意这里的并发指的是通过时间戳无法确定先后关系），也就是出现了一个节点上面的所有操作的counter（版本号），不都小于或大于另一个节点上所有操作的counter，此时根据向量时钟的偏序关系，这是不可比较的，也就是并行发生的。