一、基于数据库实现分布式锁

  1、乐观锁方式：

实现方案：通常利用数据库表中的版本号字段来实现。在获取数据时，同时获取版本号。在更新数据时，检查版本号是否与获取时一致，如果一致则进行更新，并将版本号加一。如果不一致，则说明数据在获取后被其他事务修改过，当前事务需要回滚或重试。

举例：有一个商品库存表，包含商品数量和版本号字段。当一个事务要减少库存时，先查询当前商品的数量和版本号。然后在更新库存时，检查版本号是否与查询时一致。如果一致，则更新库存数量并将版本号加一；如果不一致，则说明在查询和更新之间有其他事务修改了库存，当前事务需要重试。

优点：实现相对简单，利用了数据库的事务机制

缺点：在高并发场景下，可能会导致大量的事务重试，影响性能。

2、悲观锁方式：

实现方案：通过数据库的排他锁来实现。在执行关键业务逻辑之前，使用数据库的事务和排他锁机制，对要操作的数据行进行加锁。其他事务在尝试获取该锁时会被阻塞，直到持有锁的事务完成并释放锁。

举例：在一个银行转账系统中，当一个事务要从账户 A 向账户 B 转账时，可以对账户 A 和账户 B 的记录行加排他锁，确保在转账过程中，其他事务不能同时对这两个账户进行操作。

优点： 是能够确保在同一时间只有一个事务能够操作锁定的数据，避免了并发冲突。

缺点：是会降低系统的并发性能，特别是在长时间持有锁的情况下，可能会导致其他事务的等待时间过长。

二、基于 Redis 实现分布式锁

1、使用 SETNX 命令：

实现方案: Redis 的 SETNX（set if not exists）命令可以在指定的 key 不存在时，设置该 key 的值。利用这个特性，可以将一个特定的 key 作为锁，当一个客户端要获取锁时，使用 SETNX 命令尝试设置该 key。如果设置成功，则说明该客户端获取到了锁；如果设置失败，则说明锁已经被其他客户端持有。       

import redis.clients.jedis.Jedis;

public class RedisSetNxExample {

    public static void main(String[] args) {

        // 创建 Jedis 实例连接到 Redis 服务器

        try (Jedis jedis = new Jedis("localhost", 6379)) {

            // 设置键值对，使用 SETNX 命令，如果键不存在则设置成功，返回 1；如果键已存在则不进行任何操作，返回 0

            long result = jedis.setnx("myKey", "myValue");

            if (result == 1) {

                System.out.println("键不存在，设置成功。");

            } else {

                System.out.println("键已存在，未进行设置。");

            }

            // 获取键对应的值

            String value = jedis.get("myKey");

            System.out.println("myKey 的值为：" + value);

        } catch (Exception e) {

            e.printStackTrace();

        }

    }

}

        首先尝试使用SETNX命令设置一个键值对。如果键不存在，就会设置成功并返回 1；

        如果键已存在，则不会进行任何操作并返回 0。然后获取键对应的值并打印出来。

举例：可以设置一个名为“lock”的 key，当一个客户端要执行关键业务逻辑时，使用 SETNX 命令设置“lock_key”的值为当前时间加上一个超时时间。如果设置成功，则说明该客户端获取到了锁，可以继续执行业务逻辑。在执行完业务逻辑后，删除“lock”，释放锁。如果设置失败，则说明锁已经被其他客户端持有，该客户端可以选择等待一段时间后再次尝试获取锁。

优点：实现简单，性能高。Redis 是单线程执行命令的，所以 SETNX 命令能够保证原子性。

缺点：如果客户端在获取锁后崩溃，没有及时释放锁，可能会导致死锁。为了解决这个问题，可以结合 Redis 的过期时间设置，确保锁在一定时间后自动释放。

2、使用 Redlock 算法：

实现方案: Redlock 算法是一种更可靠的基于 Redis 的分布式锁实现。它通过在多个 Redis 节点上设置锁，并且要求在大多数节点上都成功设置锁才能认为获取锁成功。当释放锁时，需要在所有设置了锁的节点上都删除锁。

举例： 假设有 6 个独立的 Redis 节点。一个客户端要获取锁时，依次向这 6 个节点发送 SETNX 命令，并设置一个超时时间。如果在超过一半的节点上（这里至少是 4 个节点）成功设置了锁，则认为获取锁成功。在执行完业务逻辑后，向所有设置了锁节点发送删除锁命令

优点：比单个 Redis 节点的锁更加可靠，能够避免单个节点故障导致的锁失效问题

缺点：实现相对复杂，需要多个独立的 Redis 节点，并且在网络延迟较高的情况下，可能会出现锁获取和释放的不一致问题。