Redis进阶篇幅--删除策略、主从复制、哨兵模式

Redis————— 删除策略

**过期数据**
Redis是一种内存级数据库，所有的数据均存放在内存中，内存中的数据可以他用过TTL指令获取其状态
 XX  具有时效性
-1  永久有效的数据
-2  已经过期的数据 或被删除的数据 或未定义的数据

数据删除策略的目标

	在内存占用与CPU占用之间寻找一种平衡，顾此失彼都会造成整体redis‘性能的下降

甚至引发服务器宕机或内存泄漏
数据删除策略

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

惰性删除

	数据到达过期时间 不做处理 等下次访问该数据时
			判断是否过期expirelNeeded()
			1.如果发现没有过期  返回数据
			2.发现数据已经过期  删除  返回不存在
	优点  节约cpu  发现必须删除的时候才删除
	缺点  内存压力很大 出现长期占用内存的数据
	总结  用存储空间换取处理器性能(拿空间换取时间)
定期删除
	Redis’启动服务器初始化时、读取配置server.hz的值  默认是10
	每秒执行server.hz次serverCron() 频度  --databaseCron()---activeExpireCycle()  对每个expires[*] 逐一进行检测  每次执行250ms/server.hz  执行工作时长
	对某个expires[*]  随机挑选W个key检测
					1.如果某个key超时  删除key
					2.如果一轮中删除的key的数量>W*25%  循环该过程
	参数current_db用于记录activeExpireCycle() 进入那个expires[*]执行
	如果activeExpireCycle()执行时间到期 下次从current_db继续向下执行

定期删除

周期性轮询redis库中的时效性数据  采用随机抽取的资格  利用过期数据占比的方式控制删除频度
	特点 cpu性能占用设置有峰值  检测频度可自行设置
		 内存压力不是很大  长期暂用内存的冷数据会被持续清理
	总结  周期性抽查存储空间（随机抽查、重点抽查）


数据淘汰策略(数据逐出算法)

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

Redis使用内存存储数据  在执行每一个命令前 会调用freeMemioryifNeeded() 检测内存是否充足 如果内存不满足新加入数据的最低存储要求  redis要零食删除一些数据为当前指令清理存储空间  清理数据的策略为逐出算法  逐出策略

注意 逐出数据的过程不是100%能够清理处足够的可使用的内存空间 如果不成功则反复执行 当对所有数据尝试完毕 如不能达到内存清理的要求 将出现错误信息

影响数据淘汰的相关配置

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

	Maxmemory ? mb

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

	Maxmemory-samples  count

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

	Maxmemory-polioy   policy

检测易失数据 (可能会过期的数据集server.db[i].expires)

1.volatile-lru  挑选一段时间最少使用的淘汰
2.volatile-lfu  挑选一段时间使用次数最少的数据淘汰
3.volatile-ttl   挑选将要过期的数据淘汰
4.volatile-random  任意选择数据淘汰

扩大范围

1.检测全库数据 （所有数据集server.db[i].dict）
2.Alkeys-lru  挑选一段时间最少使用的淘汰
3.Alkeys-lfu  挑选一段时间使用次数最少的数据淘汰
4.Alkeys-ttl  挑选将要过期的数据淘汰

放弃数据驱逐

No-enviction(驱逐)  禁止驱逐数据(redis4.0中默认策略)  会引发错误OOM（out  of Memory）

对应设置

Maxmemory-policy volatile-lru  进行属性设置

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

Redis————— 主从复制

主从复制简介

互联网三高架构
	高并发
	高性能
	高可用  服务器 正常运行时间 占全年时间的比值
	业界可用性目标 99.999%   即服务器年宕机时长低于315秒

Redis是否高可用？
机器故障 硬盘故障 系统崩溃
容量瓶颈 内存不足

结论

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

多台服务器连接方案 master

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

接收数据方 slave

	从服务器 从节点  从库
	从客户端

主从复制 数据的及时性和有效性

主从复制将master中的数据即时、有效的复制到slave中
一个master可以拥有多个slave  一个slave值对应一个master

Master

写数据
执行写操作时  将出现变化的数据自动同步到slave

Slave

读数据
写数据（禁止）

主从复制的作用

1. 读写分离 master写 slave读 提高服务器的读写负载能力 负载均衡 基于主从结构 配合读写分离

2. 由slave分担master负载 并根据需求的变化 改变slave的数量 通过多个从节点分担数据读取负载

3. 大大提高Redis服务器并发量与数据吞吐量 故障恢复 当master出现问题时 由slave提供服务 实现快速的故障恢复 数据冗余

4. 实现数据热备份 是持久化之外的一种数据冗余方式 高可用基石 基于主从复制 构建哨兵模式与集群 实现Redis高可用方案、

主从复制工作流程

建立连接阶段（准备阶段）
建立slave到master的连接 使master能够识别slave 并保存slave端口号

1. 建立master的地址和端口，保存master信息
2. 建立socke(信息通道)连接
3. 发送ping命令(定时任务)
4. 身份验证
5. 发送slave端口信息、

