reids高级:数据删除策略,数据淘汰策略,主从复制,哨兵模式,集群cluster,企业级解决方案

Redis高级课堂讲义

学习目标

目标1：能够说出redis中的数据删除策与略淘汰策略

目标2：能够说出主从复制的概念，工作流程以及场景问题及解决方案

目标3：能够说出哨兵的作用以及工作原理，以及如何启用哨兵

目标4：能够说出集群的架构设计，完成集群的搭建

目标5：能够说出缓存预热，雪崩，击穿，穿透的概念，能说出redis的相关监控指标

 

回顾：

数据结构：key value

1,string: key value

2,hash: key Map(key,value) user name:sanshao age:18 money:1000

3,list: key value(a,b,c,d......)

4,set: key value(a,b,c,d.....)

5,sortedset: score 分值 zset key value 9 key1 value1 10

持久化：

RDB: 快照复制（根据KEY的变化的次数自动持久化，也可以手动持久化） 持久化慢，恢复快

AOF: 追加方式（设置每秒持久化一次，每次操作都持久化） 持久化快，恢复慢

1.数据删除与淘汰策略

 

1.1 过期数据

1.1.1 Redis中的数据特征

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

TTL返回的值有三种情况：正数，-1，-2

• 正数：代表该数据在内存中还能存活的时间

• -1：永久有效的数据

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

删除策略就是针对已过期数据的处理策略，已过期的数据是真的就立即删除了吗？其实也不是，我们会有多种删除策略，是分情况的，在不同的场景下使用不同的删除方式会有不同效果，这也正是我们要将的数据的删除策略的问题

1.1.2 时效性数据的存储结构

在Redis中，如何给数据设置它的失效周期呢？数据的时效在redis中如何存储呢？看下图：

 

 

过期数据是一块独立的存储空间，Hash结构，field是内存地址，value是过期时间，保存了所有key的过期描述，在最终进行过期处理的时候，对该空间的数据进行检测， 当时间到期之后通过field找到内存该地址处的数据，然后进行相关操作。

1.2 数据删除策略

1.2.1 数据删除策略的目标

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

针对过期数据要进行删除的时候都有哪些删除策略呢？

• 1.定时删除

• 2.惰性删除

• 3.定期删除

1.2.2 定时删除

创建一个定时器，当key设置有过期时间，且过期时间到达时，由定时器任务立即执行对键的删除操作。定时监控expires内存中相应的时间 ，时间到了就根据对应的内存地址找到对应的数据将其删除 。

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

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

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

1.2.3 惰性删除

数据到达过期时间，不做处理。等下次访问该数据时，我们需要判断

1. 如果未过期，返回数据

2. 发现已过期，删除，返回不存在

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

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

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

1.2.4 定期删除

定时删除和惰性删除这两种方案都是走的极端，那有没有折中方案？

我们来讲redis的定期删除方案：

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

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

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

• 对某个expires[*]检测时，随机挑选W个key检测

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

• 参数current_db用于记录activeExpireCycle() 进入哪个expires[*] 执行

• 如果activeExpireCycle()执行时间到期，下次从current_db继续向下执行

 

总的来说：定期删除就是周期性轮询redis库中的时效性数据，采用随机抽取的策略，利用过期数据占比的方式控制删除频度

• 特点1：CPU性能占用设置有峰值，检测频度可自定义设置

• 特点2：内存压力不是很大，长期占用内存的冷数据会被持续清理

• 总结：周期性抽查存储空间（随机抽查，重点抽查）

1.2.5 删除策略对比

1：定时删除：

节约内存，无占用,
不分时段占用CPU资源，频度高,
拿时间换空间

2：惰性删除：

内存占用严重
延时执行，CPU利用率高
拿空间换时间

3：定期删除：

内存定期随机清理
每秒花费固定的CPU资源维护内存
随机抽查，重点抽查

 

定时删除和定期删除为主动删除：Redis会定期主动淘汰一批已过期的key
​
惰性删除为被动删除：用到的时候才会去检验key是不是已过期，过期就删除
​
惰性删除为redis服务器内置策略
​
定期删除可以通过：
​
第一、配置redis.conf 的hz选项，默认为10 （即1秒执行10次，100ms一次，值越大说明刷新频率越快，对Redis性能损耗也越大） 
第二、配置redis.conf的maxmemory最大值，当已用内存超过maxmemory限定时，就会触发主动清理策略

 

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

1.3.1 淘汰策略概述

什么叫数据淘汰策略？什么样的应用场景需要用到数据淘汰策略？

当新数据进入redis时，如果内存不足怎么办？在执行每一个命令前，会调用freeMemoryIfNeeded()检测内存是否充足。如果内存不满足新 加入数据的最低存储要求，redis要临时删除一些数据为当前指令清理存储空间。清理数据的策略称为逐出算法。

注意：逐出数据的过程不是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

那数据删除的策略policy到底有几种呢？一共是3类8种

