redis 删除密码指令 redis删除锁

转载

bigrobin 2023-12-09 18:08:08

文章标签 redis 删除密码指令 redis 缓存数据 Redis 文章分类 Redis 数据库

锁

基于特定条件的事务执行

业务场景

天猫双11热卖过程中，对已经售罄的货物追加补货，4个业务员都有权限进行补货。补货的操作可能是一系

列的操作，牵扯到多个连续操作，如何保障不会重复操作？

业务分析

多个客户端有可能同时操作同一组数据，并且该数据一旦被操作修改后，将不适用于继续操作
在操作之前锁定要操作的数据，一旦发生变化，终止当前操作

解决方案

对 key 添加监视锁，在执行exec前如果key发生了变化，终止事务执行

watch key1 [key2……]

取消对所有 key 的监视

unwatch

Tips 18：

redis 应用基于状态控制的批量任务执行

业务场景

天猫双11热卖过程中，对已经售罄的货物追加补货，且补货完成。客户购买热情高涨，3秒内将所有商品购

买完毕。本次补货已经将库存全部清空，如何避免最后一件商品不被多人同时购买？【超卖问题】

业务分析

使用watch监控一个key有没有改变已经不能解决问题，此处要监控的是具体数据
虽然redis是单线程的，但是多个客户端对同一数据同时进行操作时，如何避免不被同时修改？

基于特定条件的事务执行——分布式锁

解决方案

使用 setnx 设置一个公共锁

setnx lock-key value

利用setnx命令的返回值特征，有值则返回设置失败，无值则返回设置成功

对于返回设置成功的，拥有控制权，进行下一步的具体业务操作
对于返回设置失败的，不具有控制权，排队或等待

操作完毕通过del操作释放锁

开始操作时，设置了一个num
127.0.0.1:6379> set num 10
OK
给num设置一个公共锁
127.0.0.1:6379> setnx lock-num 1
(integer) 1
进行自减操作
127.0.0.1:6379> incrby num -1
(integer) 9
删除锁
127.0.0.1:6379> del lock-num
(integer) 1
再次开启一个num公共锁
127.0.0.1:6379> set lock-num 1
OK
此时在另一个终端开启num公共锁时发现
127.0.0.1:6379> setnx lock-num 1
(integer) 0
结果为开启不成功，那么当上一个做完操作并将这个公共锁删除的的时候，另一个终端才能开启这个公共锁且进行操作

注意：上述解决方案是一种设计概念，依赖规范保障，具有风险性

Tips 19：

redis 应用基于分布式锁对应的场景控制

业务场景

依赖分布式锁的机制，某个用户操作时对应客户端宕机，且此时已经获取到锁。如何解决？

业务分析

由于锁操作由用户控制加锁解锁，必定会存在加锁后未解锁的风险
需要解锁操作不能仅依赖用户控制，系统级别要给出对应的保底处理方案

基于特定条件的事务执行——分布式锁改良

解决方案

使用 expire 为锁key添加时间限定，到时不释放，放弃锁

expire lock-key second
pexpire lock-key milliseconds

由于操作通常都是微秒或毫秒级，因此该锁定时间不宜设置过大。具体时间需要业务测试后确认。

例如：持有锁的操作最长执行时间127ms，最短执行时间7ms。
测试百万次最长执行时间对应命令的最大耗时，测试百万次网络延迟平均耗时
锁时间设定推荐：最大耗时120%+平均网络延迟110%
如果业务最大耗时<<网络平均延迟，通常为2个数量级，取其中单个耗时较长即可

删除策略

过期数据

Redis中的数据特征

Redis是一种内存级数据库，所有数据均存放在内存中，内存中的数据可以通过TTL指令获取其状态

XX ：具有时效性的数据
-1 ：永久有效的数据
2 ：已经过期的数据或被删除的数据或未定义的数据

过期的数据真的删除了吗？

数据删除策略

时效性数据的存储结构

redis 删除密码指令 redis删除锁_redis 删除密码指令

数据删除策略的目标

在内存占用与CPU占用之间寻找一种平衡，顾此失彼都会造成整体redis性能的下降，甚至引发服务器宕机或

内存泄露

定时删除

