redis的机制（2）

redis持久化机制

         redis的数据都存放在内存中，如果没有配置持久化机制，重启之后就会全丢失了。需要开启持久化机制，将数据保存到磁盘上，当redis重启后，可以从磁盘上恢复。

    两种持久化方式RDB和AOF

RDB

    在指定时间内对数据记性快照保存，会缺失部分数据。

   恢复方式 ：

     1.client端直接用命令BGSAVE或者SAVE创建一个内存快照

           BGSAVE 调用fork来创建子进程，子进程负责写入快照磁盘中，而父进程仍然处理命令

            SAVE 执行命令过程中，不再响应其他命令

     配置文件 redis.conf,默认满足条件的触发

# 900秒之内至少一次写操作
save 900 1
# 300秒之内至少发生10次写操作
save 300 10
# 60秒之内发生至少10000次
save 60 1000

   优点和缺点

  

优点	缺点
对性能影响最小	同步丢失数据
比AOF恢复要快	如果数据集非常大且CPU不够强（比如单核 CPU），Redis在fork子进程时可能会消耗相 对较长的时间，影响Redis对外提供服务的 能力。

 

AOF

     记录每次对服务器数据读写的操作命令，服务器重启，就会执行这些命令恢复原始的数据。

 方式：

   BGREWRITEAOF命令可以触发日志重写或自动重写，废除对同一个Key历史的无用命令，重建当前数据集所需的最短命令序列。
意外中断，如果最后的命令只写了一部分，恢复时则会跳过它，执行后面完整的命令。

配置文件redis.cof

开启AOF持久化
appendonly yes
 
AOF策略调整
#每次有数据修改发生时都会写入AOF文件，非常安全非常慢
appendfsync always
#每秒钟同步一次，该策略为AOF的缺省策略，够快可能会丢失1秒的数据
appendfsync everysec
#不主动fsync,由操作系统决定，更快，更不安全的方法
appendfsync no

优点和缺点

 

优点	缺点
安全	文件体积大
容灾	IO消耗高
易读，可修改	比RDB慢

redis丢失的可能原因

持久化丢失的可能 ：  
   RDB 方式
       快照产生的策略，天生就不保证数据安全
   AOF 持久化策略
       默认每秒同步一次磁盘，可能会有1秒的数据丢失
       每次修改都同步，数据安全可保证，但Redis高性能的特性全无
主从复制丢失的可能：
    异步复制，存在一定的时间窗口数据丢失
    网络、服务器问题，存在一定数据的丢失

淘汰策略

首先我们要对内存分配有了解

 内存分配

 Strings类型：一个String类型的value最大可以存储512M。
Lists类型：list的元素个数最多为2^32-1个，也就是4294967295个。
Sets类型：元素个数最多为2^32-1个，也就是4294967295个。
Hashes类型：键值对个数最多为2^32-1个，也就是4294967295个


# 最大内存控制
maxmemory 最大内存阈值
maxmemory-policy 到达阈值的执行策略

内存压缩

#配置字段最多512个
hash-max-zipmap-entries 512
#配置value最大为64字节
hash-max-zipmap-value 64
#配置元素个数最多512个
list-max-ziplist-entries 512
#配置value最大为64字节
list-max-ziplist-value 64


#配置元素个数最多512个
set-max-intset-entries 512
#配置元素个数最多128个
zset-max-ziplist-entries 128
#配置value最大为64字节
zset-max-ziplist-value 64

#如果超出范围，redis将自动转换成正常大小

过期数据的处理策略

主动处理
（ redis 主动触发检测key是否过期）每秒执行10次。
过程如下：
1. 从具有相关过期的密钥集中测试20个随机密钥
2. 删除找到的所有密钥已过期
3. 如果超过25％的密钥已过期，请从步骤1重新开始

被动处理：
1. 每次访问key的时候，发现超时后被动过期，清理掉

数据恢复阶段过期数据的处理策略

 RDB方式
过期的key不会被持久化到文件中。
载入时过期的key，会通过redis的主动和被动方式清理掉。
AOF方式
当 redis 使用 AOF 方式持久化时，每次遇到过期的 key redis 会追
加一条 DEL 命令 到 AOF 文件，
也就是说只要我们顺序载入执行 AOF 命令文件就会删除过期的键。

  LRU算法

Least recently used 最少使用
    根据历史的访问记录来进行淘汰数据
核心思想：如果数据最近被访问过，那么将来被访问的几率也更高。
注意：Redis的LRU算法并非完整的实现，完整的LRU实现是因为这需要太多的内存。
方法：通过对少量keys进行取样(50%)，然后回收其中一个最好的key。
配置方式： maxmemory-samples 5

  LFU算法

 

Least Frequently Used 
   根据数据的历史访问频率来淘汰数据
核心思想：如果数据过去被访问多次，那么将来被访问的频率也更高。
Redis实现的是近似的实现，每次对key进行访问时，用基于概率的对数计数器来记录
访问次数，同时这个计数器会随着时间推移而减小。
Morris counter算法依据：
   https://en.wikipedia.org/wiki/Approximate_counting_algorithm
启用LFU算法后，可以使用热点数据分析功能。（ redis-cli --hotkeys ）

内存回收策略

配置文件：maxmemory-policy noeviction

动态设置：maxmemory-policy noeviction

回收策略	备注
noeviction	客户端尝试执行会让更多内存被使用的命令直接报错
allkeys-lru	在所有key里执行LRU算法
volatile-lru	在所有已经过期的key里执行LRU算法
volatile-lfu	使用过期集在密钥中使用近似LFU进行驱逐
allkeys-lfu	使用近似LFU逐出任何键
allkeys-random	在所有key里随机回收
volatile-random	在已经过期的key里随机回收
volatile-ttl	回收已经过期的key，并且优先回收存活时间（TTL）较短的键

 

缓存击穿，缓存穿透，缓存雪崩

缓存击穿

   某一热点key，洪峰期突然缓存key失效，造成直击数据库

解决方案：

 1.设置热点key永不过期 2.增加互斥锁（拿到锁的才有资格去查询数据库）

缓存穿透

    查询一个不存的key,导致redis不可用，穿透造成数据库压力

解决方案：

1.增加检验参数

2.从nigix增加配置项，对单个key每秒访问的次数超过阀值，就把IP名单拉黑

3.布隆过滤器，提前判断值存在不存在，有误差率

4.设置不存在key值，并设置过期的时间。

缓存雪崩

洪峰期大面积缓存key失效或数据库挂掉，导致海量数据请求去查询室数据库

解决方案：

1.批量往redis存数据的时候，key的失效时间设置随机值，保证在同一时间不会大面积失效

2.集群部署，均匀的分布在不同的redis库中也能避免

3.设置热点数据永远不过期，有更新操作更新缓存就好

4.缓存穿透和缓存击穿都是造成雪崩的前提

5.缓存降级