Home > Common Problem > What are the three implementation methods of distributed locks?

What are the three implementation methods of distributed locks?

青灯夜游
Release: 2023-02-13 13:51:31
Original
47096 people have browsed it

Three ways to implement distributed locks: 1. Implement distributed locks based on database; 2. Implement distributed locks based on cache (Redis, etc.); 3. Implement distributed locks based on Zookeeper. From a performance perspective (from high to low): "Cache mode > Zookeeper mode > = Database mode".

What are the three implementation methods of distributed locks?

The operating environment of this article: Windows system, redis 6.0, thinkpad t480 computer.

Three ways to implement distributed locks:

1. Implement distributed locks based on database;
2. Implement distributed locks based on cache (Redis, etc.) ;
3. Implement distributed locks based on Zookeeper;

1. Implement distributed locks based on database

1. Pessimistic lock

Use select...where...for update exclusive lock

Note: Other additional functions are basically the same as implementation one. What needs to be noted here is "where name=lock", the name field must be indexed, Otherwise the table will be locked. In some cases, such as if the table is not large, the MySQL optimizer will not use this index, causing table lock problems.

2. Optimistic lock

The biggest difference between the so-called optimistic lock and the previous one is that it is based on the CAS idea. It is not mutually exclusive, does not cause lock waiting and consumes resources, and is considered non-existent during the operation. Concurrency conflicts can only be detected after the update version fails. Our rush sales and flash sales use this implementation to prevent overselling.
Implement optimistic locking by adding an incremental version number field

Second, implement distributed locking based on cache (Redis, etc.)

1. Introduction to using commands:
(1) SETNX
SETNX key val: If and only if the key does not exist, set a string with key val and return 1; if If the key exists, do nothing and return 0.
(2)expire
expire key timeout: Set a timeout for the key, the unit is second. After this time, the lock will be automatically released to avoid deadlock.
(3) delete
delete key: delete key

When using Redis to implement distributed locks, these three commands are mainly used.

2. Implementation idea:
(1) When acquiring a lock, use setnx to lock it, and use the expire command to add a timeout period to the lock. If the time is exceeded, the lock will be automatically released. The value of the lock It is a randomly generated UUID, which is used to judge when releasing the lock.
(2) When acquiring the lock, also set a timeout period for acquisition. If this time is exceeded, acquisition of the lock will be given up.
(3) When releasing a lock, use the UUID to determine whether it is the lock. If it is the lock, execute delete to release the lock.

3. Simple implementation code of distributed lock:

 /**
    * 分布式锁的简单实现代码    */
   public class DistributedLock {
   
       private final JedisPool jedisPool;
   
       public DistributedLock(JedisPool jedisPool) {
          this.jedisPool = jedisPool;
      }
  
      /**
       * 加锁
       * @param lockName       锁的key
       * @param acquireTimeout 获取超时时间
       * @param timeout        锁的超时时间
       * @return 锁标识
       */
      public String lockWithTimeout(String lockName, long acquireTimeout, long timeout) {
          Jedis conn = null;
          String retIdentifier = null;
          try {
              // 获取连接
              conn = jedisPool.getResource();
              // 随机生成一个value
              String identifier = UUID.randomUUID().toString();
              // 锁名,即key值
              String lockKey = "lock:" + lockName;
              // 超时时间,上锁后超过此时间则自动释放锁
              int lockExpire = (int) (timeout / );
  
              // 获取锁的超时时间,超过这个时间则放弃获取锁
              long end = System.currentTimeMillis() + acquireTimeout;
              while (System.currentTimeMillis()  results = transaction.exec();
                     if (results == null) {
                         continue;
                     }
                     retFlag = true;
                 }
                 conn.unwatch();
                 break;
             }
         } catch (JedisException e) {
             e.printStackTrace();
         } finally {
             if (conn != null) {
                 conn.close();
             }
         }
         return retFlag;
     }
 }
Copy after login

4. Test the distributed lock just implemented

In the example, 50 threads are used to simulate a flash sale of a product, use -operator to reduce goods, and whether it is locked can be seen from the order of the results.

Simulate the flash sale service, configure the jedis thread pool in it, and pass it to the distributed lock during initialization for its use.

public class Service {

    private static JedisPool pool = null;

    private DistributedLock lock = new DistributedLock(pool);

    int n = 500;

    static {
        JedisPoolConfig config = new JedisPoolConfig();
        // 设置最大连接数
        config.setMaxTotal(200);
        // 设置最大空闲数
        config.setMaxIdle(8);
        // 设置最大等待时间
        config.setMaxWaitMillis(1000 * 100);
        // 在borrow一个jedis实例时,是否需要验证,若为true,则所有jedis实例均是可用的
        config.setTestOnBorrow(true);
        pool = new JedisPool(config, "127.0.0.1", 6379, 3000);
    }

    public void seckill() {
        // 返回锁的value值,供释放锁时候进行判断
        String identifier = lock.lockWithTimeout("resource", 5000, 1000);
        System.out.println(Thread.currentThread().getName() + "获得了锁");
        System.out.println(--n);
        lock.releaseLock("resource", identifier);
    }
}
Copy after login

Simulate threads for flash kill service;

public class ThreadA extends Thread {
    private Service service;

    public ThreadA(Service service) {
        this.service = service;
    }

    @Override
    public void run() {
        service.seckill();
    }
}

