事务:分布式锁

来自WHY42
imported>Soleverlee2016年12月19日 (一) 01:27的版本 (以“=基于数据库= =基于redis/memcached= redis分布式锁即可以结合zk分布式锁锁高度安全和memcached并发场景下效率很好的优点,其实现...”为内容创建页面)
(差异) ←上一版本 | 最后版本 (差异) | 下一版本→ (差异)

基于数据库

基于redis/memcached

redis分布式锁即可以结合zk分布式锁锁高度安全和memcached并发场景下效率很好的优点,其实现方式和memcached类似,采用setnx即可实现。需要注意的是,这里的redis也需要设置超时时间。以避免死锁。

memcached带有add函数,利用add函数的特性即可实现分布式锁。add和set的区别在于:如果多线程并发set,则每个set都会成功,但最后存储的值以最后的set的线程为准。而add的话则相反,add会添加第一个到达的值,并返回true,后续的添加则都会返回false。利用该点即可很轻松地实现分布式锁

缺点:

  1. memcached采用列入LRU置换策略,所以如果内存不够,可能导致缓存中的锁信息丢失;
  2. memcached无法持久化,一旦重启,将导致信息丢失。

基于Zookeeper

基于zookeeper瞬时有序节点实现的分布式锁,大致思想即为:每个客户端对某个功能加锁时,在zookeeper上的与该功能对应的指定节点的目录下,生成一个唯一的瞬时有序节点。判断是否获取锁的方式很简单,只需要判断有序节点中序号最小的一个。当释放锁的时候,只需将这个瞬时节点删除即可。同时,其可以避免服务宕机导致的锁无法释放,而产生的死锁问题。

可以直接采用zookeeper第三方库curator即可方便地实现分布式锁