常见分布式锁1：数据库的乐观锁+version

添加一个version版本号字段。意味着每个版本只会被update一次。

主要的代码逻辑如下：

select id,version from user where id = 10001

update user set money = 100,version= version + 1 where id = 10001 and version=#{version}

当应用并发量高的时候，version值在频繁变化，则会导致大量请求失败，影响系统的可用性。

优点：

1. 适用范围广：这种方式可以应用于各种关系型数据库系统，比如 MySQL、PostgreSQL、Oracle 等等。
2. 实现简单：只需要在表中添加一个版本号字段，并且在更新记录时进行版本号比较和更新即可。
3. 易于维护：由于使用了数据库的 ACID 属性，可以保证数据的一致性和可靠性，且不需要程序员手工维护复杂的分布式锁机制。

缺点：

1. 性能瓶颈：由于每次获取分布式锁都要访问数据库，会带来一定的性能开销。尤其在高并发场景下，可能会成为系统的瓶颈，影响系统的性能。
2. 单点故障：如果数据库宕机或者出现网络故障，分布式锁将无法正常使用，可能会导致整个系统崩溃。
3. 数据库压力：由于分布式锁是通过数据库实现的，如果加锁的操作过于频繁，会增加数据库的负载，降低数据库的性能，甚至引起数据库崩溃。
4. 容易死锁：如果一个线程获取锁之后，没有及时释放锁，可能会导致其他线程无法获得锁，从而造成死锁的情况。

因此，在使用基于数据库的乐观锁实现分布式锁时，需要权衡其优缺点，并根据具体的业务场景和系统需求选择合适的锁实现方式。如果系统的性能要求较高，可以考虑使用基于 Redis、Zookeeper 等内存型或者分布式中间件来实现分布式锁，以提高系统的并发性能和可用性。同时，在使用分布式锁时也需要注意避免死锁等问题，保证系统的稳定性和可靠性。