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资源维护内存
随机抽查，重点抽查

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配置

3.哨兵模式

3.1 哨兵简介

3.1.1 哨兵概念

首先我们来看一个业务场景：如果redis的master宕机了，此时应该怎么办？

那此时我们可能需要从一堆的slave中重新选举出一个新的master，那这个操作过程是什么样的呢？这里面会有什么问题出现呢？

要实现这些功能，我们就需要redis的哨兵，那哨兵是什么呢？

哨兵

哨兵(sentinel) 是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的master并将所有slave连接到新的master。

3.1.2 哨兵作用

哨兵的作用：

监控：监控master和slave
不断的检查master和slave是否正常运行
master存活检测、master与slave运行情况检测
通知（提醒）：当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知
自动故障转移：断开master与slave连接，选取一个slave作为master，将其他slave连接新的master，并告知客户端新的服务器地址

注意：哨兵也是一台redis服务器，只是不提供数据相关服务，通常哨兵的数量配置为单数

3.2 启用哨兵

配置哨兵

配置一拖二的主从结构（利用之前的方式启动即可）
配置三个哨兵（配置相同，端口不同），参看sentinel.conf

1：设置哨兵监听的主服务器信息， sentinel_number表示参与投票的哨兵数量

sentinel monitor master_name  master_host	master_port	 sentinel_number

2：设置判定服务器宕机时长，该设置控制是否进行主从切换

sentinel down-after-milliseconds master_name	million_seconds

3：设置故障切换的最大超时时

sentinel failover-timeout master_name	million_seconds

4：设置主从切换后，同时进行数据同步的slave数量，数值越大，要求网络资源越高，数值越小，同步时间越长

sentinel parallel-syncs master_name sync_slave_number

启动哨兵

redis-sentinel filename

3.3 哨兵工作原理

哨兵在进行主从切换过程中经历三个阶段

监控
通知
故障转移

3.3.2 通知

sentinel在通知阶段要不断的去获取master/slave的信息，然后在各个sentinel之间进行共享，具体的流程如下：

3.3.3 故障转移

当master宕机后sentinel是如何知晓并判断出master是真的宕机了呢？我们来看具体的操作流程

当sentinel认定master下线之后，此时需要决定更换master，那这件事由哪个sentinel来做呢？这时候sentinel之间要进行选举，如下图所示：

在选举的时候每一个人手里都有一票，而每一个人的又都想当这个处理事故的人，那怎么办？大家就开始抢，于是每个人都会发出一个指令，在内网里边告诉大家我要当选举人，比如说现在的sentinel1和sentinel4发出这个选举指令了，那么sentinel2既能接到sentinel1的也能接到sentinel4的，接到了他们的申请以后呢，sentinel2他就会把他的一票投给其中一方，投给谁呢？谁先过来我投给谁，假设sentinel1先过来，所以这个票就给到了sentinel1。那么给过去以后呢，现在sentinel1就拿到了一票，按照这样的一种形式，最终会有一个选举结果。对应的选举最终得票多的，那自然就成为了处理事故的人。需要注意在这个过程中有可能会存在失败的现象，就是一轮选举完没有选取，那就会接着进行第二轮第三轮直到完成选举。

接下来就是由选举胜出的sentinel去从slave中选一个新的master出来的工作，这个流程是什么样的呢？

首先它有一个在服务器列表中挑选备选master的原则

不在线的OUT
响应慢的OUT
与原master断开时间久的OUT
优先原则
优先级 offset runid

选出新的master之后，发送指令（ sentinel ）给其他的slave：

向新的master发送slaveof no one
向其他slave发送slaveof 新masterIP端口

总结：故障转移阶段

发现问题，主观下线与客观下线
竞选负责人
优选新master
新master上任，其他slave切换master，原master作为slave故障恢复后连接

4.集群cluster

现状问题：业务发展过程中遇到的峰值瓶颈

redis提供的服务OPS可以达到10万/秒，当前业务OPS已经达到10万/秒
内存单机容量达到256G，当前业务需求内存容量1T
使用集群的方式可以快速解决上述问题

4.1 集群简介

集群就是使用网络将若干台计算机联通起来，并提供统一的管理方式，使其对外呈现单机的服务效果

集群作用：

分散单台服务器的访问压力，实现负载均衡
分散单台服务器的存储压力，实现可扩展性
降低单台服务器宕机带来的业务灾难

4.2 Cluster集群结构设计

数据存储设计：

通过算法设计，计算出key应该保存的位置
将所有的存储空间计划切割成16384份，每台主机保存一部分
注意：每份代表的是一个存储空间，不是一个key的保存空间
将key按照计算出的结果放到对应的存储空间

那redis的集群是如何增强可扩展性的呢？譬如我们要增加一个集群节点

当我们查找数据时，集群是如何操作的呢？

各个数据库相互通信，保存各个库中槽的编号数据
一次命中，直接返回
一次未命中，告知具体位置

4.3 Cluster集群结构搭建

首先要明确的几个要点：

配置服务器（3主3从）
建立通信（Meet）
分槽（Slot）
搭建主从（master-slave）

Cluster配置

是否启用cluster，加入cluster节点

cluster-enabled yes|no

cluster配置文件名，该文件属于自动生成，仅用于快速查找文件并查询文件内容

cluster-config-file filename

节点服务响应超时时间，用于判定该节点是否下线或切换为从节点

cluster-node-timeout milliseconds

master连接的slave最小数量

cluster-migration-barrier min_slave_number

Cluster节点操作命令

查看集群节点信息

cluster nodes

更改slave指向新的master

cluster replicate master-id

发现一个新节点，新增master

cluster meet ip:port

忽略一个没有solt的节点

cluster forget server_id

手动故障转移

cluster failover

集群操作命令：

创建集群

redis-cli –-cluster create masterhost1:masterport1 masterhost2:masterport2  masterhost3:masterport3 [masterhostn:masterportn …] slavehost1:slaveport1  slavehost2:slaveport2 slavehost3:slaveport3 -–cluster-replicas n

注意：master与slave的数量要匹配，一个master对应n个slave，由最后的参数n决定

master与slave的匹配顺序为第一个master与前n个slave分为一组，形成主从结构

添加master到当前集群中，连接时可以指定任意现有节点地址与端口

redis-cli --cluster add-node new-master-host:new-master-port now-host:now-port

添加slave

redis-cli --cluster add-node new-slave-host:new-slave-port master-host:master-port --cluster-slave --cluster-master-id masterid

删除节点，如果删除的节点是master，必须保障其中没有槽slot

redis-cli --cluster del-node del-slave-host:del-slave-port del-slave-id

重新分槽，分槽是从具有槽的master中划分一部分给其他master，过程中不创建新的槽

redis-cli --cluster reshard new-master-host:new-master:port --cluster-from src-  master-id1, src-master-id2, src-master-idn --cluster-to target-master-id --  cluster-slots slots

注意：将需要参与分槽的所有masterid不分先后顺序添加到参数中，使用，分隔

指定目标得到的槽的数量，所有的槽将平均从每个来源的master处获取

重新分配槽，从具有槽的master中分配指定数量的槽到另一个master中，常用于清空指定master中的槽

redis-cli --cluster reshard src-master-host:src-master-port --cluster-from src-  master-id --cluster-to target-master-id --cluster-slots slots --cluster-yes