Shulou(Shulou.com)06/03 Report--

Spring-boot-klock-starter

The distributed lock spring-boot starter component based on redis makes it extremely simple for the project to have distributed locking capability, and supports spring related projects such as spring boot, spirng mvc and so on.

Quick start

Pring boot project access

Add lock starter component dependencies

Cn.keking spring-boot-klock-starter 1.3-RELEASE2.application.properties configuration redis link: spring.klock.address=127.0.0.1:6379

3. Add @ Klock to the method that requires a distributed lock, such as:

The service key specified by the lock is supported, which is locked like the input parameter of one method ID, and the other is released. The acquisition of business key supports Spel, which is used as follows

Spring mvc project access

Other steps are the same as spring boot steps, and you only need to add KlockAutoConfiguration class scanning to the spring-xx.xml configuration, such as:

Use parameter description

Configuration parameter description

Spring.klock.address: redis link address spring.klock.password: redis password spring.klock.database: redis data index spring.klock.waitTime: get the lock maximum blocking time (default: 60, unit: second) spring.klock.leaseTime: acquired automatic release time after lock (default: 60, unit: second) spring.klock.cluster-server.node-addresses: redis cluster configuration such as 127.0.0.1 spring.klock.password 7000127.0.0.1 redis 7001 Just choose one of 127.0.0.1:7002spring.klock.address and spring.klock.cluster-server.node-addresses.

@ Klock annotation parameter description

@ Klock can mark four parameters, which function as follows: the name of name:lock, which corresponds to the key value of redis. The default is: class name + method name lockType: type of lock, which is currently supported (reentrant lock, fair lock, read-write lock). The default is: fair lock waitTime: get the maximum waiting time of the lock. The default is: 60s. At the same time, you can also configure leaseTime through spring.klock.waitTime: the time when the lock is automatically released after the lock is obtained. The default is: 60s. At the same time, you can also configure lockTimeoutStrategy: the processing policy of locking timeout through spring.klock.leaseTime, which can be configured as the processing policy of no processing, fast failure and blocking waiting. The default policy is not to handle customLockTimeoutStrategy: customize the processing policy of locking timeout. You need to specify the method name of the custom processing method and keep the input parameters consistent. ReleaseTimeoutStrategy: the processing policy in which the held lock has timed out when the lock is released. It can be configured as a processing policy with no processing and quick failure. The default policy is not to handle customReleaseTimeoutStrategy: when you customize the lock release, you need to specify the method name of the custom processing method and keep the input parameters consistent. Lock timeout description

Because distributed locks are implemented based on redis, if used improperly, you will encounter the problem of lock timeout in the following scenarios:

Lock timeout handling strategy (LockTimeoutStrategy):

NO_OPERATION does no processing and continues to execute the business logic.

FAIL_FAST failed quickly, KlockTimeoutException will be thrown

KEEP_ACQUIRE blocks and waits until the lock is acquired, but after too many attempts, it stops acquiring the lock and reports an error, most likely a deadlock.

Custom (customLockTimeoutStrategy) needs to specify the method name of the custom processing method, and keep the input parameters consistent. After specifying the custom processing method, it will override the above three policies and block the operation of business logic.

Timeout handling policy when releasing locks (ReleaseTimeoutStrategy):

NO_OPERATION does no processing and continues to execute the business logic.

FAIL_FAST failed quickly, KlockTimeoutException will be thrown

Custom (customReleaseTimeoutStrategy) needs to specify the method name of the custom processing method, and keep the input parameters consistent. After specifying the custom processing method, the above two policies will be overridden. When the custom processing method is executed, the business logic has been executed, and it will be executed before the method returns and before the throw exception.

It is hoped that users will clearly realize that there is no point in setting a timeout policy for releasing locks if there is no effective setting for lock timeouts.

Use cases for integrated lock timeout policies in the test module

Under the engineering test module, it is the test module of distributed lock. You can quickly experience the effects of distributed locks.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.