zookeeper分布式锁之接口优化

最近在项目中加入了分布式锁机制，出现了一些性能问题，于是对接口进行了一系列优化。

优化之前

优化之后

之前没有压测，加入分布式缓存后遇到性能问题

 

1、无超时时间遇到的问题

interProcessMutex.acquire()

使用默认获取锁的方法，不传入超时时间，会导致一个请求在没有处理完释放锁之前，所有新的请求（新线程）都在等待，线程不断积累，将内存耗尽，应用拒绝服务

 

2、设置超时时间

interProcessMutex.acquire(1000,TimeUnit.MILLISECONDS)

设置超时时间，在有限时间内如果获取不到锁，会自动放弃，该方法返回一个boolean类型作为获取锁是否成功的标记

 

3、分布式锁的性能问题

对同一个key来加锁。这样会导致对同一个业务的请求处理，就必须串行化，一个接一个的处理。

基于分布式锁串行化处理，导致没法同时处理的大量的请求。多实例部署在分布式锁的作用下变成了单实例的效果，如果每个请求需要耗时50ms，那么1s内最多处理20次请求，规模较小的电商系统完全可以满足，但是如果你的用户量比较大，假设qps大于了1000，这时就不得不对分布式锁做一些优化了

 

其实说出来也很简单，相信很多人看过java里的ConcurrentHashMap的源码和底层原理，应该知道里面的核心思路，就是分段加锁！

把数据分成很多个段，每个段是一个单独的锁，所以多个线程过来并发修改数据的时候，可以并发的修改不同段的数据。不至于说，同一时间只能有一个线程独占修改ConcurrentHashMap中的数据。

 

回到具体业务，我们将整体的分布式锁拆成若干个，基于商家维度加锁，这样在访问不同商家的时候就可以并发处理了

                       

 

4、异常处理

如果超时仍然没有获取锁，就要释放线程资源，在程序中给你必要提示，打印日志，保留现场是个好习惯，最好加入监控告警中，能够及时发现解决。

5、超时时间

获取锁超时时间的设置也是比较重要的，如果超时时间过小，会出现大部分请求直接进入异常处理的降级方法，返回不正确的数据，我的做法是预先压测，确定分布式锁控制的逻辑代码执行时间，然后让锁超时时间略高于代码执行时间。

华丽的分割线-------------------------------------------------------以上是关于分布式锁的优化，但是压测结果还是不够理想

很明显，是我的业务代码在逻辑上还有很多优化空间

6、for循环里面查库是件很不理智的事情

ding，这里有个循环里面查询数据库操作，由于产品在业务就这样规定的规定，所以不能修改逻辑，于是在这个查库接口里面添加缓存层，减少对db的访问，提高查询速度，这个字段数据对准确性要求也不太高，但也不能差太多，所以将缓存失效时间为5*60s就可以啦

然后再压测一遍，效果明显，平均耗时已经降了一大半

 

7、在sql查询中尽量缩小返回数据集合的范围

ding，上面既然是循环，那么我们是不是可以考虑从减小集合的范围入手，然后我们发现remove操作的字段就是数据表中的字段，于是我们把remove操作的字段筛选转移到sql中直接过滤调，集合在遍历前便减小了好多，bingo，优化结束，谢谢阅读