redis高级

redis基础回顾

1. 数据格式
   1. string
      1. set key value
      2. get key
      3. setex key second value 原子性 redssion
      4. ttl key 查看过期时间
   2. hash
      1. hset key field value
      2. hget key field
      3. hgetall key
   3. list
      1. LPUSH key value
      2. LRANGE key start stop
      3. RPOP key
   4. set
      1. SADD key value
      2. SMEMBERS key
      3. SREM key value
      4. SDIFF key1 key2 key1包含的内容要大于key2
   5. zset
      1. ZADD key score value
      2. ZRANGE key start stop WITHSCORES 分数从低到高
      3. ZREVRANGE key start stop WITHSCORES 分数从高到低
      4. ZREM key member
2. 持久化
   1. RDB
      1. 快照存储，有延时性
      2. 手动触发方式，save和bgsave命令
      3. bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用。
      4. bgsave是fork出来一个子进程去处理，不影响主进程的使用
      5. save second changes redis.conf中关于rdb的配置
      6. RDB存储效率高，恢复速度快，适合备份数据使用
      7. RDB是一个紧凑压缩的二进制文件，存储效率较高
      8. 应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复。
      9. 缺点
         1. 有延时性
         2. fork子进程会损失一定的性能
         3. 版本不兼容，redis各个版本之间RDB的格式不统一
         4. 数据量非常大时，效率低，fork子进程会占用大量内存，影响磁盘IO
   2. AOF
      1. 每次修改的记录，只存储最后一次修改的记录，避免日志过大
      2. 延时小，最多损失1秒的数据
         1. 有三种写的策略
            1. always(每次）：每次写入操作均同步到AOF文件中，数据零误差，性能较低，不建议使用。
            2. everysec（每秒）：每秒将缓冲区中的指令同步到AOF文件中，在系统突然宕机的情况下丢失1秒内的数据 数据准确性较高，性能较高，建议使用，也是默认配置
            3. no（系统控制）：由操作系统控制每次同步到AOF文件的周期 整体过程不可控
   3. 一般生产环境中会同时使用RDB和AOF作为备份方式
      1. 重启时，会优先使用AOF来恢复数据

Redis高级

1. 数据删除与淘汰策略

1.1 过期数据

1.1.1 Redis中的数据特征

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

​ XX ：具有时效性的数据

​ -1 ：永久有效的数据

-2 ：已经过期的数据 或 被删除的数据 或 未定义的数据

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

1.1.2 Redis中的数据特征

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-y9cXU6b0-1609936061770)(img/image-20200713192017952.png)]

CPU比较忙

1.1.3 时效性数据的存储结构

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5vlFxspW-1609936061773)(img/image-20200713192048249.png)]

过期，只针对key， 过期数据hash结构，key-过期key，field 内存地址，value 过期时间，额外占用内存空间

1.1.4 数据删除策略

1. 定时删除
2. 惰性删除
3. 定期删除

1.1.5 数据删除策略的目标

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

小结

1. 过期数据的概念

2. 时效性数据的存储结构

3. 过期数据处理方式

4. 定时删除

5. 惰性删除

6. 定期删除

1.2 数据删除策略

1.2.1 定时删除

创建一个定时器，当key设置有过期时间，且过期时间到达时，由定时器任务立即执行对键的删除操作

优点：节约内存，到时就删除，快速释放掉不必要的内存占用

缺点：CPU压力很大，无论CPU此时负载量多高，均占用CPU，会影响redis服务器响应时间和指令吞吐量

总结：用处理器性能换取存储空间（拿时间换空间）

理解： 数据量特别大的时候

1.2.2 惰性删除

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

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

优点：节约CPU性能，发现必须删除的时候才删除

缺点：内存压力很大，出现长期占用内存的数据

总结：用存储空间换取处理器性能（拿时间换空间）

不得不删除的时候，才删除。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jztxRhfA-1609936061774)(img/image-20200713200811009.png)]

1.2.3 定期删除

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

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

2. 每秒钟执行server.hz次serverCron() ->databasesCron()->activeExpireCycle()

3. activeExpireCycle()对每个expires[*]逐一进行检测，每次执行250ms/server.hz

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VI9LlO6k-1609936061776)(img/image-20200713203059176.png)]

4. 对某个expires[*]检测时，随机挑选W个key检测
   1. 如果key超时，删除key
   2. 如果一轮中删除的key的数量>W*25%，循环该过程
   3. 如果一轮中删除的key的数量≤W25%，检查下一个expires[]，0-15循环
   4. W取值=ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP属性值
5. 参数current_db用于记录activeExpireCycle() 进入哪个expires[*] 执行
6. 如果activeExpireCycle()执行时间到期，下次从current_db继续向下执行

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-N13tmCOl-1609936061777)(img/image-20200713203449799.png)]

0-15 ，16个database，循环操作，找出过期的数据，并进行删除

特点总结：

1. 周期性轮询redis库中的时效性数据，采用随机抽取的策略，利用过期数据占比的方式控制删除频度

    2.  特点1：CPU性能占用设置有峰值，检测频度可自定义设置
    3.  特点2：内存压力不是很大，长期占用内存的冷数据会被持续清理
    4.  总结：周期性抽查存储空间（随机抽查，重点抽查）
   

1.2.4 删除策略比对

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

1.3 数据淘汰策略（数据逐出算法）

1.3.1 新数据进入检测

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

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

1.3.2 影响数据淘汰的相关配置

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

   maxmemory ?mb
   

2. 每次选取待删除数据的个数，采用随机获取数据的方式作为待检测删除数据。

   maxmemory-samples count
   

3. 对数据进行删除的选择策略

   maxmemory-policy policy
   

1.3.3 数据淘汰策略 (policy)

1. 检测易失数据（可能会过期的数据集server.db[i].expires ），redis中的数据，尽量不要存储不过期的数据
   1. volatile-lru：挑选最近最少使用的数据淘汰 ，一般采用的策略
   2. volatile-lfu：挑选最近使用次数最少的数据淘汰
   3. volatile-ttl：挑选将要过期的数据淘汰
   4. volatile-random：任意选择数据淘汰
2. 检测全库数据（所有数据集server.db[i].dict ）
   1. allkeys-lru：挑选最近最少使用的数据淘汰
   2. allkeys-lfu：挑选最近使用次数最少的数据淘汰
   3. allkeys-random：任意选择数据淘汰
3. 放弃数据驱逐
   1. no-enviction（驱逐）：禁止驱逐数据（redis4.0中默认策略），会引发错误OOM（Out Of Memory）

1.3.4 数据淘汰策略配置依据

1. 使用INFO命令输出监控信息，查询缓存 hit 和 miss 的次数，根据业务需求调优Redis配置

2. 主从复制

2.1 主从复制简介

2.1.1 高可用

​ 互联网“三高”架构

​ 1. 高并发

2. 高性能

场景：一家公司一年服务宕机次数为三次

1. 服务器宕机4小时27分15秒
	2. 服务器宕机11分36秒
	3. 服务器宕机2分16秒

可用性计算公式：

宕机时间：4小时27分15秒+11分36秒+2分16秒=4小时41分7秒=16867秒

总时间：1年=3652460*60=31536000秒

可用性= （31536000 - 16867）/31536000 * 100% =99.9465151%

业界可用性目标5个9，即99.999%，即服务器年宕机时长低于315秒，约5.25分钟

你的“Redis”是否高可用？

1. 单机redis的风险与问题
   1. 问题1.机器故障
      1. 现