创建一个定时器，当key设置有过期时间，且过期时间到达时，由定时器任务立即执行对键的删除操作
优点：节约内存，到时就删除，快速释放掉不必要的内存占用
缺点：CPU压力很大，无论CPU此时负载量多高，均占用CPU，会影响redis服务器响应时间和指令吞吐量
总结：用处理器性能换取存储空间（拿时间换空间）

惰性删除

数据到达过期时间，不做处理。等下次访问该数据时

如果未过期，返回数据
发现已过期，删除，返回不存在

优点：节约CPU性能，发现必须删除的时候才删除
缺点：内存压力很大，出现长期占用内存的数据
总结：用存储空间换取处理器性能

expireIfNeeded()

（拿时间换空间）

问题：两种方案都走极端，有没有折中方案？

定期删除

Redis启动服务器初始化时，读取配置server.hz的值，默认为10

redis 删除密码指令 redis删除锁_redis_02

每秒钟执行server.hz次 serverCron()（定时服务器） ——访问每一个数据库的定时服务器——> databasesCron() ——每一个数据库都会进行检查
——>activeExpireCycle()
**activeExpireCycle()**对每个expires[*]逐一进行检测，每次执行250ms/server.hz
对某个expires[*]检测时，随机挑选W个key检测

如果key超时，删除key
如果一轮中删除的key的数量>W25%，循环该过程
如果一轮中删除的key的数量≤W25%，检查下一个expires[]，0-15循环
W取值=ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP属性值

参数current_db用于记录activeExpireCycle() 进入哪个expires[*] 执行
如果activeExpireCycle()执行时间到期，下次从current_db继续向下执行
周期性轮询redis库中的时效性数据，采用随机抽取的策略，利用过期数据占比的方式控制删除频度
特点1：CPU性能占用设置有峰值，检测频度可自定义设置
特点2：内存压力不是很大，长期占用内存的冷数据会被持续清理
总结：周期性抽查存储空间（随机抽查，重点抽查）

删除策略比对

定时删除	节约内存，无占用	不分时段占用CPU资源，频度高	拿时间换空间
惰性删除	内存占用严重	延时执行，CPU利用率高	拿空间换时间
定期删除	内存定期随机清理	每秒花费固定的CPU资源维护内存	随机抽查，重点抽查

逐出算法

新数据进入检测

当新数据进入redis时，如果内存不足怎么办？

Redis使用内存存储数据，在执行每一个命令前，会调用**freeMemoryIfNeeded()**检测内存是否充足。如果内存不满足新加入数据的最低存储要求，redis要临时删除一些数据为当前指令清理存储空间。清理数据的策略称为逐出算法。
注意：逐出数据的过程不是100%能够清理出足够的可使用的内存空间，如果不成功则反复执行。当对所有数据尝试完毕后，如果不能达到内存清理的要求，将出现错误信息。

redis 删除密码指令 redis删除锁_Redis_03

影响数据逐出的相关配置

最大可使用内存

maxmemory

占用物理内存的比例，默认值为0，表示不限制。生产环境中根据需求设定，通常设置在50%以上。

每次选取待删除数据的个数

maxmemory-samples

选取数据时并不会全库扫描，导致严重的性能消耗，降低读写性能。因此采用随机获取数据的方式作为待检测删除数据

删除策略

maxmemory-policy

达到最大内存后的，对被挑选出来的数据进行删除的策略

影响数据逐出的相关配置（8种策略）

检测易失数据（可能会过期的数据集server.db[i].expires ）
① volatile-lru：挑选最近最少使用的数据淘汰
② volatile-lfu：挑选最近使用次数最少的数据淘汰
③ volatile-ttl：挑选将要过期的数据淘汰
④ volatile-random：任意选择数据淘汰
检测全库数据（所有数据集server.db[i].dict ）
⑤ allkeys-lru：挑选最近最少使用的数据淘汰
⑥ allkeys-lfu：挑选最近使用次数最少的数据淘汰
⑦ allkeys-random：任意选择数据淘汰
放弃数据驱逐
⑧ no-enviction（驱逐）：禁止驱逐数据（redis4.0中默认策略），会引发错误OOM（Out Of Memory）