微服务下分布式锁的正确姿势

会有人问，如果我业务的执行时间超过了锁释放的时间，会怎么办呢?我们可以使用守护线程，只要我们当前线程还持有这个锁，到了10S的时候，守护线程会自动对该线程进行加时操作，会续上30S的过期时间，直到把锁释放，就不会在进行续约了，开启一个子线程，原来时间是N，每隔N/3，在去续上N

关注点：

1. key，是我们的要锁的目标，比如订单ID。
2. driverId 是由我们的商品ID，它要保证在足够长的一段时间内在所有客户端的所有获取锁的请求中都是唯一的。即一个订单被一个用户抢。
3. NX表示只有当orderId不存在的时候才能SET成功。这保证了只有第一个请求的客户端才能获得锁，而其它客户端在锁被释放之前都无法获得锁。
4. PX 30000表示这个锁有一个30秒的自动过期时间。当然，这里30秒只是一个例子，客户端可以选择合适的过期时间。
5. 这个锁必须要设置一个过期时间。 否则的话，当一个客户端获取锁成功之后，假如它崩溃了，或者由于发生了网络分区，导致它再也无法和Redis节点通信了，那么它就会一直持有这个锁，而其它客户端永远无法获得锁了。antirez在后面的分析中也特别强调了这一点，而且把这个过期时间称为锁的有效时间(lock validity time)。获得锁的客户端必须在这个时间之内完成对共享资源的访问。
6. 此操作不能分割。>SETNX orderId driverId EXPIRE orderId 30 虽然这两个命令和前面算法描述中的一个SET命令执行效果相同，但却不是原子的。如果客户端在执行完SETNX后崩溃了，那么就没有机会执行EXPIRE了，导致它一直持有这个锁。造成死锁。

方式二：基于redisson实现分布式锁故障问题。如果redis故障了，所有客户端无法获取锁，服务变得不可用。为了提高可用性。我们给redis 配置主从。当master不可用时，系统切换到slave，由于Redis的主从复制(replication)是异步的，这可能导致丧失锁的安全性

• 1.客户端1从Master获取了锁。2.Master宕机了，存储锁的key还没有来得及同步到Slave上。3.Slave升级为Master。4.客户端2从新的Master获取到了对应同一个资源的锁。

客户端1和客户端2同时持有了同一个资源的锁。锁的安全性被打破。

2.锁的有效时间(lock validity time)，设置成多少合适?如果设置太短的话，锁就有可能在客户端完成对于共享资源的访问之前过期，从而失去保护;如果设置太长的话，一旦某个持有锁的客户端释放锁失败，那么就会导致所有其它客户端都无法获取锁，从而长时间内无法正常工作。应该设置稍微短一些，如果线程持有锁，开启线程自动延长有效期

方式三：基于RedLock实现分布式锁

针对于以上两点，antirez设计了Redlock算法 Redis的作者antirez给出了一个更好的实现，称为Redlock，算是Redis官方对于实现分布式锁的指导规范。Redlock的算法描述就放在Redis的官网上：https://redis.io/topics/distlock

目的：对共享资源做互斥访问

因此antirez提出了新的分布式锁的算法Redlock，它基于N个完全独立的Redis节点(通常情况下N可以设置成5)，意思就是N个Redis数据不互通，类似于几个陌生

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!