mysql分布式锁

Question

老师 你在课程中提到
利用唯一索引实现分布式锁
出现了两个问题：
1、加锁之后 解锁之前 发生异常 导致未成功解锁 造成其他线程一直等待获取不到锁 使用定时任务定时清除
2、误删 锁的过期时间 比业务执行时间短 业务还没执行完 锁就过期了 定时任务 将锁删除
其他线程获取到锁之后 然后当前线程执行完 又释放锁 造成误删 采用uuid进行标识 每个线程
老师 我想问下 利用 select for update 悲观锁方式 存在上面两种问题吗？
比如第一个问题，线程获取到锁之后 执行到一半 服务挂掉了 事务未提交 其他线程是否也一直在等待呢？

第二个问题，悲观锁是否存在过期时间这个说法呢 如果存在 是否也存在 业务执行时间比
锁过期时间还长 导致业务还没执行完 锁就过期的问题

Answer 1

Er十七 2024-03-07 11:27:39

1、对于悲观锁的方式，也有可能出现上面的问题。服务挂掉了，没有提交事务释放锁。这时候就依赖mysql自己的异常处理了。比如事务超时机制，当事务多久没提交就回滚了。或者客户端连接超时机制，客户端挂了，连接超时也能解决。或者死锁检测机制。
2、悲观锁过期主要还是因为上述的事务超时时间，可以稍微设置的大一点。然后就是建议事务尽量小，不要产生大事务，大事务不仅仅是超时的问题，还有大事务会阻塞很多其他事务的执行，以及回滚事务的问题。

• 提问者 qq_图_0 #1

  好的  另外问下 select for update 这种加锁方式 为啥非要在事务中才生效

• Er十七 回复 提问者 qq_图_0 #2

  首先理解下锁，锁就是用来控制多个事务对同一个数据的访问的机制，防止同一份数据被多个事务同时修改，保证事务的隔离性。那设置锁之后，肯定要保证上锁的事务可以正常的访问资源，而其他事务因为锁不能修改。所以加锁肯定要有事务的。

• 提问者 qq_图_0 回复 Er十七 #3

  好的 谢谢老师  可能我有点钻牛角尖  老师从正面去解释了加锁肯定要有事务的必要性
  我理解 这只是数据库设计开发人员想的一种处理方式  比如假设没有事务  用select for update 也能加锁 就需要考虑在什么时候去释放这个锁  也许在事务提交的时候 去释放锁是最好的