分布式编程下的CAS
最近在项目中发现两个概率性数据被覆盖的问题，跟踪原因后发现都是由于并发引起的。解决方案都是更新数据时对比数据是否发生变化，如果没有发生变化，那么才更新数据。这种做法就是CAS（Compare And Set），下文是对CAS应用思想的思考。
在谈CAS之前先例举上面说到的一个问题，问题如下：低概率会发生人工翻译的数据被机器翻译覆盖现象。在业务场景中人工翻译数据优先级比机器翻译高，为什么人工翻译数据还是会被机器翻译覆盖呢？
在多用户环境下，会出现两种典型的并发问题：丢失更新、脏读。上述问题就是丢失更新问题。
并发控制有两种机制:
悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。
乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。
CAS就是乐观锁的一种应用场景，简单的原理就是：在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。
上述翻译的场景中人工翻译数据会被机器覆盖，是因为机器翻译先读取数据A进行翻译，还没有翻译完成就被人工修改为B，当机器翻译完后又把数据更新为了A。那么只要在机器翻译完后更新数据时，判断数据是否为A。如果为A才更新数据，如果不为A，则不更新数据。这样就可以解决这个概率产生的问题。
其实CAS只是一个很简单的思想，理解起来也非常容易，关键在于在复杂且干扰性非常大的应用场景使用CAS的思想。