卡片式多图流的WordPress主题模板,自动优化app,成都十大造价咨询公司,小手工在一个分布式系统中#xff0c;只要涉及到多个节点访问同一个公共资源的时候#xff0c;就需要加锁来实现互斥#xff0c;从而达到线程安全的问题。
但是呢#xff0c;分布式系统不同一些#xff0c;因为分布式系统部署在不同的服务器上#xff0c;很可能大量的请求打到…在一个分布式系统中只要涉及到多个节点访问同一个公共资源的时候就需要加锁来实现互斥从而达到线程安全的问题。
但是呢分布式系统不同一些因为分布式系统部署在不同的服务器上很可能大量的请求打到不同的服务器上如果没有分布式锁每台服务器就都判断成功就导致了资源被多次消费了。 所以有了分布式锁的概念。 分布式锁本质就是使用一个公共的服务器Redis、MySQL、或其他的服务器来记录加锁的状态。 这里直讲用Redis实现分布式锁。
分布式锁的基础实现
分布式锁其实很简单就是在Redis中通过一个键值对来完成的。 例如下面的场景在抢票的场景下现在车站提供了若干车次每个车次的票数是固定的。 现在存在多个服务器都需要处理买票的逻辑查询车次的票数判断票数是否大于0如果大于0票数–。 显然要通过加锁来避免线程安全的问题此时我们引进了一个Redis作为锁的管理 此时如果买票服务器1尝试买票需要先访问Redis然后再Redis上设置一个键值对。 例如 key —— 车次 value—— 设置为1当键值对设置成功的时候就代表没有节点对001车次加锁就可以对数据库进行操作当操作完成的时候将键值对删除掉。
在加锁的过程中即使有服务器2来尝试买票会发现Redis上已经存在该车次的key了所以只能阻塞。
所以根据上面的场景用Redis来操作的话就很简单了直接setnx操作如果key不存在就创建存在则失败返回。
过期时间
但是有一个问题 当服务器1加锁之后开始处理买票的逻辑时如果服务器1宕机了就会导致删除key不能执行其他服务器不能在这个车次上进行买票逻辑了所以需要在此基础上加上一个过期时间。
所以通过用Redis的set nx ex来完成注意这里不能setnx之后再设置一个过期时间因为Redis和MySQL不同Redis即使使用了事务也不能保证这2个操作一起成功这是和MySQL不同的地方所以很可能出现一种情况setnx成功了但是expire失败了一样导致不能成功释放掉锁。
检验ID
这时候其实还有一个很大的问题 我们设置键值对的时候是key——001vlaue——1 这是否在分布式系统中有问题呢 比如服务器1写入001:1的键值对的时候其他服务器是可以对它进行操作的这很不合理。 所以键值对应该不能简单的设置为1应该设置为服务器的编号比如key——001value——服务器1当我们要删除键值对的时候会先去判断当前删除key的服务器是否是加锁时候的服务器如果是就删除否则不能删除。
这里提供一段伪代码流程如下
String key [要加锁的资源 id];
String serverId [服务器的编号];
// 加锁, 设置过期时间为 10s
redis.set(key, serverId, NX, EX, 10s);
// 执⾏各种业务逻辑, ⽐如修改数据库数据.
doSomeThing();
// 解锁, 删除 key. 但是删除前要检验下 serverId 是否匹配.
if (redis.get(key) serverId) {redis.del(key);
}引入Lua
很明显上述的代码不是原子的所以为了解决这个问题又引入了Lua脚本来实现原子的问题。
if redis.call(get,KEYS[1]) ARGV[1] then return redis.call(del,KEYS[1])
else return 0
end;引入Watch dog
但是上面的实现方案还有问题过期时间设置为多少合适呢
如果设置少了很可能出现任务没执行完key被删除的情况。 如果过期时间设置的长也无法保证没有提前失效的场景。而且设置的长了如果服务器挂了其他的服务器也获取不到锁
因此结合上述的问题引入了Watch dog的概念本质就是在加锁的服务器上的一个单独的线程通过这个线程对加锁实现动态续约
假设过期时间为10s我们的Watch dog设置为3s检测一次那么当3s时间到的时候Watch dog会去看当前任务是否完成
如果任务完成则直接通过Lua脚本来删除key如果任务没有完成将过期时间延长
所以就解决了即使服务器挂了Watch dog也挂了key很快就会被删除掉其他服务器也可以获取到锁了。
引入Redlock算法
Redis实际上是通过集群的方式来部署的所以有可能出现以下的问题。
服务器1向master节点进行加锁操作这个写入刚刚完成但是maser改了slave节点升级为新的maseter节点由于数据还没有同步此时服务器1的加锁操作是否就形同虚设了呢 服务器2就可以给新的master写入key了。
所以为了解决上面的问题引入了Redlock算法。 Redlock算法在加锁的时候不再只写给一个Redis节点而是写入多个。最后当加锁成功的数量超过集群数量的一半的时候就视为加锁成功。
所以即使有些节点挂了也不影响锁的正确性。
