分布式锁在项目中有哪些应用场景
1、系统是一个分布式系统,golang的锁已经锁不住了;
2、需要操作共享资源,比如库里唯一的用户数据;
3、同步访问,即多个进程同时操作共享资源;
分布式锁有哪些解决方案
1、Redis分布式锁。使用setnx key value,这种方法如果不在使用完后delete删除锁,则会产生死锁;因此需要同时设置过期时间,作为一个原子性操作;但如果这次操作的耗时超过了过期时间,则其他操作现在能拿到这个数据了,此时需要用watch dog来刷新过期时间。
2、基于Zookeeper,设置临时顺序节点。
3、基于数据库,比如MySQL,使用主键或唯一索引的唯一性。
ZooKeeper和Redis做分布式锁的区别
Redis只保证最终一致性,副本间的数据复制是异步的,所以主从切换会有数据丢失从而丢失锁的情况,但Redis集群响应的时间很低,保证AP,但不可靠,相对不稳定。
ZooKeeper锁原理是使用临时顺序节点,该节点的生命周期在Client与集群的Session结束时结束,有较好的稳定性,每次进行锁操作前要创建若干节点,完成后释放,会浪费时间,保证CP。
MySQL如何做分布式锁
在MySQL中创建一个表,设置一个主键或者唯一索引,这个ID/唯一索引就是一把分布式锁,这个KEY就是要锁的KEY,这样同一个KEY只能在mysql中插入一次了,对锁的竞争就交给了数据库。其他想要进行插入数据的并发请求必须等当前请求执行完毕后删除该KEY才能继续插入。
计数器算法
在指定时间周期内累加访问次数,达到设定的阈值时,触发限流策略。下一个时间周期进行访问时,访问次数清零。但如果在两个周期的交界处,左右两边的请求加起来超过了阈值,即超过了系统的最大承载能力。
滑动时间窗口算法
为解决计算器算法的临界值问题,发明了滑动窗口算法。实际上将计数器算法中的周期划分成多个小的时间窗口,根据时间将窗口向前滑动的同时删除过期的小时间窗口,这样只需要统计滑动窗口之间的总请求数即可。小窗口划分的越多,窗口滑动越平滑,限流的统计越精确。
漏桶限流算法
维持一个漏斗,消息的生产者往里面输入,漏斗以恒定的速度流出给消费者处理,类似于消息中间件,消息处理能力取决于消费者。
漏桶的容量 = 漏桶流出的速度 * 可接受的等待时长。这个容量范围内的请求可以排队等待,超出则抛弃。
当请求速度大于漏桶流出的速度时,触发限流策略。
系统在短