网站关键词设几个,国土局网站建设方案,网站空间商推荐,关键词搜索排名推广分布式锁
什么时候需要加锁
有并发#xff0c;多线程有写操作有竞争关系
场景#xff1a;
电商系统#xff0c;下单流程#xff1a;用户下单–秒杀系统检查redis商品库存信息–用户锁定并更新库存#xff08;mysql#xff09;—秒杀系统更新redis
问题多线程有写操作有竞争关系
场景
电商系统下单流程用户下单–秒杀系统检查redis商品库存信息–用户锁定并更新库存mysql—秒杀系统更新redis
问题单机部署单线程执行无问题多线程并发操作会引起超卖
解决对用户下单后的步骤加锁让线程排队避免超卖synchronized 或reentrantLock
问题单机部署变为多机部署时仍然有超卖现象。因为synchronized和reentrantLock都只作用于自己的jvm
解决使用分布式锁。可以基于Mysql、redis、zookeeper、consule等进行实现
部署通常将锁和应用分开部署把这个锁作为一个公用的组件然后多个不同应用的不同节点都去共同访问这个组件。
分布式锁解决方法
1.基于数据库实现
1.1基于数据库表实现
新建表记录当前哪个程序正在使用数据
步骤
程序访问数据时将程序的编号insert存入表。当insert成功代表该程序获得了锁即可执行逻辑。当程序编号相同的其他程序进行insert时由于主键冲突会导致insert失败则代表获取锁失败。获取锁成功的程序在逻辑执行完以后删除该数据,代表释放锁。
1.2基于条件
MySQL乐观锁思想就是利用MySQL的InnoDB引擎的行锁机制来完成。
乐观锁的实现分为根据条件和根据版本号。 根据条件 Update(update tb_book set stockstock-#{saleNum} where id #{id} and stock-#{saleNum}0)void updateNoLock(Param(id) int id, Param(saleNum) int saleNum);根据版本号更新成功后版本号1 Update(update tb_book set name#{name},versionversion1 where id#{id} and version#{version})int updateByVersion(Param(id)int id,Param(name)String name,Param(version)int version);2.zookeeper分布式锁
实现思想内部主要是利用znode节点特性和watch机制完成。
znode节点 持久节点一旦创建则永久存在于zookeeper中除非手动删除。持久有序节点一旦创建则永久存在于zookeeper中除非手动删除。同时每个节点都会默认存在节点序号每个节点的序号都是有序递增的。如demo000001、demo000002…demo00000N。临时节点当节点创建后一旦服务器重启或宕机则被自动删除。临时有序节点当节点创建后一旦服务器重启或宕机则被自动删除。同时每个节点都会默认存在节点序号每个节点的序号都是有序递增的。如demo000001、demo000002…demo00000N。 watch监听机制 watch监听机制主要用于监听节点状态变更用于后续事件触发假设当B节点监听A节点时一旦A节点发生修改、删除、子节点列表发生变更等事件B节点则会收到A节点改变的通知接着完成其他额外事情。 实现原理 思想是当某个线程要对方法加锁时首先会在zookeeper中创建一个与当前方法对应的父节点接着每个要获取当前方法的锁的线程都会在父节点下创建一个临时有序节点因为节点序号是递增的所以后续要获取锁的线程在zookeeper中的序号也是逐次递增的。根据这个特性当前序号最小的节点一定是首先要获取锁的线程因此可以规定序号最小的节点获得锁。所以每个线程再要获取锁时可以判断自己的节点序号是否是最小的如果是则获取到锁。当释放锁时只需将自己的临时有序节点删除即可。在并发下每个线程都会在对应方法节点下创建属于自己的临时节点且每个节点都是临时且有序的。每当添加一个新的临时节点时其都会基于watcher机制监听着它本身的前一个节点等待前一个节点的通知当前一个节点删除时就轮到它来持有锁了。然后依次类推。
原理剖析
低效实现
流程开始事务–获取锁–创建锁节点类型临时节点–创建成功获得锁不成功锁节点已经存在监听锁节点删除羊群效应低效点–只有一个锁节点其他线程都会监听同一个锁节点一旦锁节点释放后其他线程都会收到通知然后竞争获取锁节点。这种大量的通知操作会严重降低zookeeper性能对于这种由于一个被watch的znode节点的变化而造成大量的通知操作叫做羊群效应。
高效实现
让获取锁的线程产生排队后一个监听前一个依次排序。推荐使用这种方式实现分布式锁。
流程开始事务–获取锁–判断父节点是否存在–不存在创建父节点–创建临时有序节点–获取锁判断自身是否为序号最小节点—是最小节点获取锁成功—不是最小节点监控比本节点序号-1的节点阻塞等待节点删除通知 --收到前置节点删除通知–回到获取锁判断是不是为序号最小的节点
结果会在根节点下为每一个等待获取锁的线程创建一个对应的临时有序节点序号最小的节点会持有锁并且后一个节点只监听其前面的一个节点从而可以让获取锁的过程有序且高效。
3.redis分布式锁
3.1单节点Redis实现分布式锁
核心API
setnx向redis中存key-value只有当key不存在时才会设置成功否则返回0体现互斥性expire设置key的过期时间用于避免死锁出现delete删除key用于释放锁
问题
编写工具类注意释放锁的原子性锁续期在创建锁的同时创建一个守护线程同时定义一个定时任务每隔一段时间去为未释放的锁增加过期时间当业务执行完释放锁后再关闭守护线程这种实现思想可以解决锁续期业务没执行完锁过期服务单点集群问题单点redis可以完成锁操作可一旦redis服务节点挂掉了则无法提供锁操作 生产环境为保证redis高可用采用异步复制方法进行主从部署主节点写入数据异步复制给从节点当主节点宕机从节点升级为主节点。
3.2 redission实现分布式锁
单机实现getLocklockunlock 多线程并发获取锁时当一个线程获取到锁其他线程则获取不到并内部会不断尝试获取锁当持有锁的线程将锁释放后其他线程则会继续去竞争锁。 看门狗 不需要对锁key设置过期时间当过期时间为-1时会启动一个定时任务在业务释放锁前会一直不停的增加这个锁的有效时间从而保证在业务执行完毕之前这把锁不会被提前释放掉实现将lock改为tryLock。 在lock源码中如果没有设置锁超时默认过期时间是30秒即watchdog每隔30秒来进行一次续期值可修改 红锁 考虑将redis配置为主从结构在主从结构中数据复制是异步实现的。假设在主从结构中master会异步将数据复制到slave中一旦某个线程持有了锁在还没有将数据复制到slave时master宕机。则slave会被提升为master但被提升为slave的master中并没有之前线程的锁信息那么其他线程则又可以重新加锁。redlock基于多节点redis实现分布式锁的算法可以有效解决redis单点故障的问题实现过程 记录获取锁前的当前时间使用相同的keyvalue获取所有redis实例中的锁并且设置获取锁的时间要远远小于锁自动释放的时间。假设锁自动释放时间是10秒则获取时间应在5-50毫秒之间。通过这种方式避免客户端长时间等待一个已经关闭的实例如果一个实例不可用了则尝试获取下一个实例。客户端通过获取所有实例的锁后的时间减去第一步的时间得到的差值要小于锁自动释放时间避免拿到一个已经过期的锁。并且要有超过半数的redis实例成功获取到锁才算最终获取锁成功。如果不是超过半数有可能出现多个客户端重复获取到锁导致锁失效。当已经获取到锁那么它的真正失效时间应该为过期时间-第三步的差值。如果客户端获取锁失败则在所有redis实例中释放掉锁。为了保证更高效的获取锁还可以设置重试策略在一定时间后重新尝试获取锁但不能是无休止的要设置重试次数。
redis和zookeeper分布式锁对比
redis缺点
采用抢占式方式进行锁的获取需要不断的在用户态进行CAS尝试获取锁对CPU占用率高。redis本身并不是CP模型即便采用了redlock算法但仍然无法保证百分百不会出现问题如持久化问题。对于redis分布式锁的使用在企业中是非常常见的绝大多数情况不会出现极端情况。
zookeeper实现分布式的优点在于其是强一致性的采用排队监听的方式获取锁不会像redis那样不断进行轮询尝试对性能消耗较小。其缺点则是如果频繁的加锁和解锁对zk服务器压力较大。
当进行技术选型时应该对其优缺点结合公司当前情况进行考虑。 如果公司有条件使用zk集群更推荐使用zk的分布式锁因为redis实现分布式锁有可能出现数据不正确的情况但如果公司没有zk集群使用redis集群完成分布式锁也无可厚非。
参考
https://blog.csdn.net/poizxc2014/article/details/123963250
https://blog.csdn.net/q66562636/article/details/124862795