第一类：检测易失数据（可能会过期的数据集server.db[i].expires ）

volatile-lru：挑选最近最少使用的数据淘汰
volatile-lfu：挑选最近使用次数最少的数据淘汰
volatile-ttl：挑选将要过期的数据淘汰
volatile-random：任意选择数据淘汰

 

 

第二类：检测全库数据（所有数据集server.db[i].dict ）

allkeys-lru：挑选最近最少使用的数据淘汰
allkeLyRs-lfu：：挑选最近使用次数最少的数据淘汰
allkeys-random：任意选择数据淘汰，相当于随机

第三类：放弃数据驱逐

no-enviction（驱逐）：禁止驱逐数据(redis4.0中默认策略)，会引发OOM(Out Of Memory)

注意：这些策略是配置到哪个属性上？怎么配置？如下所示

maxmemory-policy volatile-lru

数据淘汰策略配置依据

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

2.主从复制

2.1 主从复制简介

2.1.1 高可用

首先我们要理解互联网应用因为其独有的特性我们演化出的三高架构

• 高并发

  应用要提供某一业务要能支持很多客户端同时访问的能力，我们称为并发，高并发意思就很明确了

• 高性能

  性能带给我们最直观的感受就是：速度快，时间短

• 高可用

可用性：一年中应用服务正常运行的时间占全年时间的百分比，如下图：表示了应用服务在全年宕机的时间

 

 

我们把这些时间加在一起就是全年应用服务不可用的时间，然后我们可以得到应用服务全年可用的时间

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分钟

 

2.1.2 主从复制概念

知道了三高的概念之后，我们想：你的“Redis”是否高可用？那我们要来分析单机redis的风险与问题

问题1.机器故障

• 现象：硬盘故障、系统崩溃

• 本质：数据丢失，很可能对业务造成灾难性打击

• 结论：基本上会放弃使用redis.

问题2.容量瓶颈

• 现象：内存不足，从16G升级到64G，从64G升级到128G，无限升级内存

• 本质：穷，硬件条件跟不上

• 结论：放弃使用redis

结论：

为了避免单点Redis服务器故障，准备多台服务器，互相连通。将数据复制多个副本保存在不同的服务器上，连接在一起，并保证数据是同步的。即使有其中一台服务器宕机，其他服务器依然可以继续提供服务，实现Redis的高可用，同时实现数据冗余备份。

多台服务器连接方案：

 

 

• 提供数据方：master

主服务器，主节点，主库主客户端

• 接收数据方：slave

从服务器，从节点，从库

从客户端

• 需要解决的问题：

数据同步（master的数据复制到slave中）

 

这里我们可以来解释主从复制的概念：

概念：主从复制即将master中的数据即时、有效的复制到slave中

特征：一个master可以拥有多个slave，一个slave只对应一个master

职责：master和slave各自的职责不一样

master:

写数据
​
执行写操作时，将出现变化的数据自动同步到slave
​
读数据（可忽略）

slave:

读数据
​
写数据（禁止）

2.1.3 主从复制的作用

• 读写分离：master写、slave读，提高服务器的读写负载能力

• 负载均衡：基于主从结构，配合读写分离，由slave分担master负载，并根据需求的变化，改变slave的数 量，通过多个从节点分担数据读取负载，大大提高Redis服务器并发量与数据吞吐量

• 故障恢复：当master出现问题时，由slave提供服务，实现快速的故障恢复

• 数据冗余：实现数据热备份，是持久化之外的一种数据冗余方式

• 高可用基石：基于主从复制，构建哨兵模式与集群，实现Redis的高可用方案

2.2 主从复制工作流程

主从复制过程大体可以分为3个阶段

• 建立连接阶段（即准备阶段）

• 数据同步阶段

• 命令传播阶段（反复同步）

 

 

而命令的传播其实有4种，分别如下：

 

 

 

2.2.1 主从复制的工作流程（三个阶段）

2.2.1.1 阶段一：建立连接

建立slave到master的连接，使master能够识别slave，并保存slave端口号

流程如下：

1. 步骤1：设置master的地址和端口，保存master信息

2. 步骤2：建立socket连接

3. 步骤3：发送ping命令（定时器任务）

4. 步骤4：身份验证

5. 步骤5：发送slave端口信息

至此，主从连接成功！

当前状态：

slave：保存master的地址与端口

master：保存slave的端口

总体：之间创建了连接的socket

 

 

 

master和slave互联

接下来就要通过某种方式将master和slave连接到一起

方式一：客户端发送命令

slaveof masterip masterport

方式二：启动服务器参数

redis-server --slaveof masterip masterport

方式三：服务器配置（主流方式）

slaveof masterip masterport

slave系统信息

master_link_down_since_seconds
masterhost & masterport

master系统信息

uslave_listening_port(多个)

主从断开连接

断开slave与master的连接，slave断开连接后，不会删除已有数据，只是不再接受master发送的数据