扯扯犊子
并发知识点总结:
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,获取锁更安全