浏览 7838 次
|
精华帖 (0) :: 良好帖 (1) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-08-29
最后修改：2011-08-29
首先我们看看CAS在memcached里完成了怎样的功能：
引用 when the client performs a GET the server actually returns two values:
the value of the key itself and an integer, that is called a "cas_token" in memcached slang, but actually it's a 64 bit integer that you can think as a "version" of the value contained inside a key. Every time a key is set to another thing this counter increments. 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+token送到服务端来供其CAS是很不容易的，尤其是在网络传输仍然是系统瓶颈的当今，最糟糕的是你一句话说失败了人家还要重来...你还不如让他在那挂起呢！
all the work to create the new value, issued and transfered the new value, and so on... 还有一点，CAS比他的前辈悲观锁改善了很多，但是人品不好的线程被饿死的情况仍不能避免，然而至少一点，每个来抢锁的线程都是平等的，没有时延，但是分布式情况下就会彻底打破这种平衡，如果某台客户端机器因为质量问题(正反序列化是很能检验机器的)而发送时延过大，那么他对服务端指定key里面的value的更新就永远别想提交了... 至于redis拿什么方案来替代CAS的，我仍然在探索当中...但至少有一点，memcached不宜CAS 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2011-08-29
这个很简单嘛，你要客户端不存在一直苦等，那就加个权重咯。。。不然你怎么办。 CAS+权重并存＝ 就ok了。 个人理解，望达人指---点。。。。1.2 [] |
| 返回顶楼 | |
|
发表时间：2011-08-29
菜菜土人 写道 这个很简单嘛，你要客户端不存在一直苦等，那就加个权重咯。。。不然你怎么办。 CAS+权重并存＝ 就ok了。 个人理解，望达人指---点。。。。1.2 [] 你还没听懂我意思...：每次服务端CAS的对象是cas_token，也就是说客户端提出的更新请求是要在其知道服务端版本前提下的，CAS失败就要重新向服务端获取一次，网络压力会很大啊；我们允许的CAS反复失败并尝试是在本地环境上的，分布式情况下就得再三考虑了 原文地址http://groups.google.com/group/redis-db/browse_thread/thread/6b8ccada4d4b79fa |
| 返回顶楼 | |
|
发表时间：2011-08-29
invincibleLiu 写道 菜菜土人 写道 这个很简单嘛，你要客户端不存在一直苦等，那就加个权重咯。。。不然你怎么办。 CAS+权重并存＝ 就ok了。 个人理解，望达人指---点。。。。1.2 [] 你还没听懂我意思...：每次服务端CAS的对象是cas_token，也就是说客户端提出的更新请求是要在其知道服务端版本前提下的，CAS失败就要重新向服务端获取一次，网络压力会很大啊；我们允许的CAS反复失败并尝试是在本地环境上的，分布式情况下就得再三考虑了 原文地址http://groups.google.com/group/redis-db/browse_thread/thread/6b8ccada4d4b79fa 不是吧，我现在理解了，你担心网络？ 现在局域网是1000M，广域网都快55M的上行和12M的下行了。 一个token算2个字节吧。 对网络会有多大影响？ 我觉得可以忽略不计。 全世界66亿人一起上网请求你的token，6600,000,000一起上网，你的机房分步在全世界66个国家， 那么平均才1亿，也才100M,一个国家多个IDC地区机房，那么你的带宽100M/5吧，。这样20M/S，一秒钟也能完成阿。 不算慢吧， 那是全世界人民动员，也不慢，所以网络应该可以忽略吧， 你觉得呢？？？ 看看各位达人如何给我们新人指点1.2... |
| 返回顶楼 | |
|
发表时间：2011-08-30
最后修改：2011-08-30
菜菜土人 写道 invincibleLiu 写道 菜菜土人 写道 这个很简单嘛，你要客户端不存在一直苦等，那就加个权重咯。。。不然你怎么办。 CAS+权重并存＝ 就ok了。 个人理解，望达人指---点。。。。1.2 [] 你还没听懂我意思...：每次服务端CAS的对象是cas_token，也就是说客户端提出的更新请求是要在其知道服务端版本前提下的，CAS失败就要重新向服务端获取一次，网络压力会很大啊；我们允许的CAS反复失败并尝试是在本地环境上的，分布式情况下就得再三考虑了 原文地址http://groups.google.com/group/redis-db/browse_thread/thread/6b8ccada4d4b79fa 不是吧，我现在理解了，你担心网络？ 现在局域网是1000M，广域网都快55M的上行和12M的下行了。 一个token算2个字节吧。 对网络会有多大影响？ 我觉得可以忽略不计。 全世界66亿人一起上网请求你的token，6600,000,000一起上网，你的机房分步在全世界66个国家， 那么平均才1亿，也才100M,一个国家多个IDC地区机房，那么你的带宽100M/5吧，。这样20M/S，一秒钟也能完成阿。 不算慢吧， 那是全世界人民动员，也不慢，所以网络应该可以忽略吧， 你觉得呢？？？ 看看各位达人如何给我们新人指点1.2... CAS什么的我不大懂，但是网络方面我想补充一句……“网络延迟”和“带宽”是2个概念，楼上最好先理清楚，1G的带宽照样可能延迟3分钟，而一个资源的下载时间是（网络延迟 + 资源大小 / 带宽），一次网络交互是一个上传过程和一个下载过程，也就是（网络延迟 * 2 + 请求内容大小 / 带宽 + 返回内容大小 / 带宽），带宽的极限是将后2项无限趋近于0，但是网络延迟 * 2放在那，不是100M/s还是30T/s所能改变的 而我想楼主所要表达的意思也和网络延迟有更大的关系，一但延迟较大，那么在数据发送的过程中，cas_token变动的可能性也会加大，当延迟大到一定程度的时候，可以假定每次更新提交的传输时间中，cas_token都会发生变化，那么这个更新永远也提交不了，会不断重新获取最新数据、作更新、提交更新、cas_token检验失败、再获取最新数据这样的循环。哪怕你抱着骨干网总出口，如果延迟足够大（比如海底光缆受了外星人信号干扰，或者你可怜的骨干光缆去火星转了一圈才回来），照样可以让你的更新永远失败，造成系统“不可用”的现象 |
| 返回顶楼 | |
|
发表时间：2011-08-31
菜菜土人 写道 invincibleLiu 写道 菜菜土人 写道 这个很简单嘛，你要客户端不存在一直苦等，那就加个权重咯。。。不然你怎么办。 CAS+权重并存＝ 就ok了。 个人理解，望达人指---点。。。。1.2 [] 你还没听懂我意思...：每次服务端CAS的对象是cas_token，也就是说客户端提出的更新请求是要在其知道服务端版本前提下的，CAS失败就要重新向服务端获取一次，网络压力会很大啊；我们允许的CAS反复失败并尝试是在本地环境上的，分布式情况下就得再三考虑了 原文地址http://groups.google.com/group/redis-db/browse_thread/thread/6b8ccada4d4b79fa 不是吧，我现在理解了，你担心网络？ 现在局域网是1000M，广域网都快55M的上行和12M的下行了。 一个token算2个字节吧。 对网络会有多大影响？ 我觉得可以忽略不计。 全世界66亿人一起上网请求你的token，6600,000,000一起上网，你的机房分步在全世界66个国家， 那么平均才1亿，也才100M,一个国家多个IDC地区机房，那么你的带宽100M/5吧，。这样20M/S，一秒钟也能完成阿。 不算慢吧， 那是全世界人民动员，也不慢，所以网络应该可以忽略吧， 你觉得呢？？？ 看看各位达人如何给我们新人指点1.2... 要仔细看原文。你还是没理解他的意思。 |
| 返回顶楼 | |
|
发表时间：2011-08-31
之前的项目中用了cas，的确，有文中所说的问题，但分布式想要协作，是必须要提供一种机制的
而且，cas也不是必须要用while（true）的，完全可以加一个次数限制，这个次数完全可以根据这个操作的重要程度来决定 |
| 返回顶楼 | |
|
发表时间：2011-08-31
CurrentJ 写道 菜菜土人 写道 invincibleLiu 写道 菜菜土人 写道 这个很简单嘛，你要客户端不存在一直苦等，那就加个权重咯。。。不然你怎么办。 CAS+权重并存＝ 就ok了。 个人理解，望达人指---点。。。。1.2 [] 你还没听懂我意思...：每次服务端CAS的对象是cas_token，也就是说客户端提出的更新请求是要在其知道服务端版本前提下的，CAS失败就要重新向服务端获取一次，网络压力会很大啊；我们允许的CAS反复失败并尝试是在本地环境上的，分布式情况下就得再三考虑了 原文地址http://groups.google.com/group/redis-db/browse_thread/thread/6b8ccada4d4b79fa 不是吧，我现在理解了，你担心网络？ 现在局域网是1000M，广域网都快55M的上行和12M的下行了。 一个token算2个字节吧。 对网络会有多大影响？ 我觉得可以忽略不计。 全世界66亿人一起上网请求你的token，6600,000,000一起上网，你的机房分步在全世界66个国家， 那么平均才1亿，也才100M,一个国家多个IDC地区机房，那么你的带宽100M/5吧，。这样20M/S，一秒钟也能完成阿。 不算慢吧， 那是全世界人民动员，也不慢，所以网络应该可以忽略吧， 你觉得呢？？？ 看看各位达人如何给我们新人指点1.2... 要仔细看原文。你还是没理解他的意思。 大哥，我真的还没理解你的意思。。。  两种理解都不对，我没第三中理解了。 我反省去了。。。８８
|
| 返回顶楼 | |
