klock 分布式锁重大更新

开发四年只会写业务代码，分布式高并发都不会还做程序员？ >>>  

klock简介

基于redis的分布式锁spring-boot starter组件，使得项目拥有分布式锁能力变得异常简单，支持spring boot，和spirng mvc等spring相关项目。基于注解驱动，支持spring Spel，方便的定义锁的key的粒度

本次更新内容

本次更新主要新增了【锁等待超时】和【锁持有超时】的处理策略，这两个参数是为了解决分布式锁的死锁问题而设置的，而增加这两个策略是为了在极端情况下锁失效时业务能够感知并处理。

因为基于redis实现分布式锁，如果使用不当，会在以下场景下遇到锁超时的问题： 

加锁超时处理策略(LockTimeoutStrategy)：

• NO_OPERATION 不做处理，继续执行业务逻辑
• FAIL_FAST 快速失败，会抛出KlockTimeoutException
• KEEP_ACQUIRE 阻塞等待，一直阻塞，直到获得锁，但在太多的尝试后，会停止获取锁并报错，此时很有可能是发生了死锁。
• 自定义(customLockTimeoutStrategy) 需指定自定义处理的方法的方法名，并保持入参一致，指定自定义处理方法后，会覆盖上述三种策略，且会拦截业务逻辑的运行。

释放锁时超时处理策略(ReleaseTimeoutStrategy)：

• NO_OPERATION 不做处理，继续执行业务逻辑
• FAIL_FAST 快速失败，会抛出KlockTimeoutException
• 自定义(customReleaseTimeoutStrategy) 需指定自定义处理的方法的方法名，并保持入参一致，指定自定义处理方法后，会覆盖上述两种策略, 执行自定义处理方法时，业务逻辑已经执行完毕，会在方法返回前和throw异常前执行。

本次更新内容如何使用？

  @Klock(name="foo-service", waitTime=2, customLockTimeoutStrategy = "customLockTimeout")
    public String foo4(String foo, String bar) {
        try {
            TimeUnit.SECONDS.sleep(2);
            logger.info("acquire lock");
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        return "foo4";
    }

    private String customLockTimeout(String foo, String bar) {

        logger.info("customLockTimeout foo: " + foo + " bar: " + bar);
        return "custom foo: " + foo + " bar: " + bar;
    }

如上代码，在锁获取超时时，会调用用户自定义的方法。这个和分布式事务TCC的用法类似，在使用自定义处理策略时，需要提供一个方法入参和被加锁的方法一直的方法。

后记

本次更新内容，在测试模块中都已集成相关场景的使用用例，欢迎测试体验