1. redission
redission 原理
Redis分布式锁-这一篇全了解(Redission实现分布式锁完美方案)
2.zk
2.1 指令
ls / / 下有哪些子节点
get /zookeeper 查看某个子节点内容
create /aa “test”
delete /aa
set /aa “test01”
2.2 创建节点
模式 默认创建永久
create -e 创建临时
create -e /zz “hello zz”
create -s 创建 有序节点
create -s -e 临时序列化节点
2.3 节点事件监听
一次性的监听
-
节点创建 事件监听
NodeCreated
stat -w /xx -
节点 删除 监听
NodeDeleted
stat -w -
节点数据 变化 监听
NodeDataChanged
get -w /bb
set /bb “cc” //修改节点数据 -
子节点 监听
NodeChildrenChanged
ls -w /bb
create /bb/cc “test”
2.4 zk 分布式锁
- 独占、排它， 其他线程获取不到
- 阻塞 解决自旋的消耗
临时 有序节点+ 事件 监听(监听 比他小1的节点)，
让最小的节点 获取到锁, 44节点监听43节点，43 节点删除后，唤醒后续44节点 获得锁。公平锁
3. 锁的可重入性
思路1： 在节点的内容中记录 服务器、线程、已经重入信息
思路2 ：Threadloacal： 线程的局部变量，线程私有
阻塞操作 获取不到监听 并阻塞
创建 临时 有序节点 返回节点路径
// 获取前置节点 ，如果前置节点为空，那么获得锁成功，否则监听 前置节点
countdownLatch(1)
在监听事件的内部 进行一个countDown();
可重入锁
threadloacal
在 trylock()
unlock 里面 判断：
2.5 锁
zk 的节点 存储机制+通知机制
zk 有4中节点类型，持久节点，持久顺序节点、临时节点、临时顺序节点
持久和临时 判断标准依赖于客户端 的生命周期
顺序： 节点对应的id
- 持久节点
- 持久顺序节点
- 持久的非顺序节点
- 临时节点
- 临时的非顺序节点( 实现分布式锁的条件)
- 临时的顺序节点
利用zk 支持的临时顺序节点 +通知机制 可以实现分布式锁
- 加锁：判断是否持有了分布式锁，判断客户端 创建的节点是否是
有序节点中 序号最小的一个 - 释放锁: 将自己的创建的节点 删除即可。
3. redission zk 分布式锁对比
4. 延时任务
4.0 场景
4.1 定时任务数据库轮询
- 定时任务轮询数据库，
采用定时任务失效延迟、对业务表进行轮询判断，到点执行。有一点点误差。
1） 使用单机版本的spring schedule +分布式锁的实现。
同一个服务，多个节点 同时执行可能都会执行，需要加分布式锁。
- 分布式调度框架 xxl-job
如果处理数据量较大，可以利用分布式调度系统的分片功能并行处理，大大提升数据的处理能力，加快处理速度。
优点：
单机版 基于spring，实现简单。不用引入各种中间件，各个模块可以自行定义延迟规则。
缺点
2. 完全由业务代码进行控制，重复代码多，不论是否有待执行的数据，都要空轮询cpu 且频繁的访问数据库 io 消耗。
3. 由于是定时轮询，存在一点误差。
基于@schedule
取消订单操作
基于xxl-job 的
4.2 Java 的DelayQueue
Java DelayQueue的使用及应用场景
DelayQueue 的实现原理。
1） DelayQueue 是JDK提供的一个无界 BlockQueue ，用于放置实现了Delayed 接口的对象。其中的对象只能在其到期时，才能从队列中拿走。
这种队列 是 有序的，即 队头对象的延迟到期时间最长。
注意不能将null 元素放置 到这种队列中。
2）实现注意事项
队列 里面的元素 需要实现Delayed 这个接口。getDelay 方法用于设置 延迟时间。 compareTo 方法用于对队列的元素 进行排序。
public class DelayQueue<E extends Delayed> extends AbstractQueue<E>implements BlockingQueue<E>
// 入队
put(){
offer();} 线程安全 reentrantlock 加锁
offer(); 线程安全
// 出队
poll(); 非阻塞方法，没有到期元素 直接返回 null
take(); 阻塞式 获取，没有到期元素，线程将会进行等待。
优点:
jdk 自带的，不需要引入其他框架 中间件，实现简单。
缺点:
- 不支持分布式或者 持久化的，重启会丢失。
- 如果 并发量 非常大，因为DelayQueue式无界的，队列内的对象越多。可能会造成oom 的风险。
- 所以使用 delayQueue实现的定时任务，只适用于任务量较小的情况。
4.3 消息中间件
rocketmq如何实现延时队列
rocketmq 先把消息 按照延时时间段(1s,5s,10s) 发到指定的队列中,然后通过一个定时器轮询这些队列。如果到期，就把 这个消息发到指定的topic 队列。
注意点:
- rocketmq 延时消息的时长
不支持随机时长的延迟。是通过特定的延迟等级来指定的。
默认支持18个等级的延迟消息。
延时等级 在rocketmq服务端的MessageStoreConfig类中
private String messageDelayLevel ='1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 30m 1h 2h'发消息时： 设置delayLevel 等级即可 msg.setDelayLevel( level);level ==0 消息非延迟1<=level <=maxlevel 消息延迟特定的时间。level >maxlevel 那么 level=maxlevel 例如leve=20，延迟2h优点：
基于消息中间件可以快速实现延时队列，而且天然支持消息消费的有序性、消息持久化、ack机制。
缺点：
需要额外的部署 和运维成本。
4.4 redis zset、 key 过期回调
zrangebyScore
redis 127.0.0.1:6379> ZADD salary 2500 jack # 测试数据
(integer) 0
redis 127.0.0.1:6379> ZADD salary 5000 tom
(integer) 0
redis 127.0.0.1:6379> ZADD salary 12000 peter
(integer) 0redis 127.0.0.1:6379> ZRANGEBYSCORE salary -inf +inf # 显示整个有序集
1) "jack"
2) "tom"
3) "peter"redis 127.0.0.1:6379> ZRANGEBYSCORE salary -inf +inf WITHSCORES # 显示整个有序集及成员的 score 值
1) "jack"
2) "2500"
3) "tom"
4) "5000"
5) "peter"
6) "12000"redis 127.0.0.1:6379> ZRANGEBYSCORE salary -inf 5000 WITHSCORES # 显示工资 <=5000 的所有成员
1) "jack"
2) "2500"
3) "tom"
4) "5000"redis 127.0.0.1:6379> ZRANGEBYSCORE salary (5000 400000 # 显示工资大于 5000 小于等于 400000 的成员
1) "peter"
4.5 时间轮算法
核心参数
每个 刻度 代表一个duration 时长。
- tickDuration s 、mins、 h
每个刻度的时长 - round
第几圈 后执行，使用延期时长/ 一圈的时长得来
一个刻度1s，15s 后执行，那么 需要 round =2，没到指定位置，round -1； - ticksPerWheel
一圈下来有几个刻度
工作原理
- 指针停在0处
- tickDuration=1
- ticksPerWheel=12
如果一个25秒才执行的延时任务添加进来，首先它会计算它的round和index，round=25/12 =2
index=25%12=1.
所以时间轮长这样:
当指针转到index=1的刻度时，会判断第一个task的round是不是为0，如果为0则取出来，去执行，如果大于0，则将round-1.
