秒杀系统项目实战（十二）秒杀系统架构方案之使用redis做分布式锁有什么缺陷？

我们知道在秒杀系统里面，都会涉及到分布式锁。对于现在的研发人员，一提起分布式锁，大家首先想到的就是redis的分布式锁。诚然redis里面有提供分布式锁的作用。但是在大型秒杀环境下，使用redis作为分布式锁真的好吗？我们来分析一下。

假设现在的秒杀场景是：100W的请求进来，线上使用redis集群环境来操作分布式锁，redis的架构是 master-slave+ sentinel模式。假设我们现在进行了分布式锁加锁。那么有没有可能出现这样一种情况呢？

1、线程1向redis的master发起加锁请求，加锁成功了。
2、此时redis的master还未把锁信息同步给slave，结果redis的master挂了。
3、sentinel进行介入，经过选举，把slave变成了master。
4、线程2向redis的mater发起加锁请求，由于slave没有之前的加锁信息，此时slave也加锁成功了。

上面这个流程我们会发现 线程1和线程2都同时加锁成功了，这时候怎么办？是不是数据就会出现问题。像上面100W的请求打进系统，此时落到redis的请求量会非常大，redis出现主从切换的可能性就变得非常高。在秒杀系统里面，是不是就会出现超卖的情况了？所以大家一定要根据实际情况考虑这个秒杀系统的设计，特别是这种分布式锁，因为实际的情况和理论上相比还是会有一些差异。千万不要在关键时刻出问题。

最后总结下：

1、redis在单机的环境下分布式锁是非常可靠的。

2、在redis集群的环境下，使用redis的分布式锁，特别是在超大型的秒杀系统里面，由于集群数据同步的时延，很容易造成问题。

3、作为生产环境大型秒杀系统的分布式锁替代，可以考虑使用ETCD。