分布式缓存--序列3--原子操作与CAS乐观锁
分布式缓存--序列3--原子操作与CAS乐观锁
果子核 发表于6个月前
分布式缓存--序列3--原子操作与CAS乐观锁
  • 发表于 6个月前
  • 阅读 1
  • 收藏 1
  • 点赞 0
  • 评论 0

腾讯云 学生专属云服务套餐 10元起购>>>   

 

标签: memcachedcasrediswatch乐观锁

问题的提出

我们知道,在单机的“线程模型“中,2个线程并发修改一个变量,是需要加锁的。这个在Java并发编程–序列1已经讲过,要么是悲观锁,要么是乐观锁。 
这里写图片描述

如果把单机的线程模型,改成有客户端/服务器的进程模型。服务器可以是MySQL/Redis/Memcached任何一种,那该问题又如何解决呢?

这里写图片描述

方案1 – 单条命令的原子性

Mysql: 用类似update table set x = x + 1 where … 这样的单条语句就可解决上述问题,因为服务器内部会处理加锁的问题,不用客户端解决。

Memcached: incr/decr命令

Redis: incr/decr命令

一句话:对于这种简单的整数加减的原子操作,只要是1条命令可以搞定,就不需要客户端解决互斥问题。

方案2 – Memcached/Redis的乐观锁

上面的方案1,必须是单条命令,但该方法有很大局限性。很多时候,如果我们需要执行复杂的计算逻辑,要先把数据get出来,执行复杂逻辑,再set回去。类似下面这种:

//客户端1
x = get(key)
对x执行复杂逻辑
set(key,x)

//客户端2
x = get(key)
对x执行复杂逻辑
set(key,x)
  •  

此时有2条指令,没有办法保证2条语句的原子性,这个时候如何解决呢?

Mysql的乐观锁

关于Mysql解决上述问题的乐观锁方案,此处不再详述,参见Java并发编程-序列1

Memcached乐观锁

Memcached提供了2个命令 gets + cas。gets取出数据的时候,同时返回版本号;修改之后, cas回去的时候,会比较该版本号和服务器上最新的版本号。如果不等,则cas失败。

Redis乐观锁

Redis提供了watch命令,如下所示:

    watch  key1   //修改数据之前,执行watch,意思监听此key

    multi
    set key1  foo  //如果别的客户端在此期间修改了该key1,此处更新将失败
    exec 
  •  

方案3 – Redis事务

Redis也提供了事务的概念,但它不能回滚。如果1条命令执行错误,会继续执行下面的。

      multi

      get foo

      ...

      incr foo

      exec
  •  

此处的multi/extc,类似Mysql中的beganTransaction/endTransaction。 
另外,由于redis是单线程的,因此事务里面的多条语句执行时,不会被打断。

Memcached的多线程 vs. Redis单线程

我们都知道, Memcached内部是多线程的,而Redis是单线程的。多线程好理解,但Redis为什么要搞成单线程呢? 
个人认为,有以下几个原因: 
(1)redis有各种复杂的数据结构list, has, set。也就是说,对于一个(key, value),value的类型可以是list, hash, set。在实际应用场景中,很容易出现多个客户端对同一个key的这个复杂的value数据结构进行并发操作,如果是多线程,势必要引入锁,而锁却是性能杀手。 
相比较而言,memcached只有简单的get/set/add操作,没有复杂数据结构,在互斥这个问题上,没有redis那么严重。

(2)对于纯内存操作来说,cpu并不是瓶颈,瓶颈在网络IO上。所以即使单线程,也很快。另外,如果要利用多核的优势,可以在一个机器上开多个redis实例。

共有 人打赏支持
粉丝 3
博文 36
码字总数 7373
×
果子核
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: