扣减库存，redis你值得拥有

扯扯犊子

并发知识点总结：
1.秒杀，物理业务隔离，抽成单独的服务器
2.接口设计，防止洪流访问数据库。
3.加redis缓存。
4.缓存雪崩，一个请求，多个key同时失效，避免同时失效。多个请求，一个key失效。加锁
5.热点数据，缓存预热。
6.超过10w+的时候，增加本地缓存ehchache，redis作为二级缓存
7.缓存，ehcache,现在有了大堆得概念，毕竟是本地缓存，减少io，加快速度

扣减库存逻辑，你值得拥有~

1.基于DB做数据库的扣减库存
2.基于redis扣减库存   incrby，库存会存在大负数，库存弥补有问题，lua脚本实现
3.死锁问题的解决：锁的过期时间的设置，redis锁的续命机制，直接设置expire的过期时间
4.redis主从失效的问题，redission框架实现的，底层原理还是投票选举机制 
5.秒杀扣减库存，是使用redis分布式锁（while循环，自旋实现的），还是使用lua脚本呢？都可以的。通过压测，
  lua脚本性能高些，与redis交互一次，分布式锁与redis交互3次（先锁住，查询，扣减），就是网络通讯太多
6.lua脚本的优化，本身是one by one 就是一个执行完之后，下一个去执行。解决是：如果是多台主机的话，
  4台，每台有250的库存，说明了，就是引入分段锁的概念。
  redis分布式锁的，一台机器的时候的优化，其实都是竞争一把锁。现在可以竞争10把锁，一把锁是250个，
  也是分段锁的思想。
7.扣减库存操作，还可以继续优化。用户请求先到tomcat，再到处理自己的业务逻辑。自己业务逻辑处理快的
  话，tomcat线程池的利用率就高，并发量就上去了了。用户请求，从并行，改到了串行。引入本地队列，
  自己的业务逻辑里面只有判断该用户知否秒杀过了，然后放到队列，通过线程池去跑。这个也是应对洪流削峰
  填谷的思想。
8.redLock:获取锁的实际时间>锁的失效时间，无论是否过半，都会判断获取锁失败
  如果时间条件满足，那么必须过半数成功。
9.redis 分布式锁，速度快，但是不能保证一致性
  zk分布式锁，效率低，CAP保证CP,获取锁更安全