如何解决电商网站超卖现象（网站秒杀抢购思路）

 如何解决电商网站超卖现象（网站秒杀抢购思路）

悲观锁:一段执行逻辑加上悲观锁,不同线程同时执行时,只能有一个线程执行,其他的线程在入口处等待,直到锁被释放.

乐观锁:一段执行逻辑加上乐观锁,不同线程同时执行时,可以同时进入执行,在最后更新数据的时候要检查这些数据是否被其他线程修改了(版本和执行初是否相同),没有修改则进行更新,否则放弃本次操作.

从解释上可以看出,悲观锁具有很强的独占性,也是最安全的。而乐观锁很开放,效率高,安全性比悲观锁低,因为在乐观锁检查数据版本一致性时也可能被其他线程修改数据。

1、常用方法

（1）乐观锁：大多数是基于数据版本(version)的记录机制实现的。即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表添加一个”version”字段来实现读取出数据时，将此版本号一同读出，之后更新时，对此版本号+1。此时，将提交数据的版本号与数据库表对应记录版本号进行比对，如果提交的数据版本号大于数据当前版本号，则予以更新，否则认为是过去数据。

（2）在Redis中，使用watch命令实现乐观锁(watch key): 
watch命令会监视给定的key，当exec时，如果监视的key从调用watch后发生过变化，则事务会失败，也可以调用wathc多长监视多个key。这样就可以对指定key加乐观锁了。注意watch的可以是对整个连接有效的。事务也一样。如果连接断开，监视和事务都会被自动清除。当然exec，discard，unwatch命令都会清除连接中的所有监视。

2、redis使用watch秒杀抢购思路

1、使用watch，采用乐观锁 
2、不使用悲观锁，因为等待时间非常长，响应慢 
3、不使用队列，因为并发量会让队列内存瞬间升高

WATCH命令

监控指定键，若被监控的键在以下事务执行前被修改，则包含对此键有操作动作的事务不执行，返回nil。

MULTI：开启事务

EXEC：执行事务

DISCARD：取消事务

WATCH：监视事务中的键变化，一旦有改变则取消事务。

------------------------------------------------------------------------------------------------------------------------------------------------------------------------

127.0.0.1:6379[5]> get k

"20"

127.0.0.1:6379[5]> set k 30

OK

127.0.0.1:6379[5]>watch k

OK

127.0.0.1:6379[5]> set k 40

OK

127.0.0.1:6379[5]> multi

OK

127.0.0.1:6379[5]> set k 50

QUEUED

127.0.0.1:6379[5]> exec

(nil)

127.0.0.1:6379[5]> get k

"40"
------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Redis对事物的支持目前比较简单。Redis只能保证一个client发起的事务中的命令可以连续的执行,但后面命令出错前面不会回滚。而中间不会插入其他client的命令。当一个client在找一个连续中发出multi命令时，这个链接会进入一个事务上下文，该链接后续的命令不会立即执行，而是先放到队列中，当执行exec命令是，redis会顺序的执行队列中的所有命令。当如果队列中有命令错误，不会回滚。