基于Redis的分布式资源锁

随着双11,春运抢票这种业务的存在,分布式高并发成为了技术人员必须要面对的问题,那么如果保证数据的准确性呢?一般主流的方式就是加锁,保证某个时刻只有一个客户端去调用。

 

分布式锁一般有三种实现方式:

1. 数据库乐观锁;

(1)基于数据库表(普通的增删操作)

  (2) 基于数据库排他锁

2. 基于Redis的分布式锁;

  redis的基础概念: setNX(set if Not exists)  [如果不存在则set] 

   

3. 基于ZooKeeper的分布式锁。

 

以上三种操作的基本原理是不变的:用一个状态值表示锁,对锁的占用和释放通过状态值来标识。 

 

首先,为了确保分布式锁可用,我们至少要确保锁的实现同时满足以下四个条件:

  1. 互斥性。在任意时刻,只有一个客户端能持有锁。
  2. 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁,也能保证后续其他客户端能加锁。
  3. 具有容错性。只要大部分的Redis节点正常运行,客户端就可以加锁和解锁。
  4. 解铃还须系铃人。加锁和解锁必须是同一个客户端,客户端自己不能把别人加的锁给解了。

 

具体的代码实现请看这篇详细的文章:

http://www.cnblogs.com/0201zcr/p/5942748.html

 

推荐一篇电商秒杀的架构思路,这位作者写的太好了:

https://blog.csdn.net/bigtree_3721/article/details/72760538

 

秒杀架构划重点:

(1)将秒杀系统单独部署,甚至使用独立域名,防止秒杀系统崩溃影响正常业务

(2)页面内容静态化,读多写少的接口做好缓存

(3)将下单页面的Url作为随机数,在秒杀开始的时候才能得到

(4)前端控制请求发送

(5)采用最少连接的负载均衡算法

(6)拍下减库存比付款减库存用户体验更好一些

(7)数据库采用乐观锁(采用带版本号更新)

posted @ 2018-06-26 11:24  哦克Oak  阅读(317)  评论(0编辑  收藏  举报