同是memcached，为什么Redis放弃了CAS
首先我们看看CAS在memcached里完成了怎样的功能：
引用
when the client performs a GET the server actually returns two values:
thevalueofthekeyitselfandaninteger,thatiscalleda
"cas_token"inmemcachedslang,butactuallyit'sa64bitinteger
thatyoucanthinkasa"version"ofthevaluecontainedinsideakey.
Everytimeakeyissettoanotherthingthiscounterincrements.
memcached服务器端储存的是些key-value对，每次客户端get(key)时server返回了两个东西，一个是我们想要的value，还有一个叫“cas_token”，说白了了就是个64位的版本号，每次value被更新时cas_token就会++，看到++估计在座的各位就会形成条件反射了，没错、CAS这时候就可以登场了！
在此我想先谈谈CAS，天下武功唯快不破，CAS亦是如此，不加锁的前提下假设要改变的变量是最干净的(现代CPU能侦测到其他线程对指定变量的变更)，成功的话就更新，失败则快速返回并再次尝试更新...
然而分布式的情况下却容不得这种while(true)式的轻量级打法，引用
You will find that the lock was not obtained after you already did
一旦加锁失败，可以失败，但是你敢早点说失败吗？客户端把新的value送到服务端来供其CAS是很不容易的，尤其是在网络传输仍然是系统瓶颈的当今，最糟糕的是你一句话说失败了人家还要重来...你还不如让他在那挂起呢！alltheworktocreatethenewvalue,issuedandtransferedthenew
value,andsoon...
还有一点，CAS比他的前辈悲观锁改善了很多，但是人品不好的线程被饿死的情况仍不能避免，然而至少一点，每个来抢锁的线程都是平等的，没有时延，但是分布式情况下就会彻底打破这种平衡，如果某台客户端机器因为质量问题而发送时延过大，那么他对服务端指定key里面的value的更新就永远别想提交了...
至于redis拿什么方案来替代CAS的，我仍然在探索当中...但至少有一点，memcached不宜CAS
相关推荐
manongxiaomei 2020-07-05
zhangxiaocc 2020-04-29
zmzmmf 2020-02-09
xiaoemo0 2019-12-17
middleware0 2019-12-04
清溪算法 2019-11-21
chengqiang00 2019-10-30
sdwang 2019-06-10
Mical0 2014-05-29
84086320 2012-04-18
beiya 2016-10-24
82463165 2014-06-28
laiwanwanyihao 2013-10-28
秦怀卓 2012-05-28
凯哥Java 2012-03-15