Redis实战篇（二）：秒杀问题及其优化和分布式锁与Redission
优惠券秒杀
今天继续来学习Redis实战中的优惠券秒杀场景下碰到的问题和解决的方案
+
Redis实战篇（二）：秒杀问题及其优化和分布式锁与Redisson
优惠券秒杀
今天继续来学习Redis实战中的优惠券秒杀场景下碰到的问题和解决的方案
全局唯一ID
优惠券在购买后会一个购买优惠券的订单ID，这个ID是要返还给用户的。这个ID也会被用于用户退款，或者商家自己查询到底被谁买了，那么问题就来了：
- 如果使用MySQL数据库的自增id，那么总是从1开始，这样的数字过于简短，有太明显的规律，易于被用户和商业对手猜测出购买的数量等等 @@ -374,15 +374,215 @@
- 利用Redis集群保证高可用和高并发
利用Lua脚本保证释放锁的原子性
分布式锁-Redission
Redisson: Easy Redis Java client and Real-Time Data Platform是 Redis Java 客户端和实时数据平台。
+分布式锁-Redisson
Redisson: Easy Redis Java client and Real-Time Data Platform是 Redis Java 客户端和实时数据平台。
Redisson 对象提供了关注点分离，使您可以专注于数据建模和应用程序逻辑。
-基于setnx实现的分布式锁存在的问题
重入问题：重入问题是指 获得锁的线程可以再次进入到相同的锁的代码块中，可重入锁的意义在于防止死锁，比如HashTable这样的代码中，他的方法都是使用synchronized修饰的，假如他在一个方法内，调用另一个方法，那么此时如果是不可重入的，不就死锁了吗？所以可重入锁他的主要意义是防止死锁，我们的synchronized和Lock锁都是可重入的。
+基于setnx实现的分布式锁存在的问题
重入问题：获得锁的线程可以再次进入到相同的锁的代码块中，可重入锁的意义在于防止死锁，比如HashTable这样的代码中，他的方法都是使用synchronized修饰的，假如他在一个方法内，调用另一个方法，那么此时如果是不可重入的，不就死锁了吗？所以可重入锁他的主要意义是防止死锁，我们的synchronized和Lock锁都是可重入的。
不可重试：是指目前的分布式只能尝试一次，我们认为合理的情况是：当线程在获得锁失败后，他应该能再次尝试获得锁。
超时释放：我们在加锁时增加了过期时间，这样的我们可以防止死锁，但是如果卡顿的时间超长，虽然我们采用了lua表达式防止删锁的时候，误删别人的锁，但是毕竟没有锁住，有安全隐患
主从一致性： 如果Redis提供了主从集群，当我们向集群写数据时，主机需要异步的将数据同步给从机，而万一在同步过去之前，主机宕机了，就会出现死锁问题。
-使用现成的分布式锁工具Redission可以很好的解决这些问题
+使用现成的分布式锁工具Redisson可以很好的解决这些问题
双 手 合 十 成 为 自 己 的 神
自 己 所 信 念 的 即 是 信 仰
微 信 号 ： L I J J J W E I
Q Q 号 ： 2 8 4 8 5 2 7 4 8 5
双 手 合 十 成 为 自 己 的 神
自 己 所 信 念 的 即 是 信 仰
微 信 号 ： L I J J J W E I
Q Q 号 ： 2 8 4 8 5 2 7 4 8 5