线程并发问题和进程间并发问题都可以通过分布式锁解决,但是很大题小做。非常消耗资源。
分布式锁最适合解决分布式情况下的多进程并发问题。
分布式锁本身lock和unlock耗时是us微秒级,在理想情况下大概可支持每秒1000个原子操作,300多个从分配到释放流程结束。
场景:采用分布式锁1秒间秒杀1000件商品,如果性能出现了问题,应该先排查业务逻辑。
1:一个线程里lock成功,unlock失败?
Q: 日志里报了多次的unlock失败,什么原因?
A: 之前的代码里try finally模式的unlock,是否lock成功都会unlock。
Q:加上了lock成功才unlock,还是有unlock失败?
A:这是锁住的逻辑耗时太多,超过了expire的时间,自动释放锁了。
2:有哪些抓手可以确定哪些逻辑耗时太多?
Q: 日志可以吗?
A: 目前的日志可以找到有问题的traceId,看整个链路都进行了哪些处理,大概几步时间消耗,但是具体sql的耗时分析没有
Q:CAT监控可以吗?
A:CAT监控可以找到耗时多的几个请求,看到每条sql的耗时情况,超过5秒的sql都是需要注意的
3:锁内部要避免的操作有哪些?
Q:逻辑上的?
A:避免显式的和隐式的循环。如:.stream().
Q:性能上的?
A:数据查询的条件是否建立了索引
4:循环获取锁的时间间隔怎么算合理?
A:获取锁与服务器通讯时间可以忽略不计,在跨机房的情况下理论上也不超过2ms
所以锁可以获取到的时间=一段分布式锁中间执行时间平均值
5:获取锁重试次数怎么算合理?
A:获取锁的重试次数理论上如果获取锁时间间隔合理的话,就与允许的同时扩容最大容器数接近,不大于最大容器数20%。
6:多次获取锁失败原因有哪些?
A:如果不符合可获取到的时间间隔计算,则考虑是否特定场景下有耗时操作。具体可参考 3:锁内部要避免的操作有哪些?
7:加了分布式锁还出现了并发问题?
Q:锁获取失败是怎么处理的?
A:锁获取失败并没有按请求失败处理,而是在无锁状态下继续执行会引发并发问题。
Q:锁获取成功了还是出现并发问题?
A:执行太慢了,超过了expire的时间锁失效了。