public class Test {
    public static void main(String[] args) {
        Service service = new Service();
        for (int i = 0; i <p>The results are as follows, the results are in order:</p><p><img src="https://img.php.cn/upload/article/000/000/024/0c1cb2ceea4c8cbfa184228a02822f99-1.png" alt="What are the three implementation methods of distributed locks?"></p>##If you comment out the use of locks Part: <p></p><pre class="brush:php;toolbar:false">public void seckill() {
    // 返回锁的value值,供释放锁时候进行判断
    //String indentifier = lock.lockWithTimeout("resource", 5000, 1000);
    System.out.println(Thread.currentThread().getName() + "获得了锁");
    System.out.println(--n);
    //lock.releaseLock("resource", indentifier);
}
Copy after login
As can be seen from the results, some are performed asynchronously:

What are the three implementation methods of distributed locks?

Three, distributed based on Zookeeper Lock

ZooKeeper is an open source component that provides consistent services for distributed applications. Internally it is a hierarchical file system directory tree structure, which stipulates that there can only be one in the same directory. Unique file name. The steps to implement distributed locks based on ZooKeeper are as follows:

(1) Create a directory mylock;

(2) Thread A creates a temporary sequence node in the mylock directory if it wants to acquire the lock;
(3 ) Get all the child nodes in the mylock directory, and then get the sibling nodes smaller than itself. If it does not exist, it means that the current thread sequence number is the smallest and the lock is obtained;
(4) Thread B gets all the nodes and determines that it is not the smallest Node, set to monitor the node smaller than itself;
(5) After thread A finishes processing, delete its own node, thread B listens to the change event, determines whether it is the smallest node, and if so, obtains the lock.

Here we recommend Curator, an Apache open source library, which is a ZooKeeper client. The InterProcessMutex provided by Curator is the implementation of distributed locks. The acquire method is used to acquire locks, and the release method is used to release locks.

The implementation source code is as follows:

import lombok.extern.slf4j.Slf4j;
import org.apache.commons.lang.StringUtils;
import org.apache.curator.framework.CuratorFramework;
import org.apache.curator.framework.CuratorFrameworkFactory;
import org.apache.curator.retry.RetryNTimes;
import org.apache.zookeeper.CreateMode;
import org.apache.zookeeper.data.Stat;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.stereotype.Component;

/**
 * 分布式锁Zookeeper实现
 *
 */
@Slf4j
@Component
public class ZkLock implements DistributionLock {
private String zkAddress = "zk_adress";
    private static final String root = "package root";
    private CuratorFramework zkClient;

    private final String LOCK_PREFIX = "/lock_";

    @Bean
    public DistributionLock initZkLock() {
        if (StringUtils.isBlank(root)) {
            throw new RuntimeException("zookeeper 'root' can't be null");
        }
        zkClient = CuratorFrameworkFactory
                .builder()
                .connectString(zkAddress)
                .retryPolicy(new RetryNTimes(2000, 20000))
                .namespace(root)
                .build();
        zkClient.start();
        return this;
    }

    public boolean tryLock(String lockName) {
        lockName = LOCK_PREFIX+lockName;
        boolean locked = true;
        try {
            Stat stat = zkClient.checkExists().forPath(lockName);
            if (stat == null) {
                log.info("tryLock:{}", lockName);
                stat = zkClient.checkExists().forPath(lockName);
                if (stat == null) {
                    zkClient
                            .create()
                            .creatingParentsIfNeeded()
                            .withMode(CreateMode.EPHEMERAL)
                            .forPath(lockName, "1".getBytes());
                } else {
                    log.warn("double-check stat.version:{}", stat.getAversion());
                    locked = false;
                }
            } else {
                log.warn("check stat.version:{}", stat.getAversion());
                locked = false;
            }
        } catch (Exception e) {
            locked = false;
        }
        return locked;
    }

    public boolean tryLock(String key, long timeout) {
        return false;
    }

    public void release(String lockName) {
        lockName = LOCK_PREFIX+lockName;
        try {
            zkClient
                    .delete()
                    .guaranteed()
                    .deletingChildrenIfNeeded()
                    .forPath(lockName);
            log.info("release:{}", lockName);
        } catch (Exception e) {
            log.error("删除", e);
        }
    }

    public void setZkAddress(String zkAddress) {
        this.zkAddress = zkAddress;
    }
}
Copy after login
Advantages: It has the characteristics of high availability, reentrancy, and blocking locks, which can solve the problem of failure deadlock.

Disadvantages: Because nodes need to be created and deleted frequently, the performance is not as good as Redis.

Four, comparison

Database distributed lock implementationDisadvantages:

1. The db operation performance is poor, and there is a risk of table locking
2. After the non-blocking operation fails, polling is required, occupying CPU resources;
3. No commit for a long time or polling for a long time , may occupy more connection resources

Redis (cache) distributed lock implementation
Disadvantages:

1. The expiration time of lock deletion failure is difficult to control
2. Non-blocking, after the operation fails, polling is required and CPU resources are occupied;

ZK distributed lock implementation
Disadvantages: The performance is not as good as redis implementation, the main reason is that writing All operations (lock acquisition and lock release) need to be performed on the leader and then synchronized to the follower.

In short: ZooKeeper has good performance and reliability.

From the perspective of ease of understanding (from low to high) Database > Cache > Zookeeper

From the perspective of implementation complexity (from low to high) Zookeeper >= Cache > ; Database

From a performance perspective (from high to low) Cache> Zookeeper >= Database

From a reliability perspective (from high to low) Zookeeper > Cache> Database

Related recommendations: "Programming Teaching"

The above is the detailed content of What are the three implementation methods of distributed locks?. For more information, please follow other related articles on the PHP Chinese website!

Related labels:
source:php.cn
Statement of this Website
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Popular Tutorials
More>
Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template