基于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）数据库采用乐观锁（采用带版本号更新）