主连接(slave连接master)

方式一 客户端发送命令
	Slaveof  masterip masterport
	
方式二  启动服务器参数
	Redis-server-slaveof masterip masterport
	
方式三  服务器配置
	Slaveof masterip masterport
	在redis-conf配置文件中 加入 slaveof  ip地址  端口号
	Info命令  可以查看连接的信息

主从断开连接

• 断开slave与master的连接 slave断开连接后 不会删除已有数据 只是不在接收master发送的数据
• Slaveof no one slave的客户端执行

授权访问

master客户端发送命令设置密码

	requirepass  password

mater配置文件设置密码

	config set requirepass password
	config get requirepass 

slave客户端发送命令设置密码

	auth  password

slave配置文件设置密码

	masterauth  password

slave启动服务器设置密码

	redis-server  -a password

数据同步阶段

在slaver初次来凝结master后  复制master中的所有数据到slave
将slave的数据库更新撑master当前的数据库状态

请求同步数据

• 创建RDB同步数据
• 恢复RDB同步数据
• 请求部分同步数据
• 恢复部分同步数据

当前状态：
Slave 具有master段全部数据 包含RDB过程接收的数据
Master 保存slave当前数据同步的位置
总体 之间完成了数据克隆

数据同步阶段master说明

1. 如果master数据量巨大 数据同步阶段应避开流量高峰期，避免造成master阻塞 影响业务正常执行

2. 复制缓冲区大小设定不合理 会导致数据溢出 如进行全量复制周期太长 进行部分复制发现数已经存在丢失的情况 必须进行第二次全量复制
   致使slave陷入死循环状态

   	Repl-bocklog-size   设置大小 
   

3. Master单机内存占用主内存的比例不应大 使用六七成的内存
   留下三四成用于执行bgsave命令和创建复制缓冲区

数据同步阶段slave说明

1. 为避免slave进行全量复制、部分复制时服务器响应阻塞或数据不同步 建议关闭此期间的对外服务
   slabe-serve-stale-data yes|no
2. 数据同步阶段 master发送给slave信息可以理解master是slaved一个客户端主动向slave发送命令
3. 多个slave同时对master请求数据同步 master发送的RDB文件增多 会对带宽造成巨大冲击 如果master带宽不足, 因此数据同步需要根据业务需求 适量错峰

命令传播阶段与复制缓冲区工作原理

当master数据库状态被修改后  导致服务器数据库状态不一致
		此时需要让主从数据同步到一致的状态  同步的动作成为命令传播\
Master将接收到的数据更命令发送给slave  slave接收命令后执行命令

命令传播阶段的部分复制

命令阶段出现断网现象
	网络闪断闪连      忽略
	短时间网络中断    部分复制
	长时间网络中断	全量复制

部分复制的三个核心要素

	服务器的运行id(run  id)
	主服务器的复制积压缓冲区
	主从服务器的复制偏移量

复制缓冲区

复制换缓冲区 又名 复制积压缓冲区 是一个先进先出(FIFO)的队列 用于存储服务器执行过的命令 每次传播命令 master都会将传播的命令记录下来 并存储在复制缓冲区

复制缓冲区默认数据存储空间大小是1M

当入队列元素的数量大于队列长度时 最先入队的元素会被弹出 而新元素会被放入队列

作用

 用于保存master收到的所有指令 （仅影响数据变更的指令  例如set   sekect）,
 数据来源 当master接收到主客户的指令时 除了将指令执行 会将改指令存储到缓冲区中

主从服务器复制偏移量(offset)

	同步信息  比对master与slave的差异  当slave断线后  恢复数据使用

数据同步+命令传播阶段工作流程

心跳机制

进入命令传播阶段 master与slave间需要进行信息交换 使用心跳机制进行维护  实现双方连接保持在线

Master 心跳

内部指令  ping
周期  由repl-ping-period决定 默认10s
作用  判断slave是否在线
查询  INFO replication  获取slave最后一次连接时间间隔 lag项目维持在0或1视为正常

Slave心跳任务

	内部指令 replconf  ack {offset}
	周期  1s
	作用  汇报slave自己的复制了、偏移量 获取最新的数据指令  
	判断master是否在线

Redis————— 哨兵模式

哨兵简介

当主机 宕机
关闭master和所有slave

关闭期间的数据服务谁来继承

找一个slave作为master

	找一个主  怎么找法

修改其他slave的配置，连接新的主

	修改配置后  原始的主怎么恢复	

启动新的master与slave

全量复制N+部分复制N

哨兵 Sentinel

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

哨兵的作用

监控
1. 不断的检查master和slave是否正常运行
2. Master存活检测 master与slave运行情况检测

通知(提醒) 当监控的服务器出现问题时，向其他(哨兵间 客户端)发送通知
自动故障转移：断开master与slave连接 选取一个slave作为master，将其他slave连接新的master，并告知客户端新的服务器地址

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

启用哨兵模式
配置一拖二的主从结构
配置三个哨兵(配置相同，端口不同)

		启动哨兵
	Redis-sentinel  filename