分布式锁 详解

研究分布式锁有一阵子了,但是并没有一个十分完美的方案,首先我必须要承认,分布式锁在逻辑上是不可能完美无缺的。下面我总结了从小型,中型,大型网站下如果做分布式锁。

业务场景描述:
在交易的时候,防止一个用户重复下单

小型解决方案:

1.通过数据库中的一条记录的某一个字段作为版本控制,比如你取出来的最后更新时间是xxx,那你更新的时候这个字段就带上where条件。

2.专门建立一个锁表,比如
uid|order_id|status|expire
1|1232312 | 1|5
2|12123313| 0|5
每次都查询此订单是否有人下过,如此也可以解决

中型解决方案:

1.用memcache来做,原理是这样的,利用memcache的add命令的返回值不同,键存在和不存在返回值不一样,整个过程只调用了一个add命令,所以此过程是原子的,完美。
2.用redis的set然后get回来,缺点是这两个操作不是原子的,但是如果并发不高的话,这样也是没有问题的。

3. redis的cas(check and set)
WATCH mykey
val = GET mykey
val = val + 1
MULTI
SET mykey $val
EXEC

强一直性解决方案:
redlock官方插件

paxos算法:大概意识是集群中的每台机器都设置一个值,然后accuire,最后按投票的方式来决定是否获取到了,比如3天机器,2天获取到了就算获取到了锁,请参考 redis作者的redlock方案

redlock

zookeeper

使用zookeeper,这套方案有点重了,如果为了搞一套锁机制,而你们公司没有使用zk的话,是有些重了

队列异步

队列异步来解决这个事情,只要成功放入队列则提示给用户成功,后台我们自己做处理,处理失败也可以修补,此方案生产也很常见
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值