共计 5240 个字符，预计需要花费 14 分钟才能阅读完成。
1.1 什么是长久化
阐明:Redis 运行环境在内存中, 如果 redis 服务器敞开, 则内存数据将会失落.
需要: 如何保留内存数据呢?
解决方案: 能够定期将内存数据长久化到磁盘中.
长久化策略规定:
当 redis 失常运行时, 定期的将数据保留到磁盘中, 当 redis 服务器重启时, 则依据配置文件中指定的长久化的形式, 实现数据的复原.(读取数据, 之后复原数据.)
1.2 RDB 模式
1.2.1RDB 模式特点阐明
1).RDB 模式是 Redis 默认的策略.
2).RDB 模式可能定期 (工夫距离) 长久化. 弊病: 可能导致数据的失落.
3).RDB 模式记录的是内存数据的快照. 长久化效率较高. 快照只保留最新的记录.
1.2.2 RDB 模式命令
1.save 命令: 将内存数据长久化到磁盘中 被动的操作 会造成线程阻塞
2.bgsave 命令: 将内存数据采纳后盾运行的形式, 长久化到文件中. 不会造成阻塞.
3. 默认的长久化的机制
save 900 1 如果在 900 秒内, 执行了 1 次更新操作, 则长久化一次
save 300 10 如果在 300 秒内, 执行了 10 次更新操作, 则长久化一次
save 60 10000 如果在 60 秒内, 执行了 10000 次更新操作, 则长久化一次
1.2.3 长久化文件配置
1). 指定长久化文件
2). 指定长久化文件目录
1.3 AOF 模式
1.3.1 AOF 模式特点
1).AOF 模式默认条件下是敞开的. 须要手动开启
2).AOF 模式记录的是用户的操作过程, 所以能够实现实时长久化操作.
3).AOF 模式因为记录的是实时的操作过程, 所以长久化文件较大. 须要定期维护.
1.3.2 启动 AOF 模式
阐明: 如果一旦开启 AOF 模式, 则以 AOF 模式为准.
1.4 对于长久化操作总结
1. 当内存数据容许大量失落时, 采纳 RDB 模式 (快)
2. 当内存数据不容许失落时, 采纳 AOF 模式(定期维护长久化文件)
3. 个别在工作中采纳 RDB+AOF 模式独特作用, 保证数据的有效性.
1.5 面试题
问题: 如果小李 (丑陋妹子) 在公司服务器中执行了 flushAll 命令, 问怎么办?
答: 须要找到 aof 文件之后, 删除 flushAll 命令 之后重启 redis, 执行 save 命令即可.
2. 内存优化策略
2.1 为什么须要内存优化
阐明: 因为 redis 在内存中保留数据. 如果始终存储, 则内存数据必然溢出. 所以须要定期维护内存数据的大小.
保护策略: 删除旧的不必的数据, 保留新的罕用的数据
2.2 LRU 算法
LRU 是 Least Recently Used 的缩写，即最近起码应用 ，是一种罕用的页面置换算法，抉择最近最久未应用的页面予以淘汰。该算法赋予每个页面一个拜访字段，用来记录一个页面自上次被拜访以来所经验的工夫 t，当须淘汰一个页面时，抉择现有页面中其 t 值最大的，即最近起码应用的页面予以淘汰。
计算维度: 工夫 T
注意事项: LRU 算法是迄今为止内存中最好用的数据置换算法.
2.3 LFU 算法
LFU（least frequently used (LFU) page-replacement algorithm）。即最不常常应用页置换算法 ，要求在页置换时置换 援用计数 最小的页，因为常常应用的页应该有一个较大的援用次数。然而有些页在开始时应用次数很多，但当前就不再应用，这类页将会长工夫留在内存中，因而能够将援用计数寄存器定时右移一位，造成指数衰减的均匀应用次数。
维度: 应用次数
2.4 随机算法
随机算法.
2.5 TTL 算法
依据残余的存活工夫, 将马上要超时的数据提前删除.
2.6 配置内存优化策略
`1.volatile-lru 在设定了超时工夫的数据中, 采纳 lru 算法
2.allkeys-lru 在所有的数据中, 采纳 lru 算法 `
3.volatile-lfu 在设定了超时工夫的数据中, 采纳 lfu 算法
4.allkeys-lfu 所有数据采纳 lfu 算法
5.volatile-random 设置超时工夫数据的随机算法
6.allkeys-random 所有数据的随机
7.volatile-ttl 将设定了超时工夫的数据, 提前删除.
8.noeviction 默认规定 如果设定 noeviction 则不删除数据, 间接报错返回.
手动批改 redis 内存优化策略:
3. 对于缓存面试问题
问题出发点:
因为 缓存生效, 导致大量的用户的申请, 间接拜访数据库服务器. 导致负载过高, 从而引发整体宕机的危险!!!
3.1 缓存穿透
阐明: 用户 频繁拜访数据库中不存在的数据 , 可能呈现缓存穿透的景象. 如果该操作是高并发操作, 则可能间接威逼数据库服务器.
解决方案:
1. 采纳 IP 限流的形式 升高用户拜访服务器次数. IP 动静代理(1 分钟变一次)
2. 微服务的解决形式: 利用断路器返回执行的业务数据即可不执行数据库操作 从而爱护了数据库.
3. 微服务解决形式: API 网关设计. 不容许做非法操作
3.2 缓存击穿
阐明: 因为 redis 中 某个 热点数据 因为超时 / 删除等操作造成数据生效 . 同时用户高并发拜访该数据, 则可能导致数据库宕机. 该操作称之为 缓存击穿.
解决方案: 能够采纳多级缓存的设计. 同时数据的超时工夫采纳随机数的形式.
3.3 缓存雪崩
阐明: 因为 redis 内存 数据大量生效 . 导致用户的拜访命中率太低. 大量的用户间接拜访数据库, 可能导致数据库服务器宕机. 这种景象称之为缓存雪崩.
解决:
1. 采纳多级缓存.
2. 设定不同的超时工夫
3. 禁止执行 flushAll 等敏感操作.
4.Redis 分片机制
4.1 Redis 分片阐明
阐明: 如果须要 Redis 存储海量的内存数据, 应用单台 redis 不能满足用户的需要, 所以能够采纳 Redis 分片机制实现数据存储.
注意事项:
如果有多台 redis, 则其中的数据都是不一样的…
4.2 Redis 部署
搭建端口:6379/6380/6381
4.2.1 筹备配置文件:
6379.conf 6380.conf 6381.conf
4.2.2 批改端口号
只批改 80/81 的端口即可
4.3 Redis 分片测试
`@Test
public void testShards(){List<JedisShardInfo> shards = new ArrayList<>();
shards.add(new JedisShardInfo("192.168.126.129", 6379));
shards.add(new JedisShardInfo("192.168.126.129", 6380));
shards.add(new JedisShardInfo("192.168.126.129", 6381));
ShardedJedis shardedJedis = new ShardedJedis(shards);
shardedJedis.set("shards", "redis 分片操作!!!");
System.out.println(shardedJedis.get("shards"));
}`
4.4 一致性 HASH 算法
4.4.1 概念
一致性哈希算法在 1997 年由麻省理工学院提出，是一种非凡的哈希算法，目标是 解决分布式缓存的问题 。
[1] 在 移除 或者 增加 一个服务器时，可能 尽可能小地扭转 已存在的服务申请与解决申请服务器之间的 映射关系。一致性哈希解决了简略哈希算法在分布式哈希表(Distributed Hash Table，DHT) 中存在的动静伸缩等问题 [2]。
4.4.2 原理阐明
常识温习:
- 惯例 hash 由多少位 16 进制数组成??? 8 位 16 进制数组成 2^32 次方
- 如果对雷同的数据进行 hash 计算问后果是否雷同??? 后果必然雷同.
4.4.3 个性一平衡性
①平衡性是指 hash 的后果应该平均分配到各个节点，这样从算法上解决了负载平衡问题.
实现平衡性的计划: 引入虚构节点
4.4.3 个性二枯燥性
②枯燥性是指在新增或者删减节点时，不影响零碎失常运行 [4]。
特点: 在进行数据迁徙时, 要求尽可能小的扭转数据.
4.4.4 个性三分散性
③分散性是指数据应该扩散地寄存在分布式集群中的各个节点 (节点本人能够有备份)，不用每个节点都存储所有的数据 [4]。
俗语: 鸡蛋不要到放到一个篮子里
4.5 SpringBoot 整合 Redis 分片
4.5.1 编辑 properties 配置文件
`# 配置单台 redis 服务器
#redis.host=192.168.126.129
#redis.port=6379
## 配置 redis 分片
redis.nodes=192.168.126.129:6379,192.168.126.129:6380,192.168.126.129:6381`
4.5.2 编辑配置类
`package com.jt.config;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.PropertySource;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisShardInfo;
import redis.clients.jedis.ShardedJedis;
import java.util.ArrayList;
import java.util.List;
@Configuration // 标识我是配置类
@PropertySource("classpath:/properties/redis.properties")
public class RedisConfig {
/**
* SpringBoot 整合 Redis 分片, 本质:ShardedJedis 对象, 交给容器治理
*/
@Value("${redis.nodes}")
private String nodes; //node,node,node
@Bean
public ShardedJedis shardedJedis(){List<JedisShardInfo> shards = new ArrayList<>();
String[] nodeArray = nodes.split(",");
for (String node : nodeArray){ //node=ip:port
String host = node.split(":")[0];
int port = Integer.parseInt(node.split(":")[1]);
// 筹备分片节点信息
JedisShardInfo info = new JedisShardInfo(host, port);
shards.add(info);
}
return new ShardedJedis(shards);
}
/* @Value("${redis.host}")
private String host;
@Value("${redis.port}")
private Integer port;
@Bean
public Jedis jedis(){return new Jedis(host, port);
}*/
}`
4.5.3 批改 AOP 缓存注入
阐明: 将 AOP 中的注入对象切换为分片对象
5 Redis 哨兵机制
5.1 分片机制存在的问题
阐明: redis 分片次要的作用是实现内存数据的扩容. 然而如果 redis 分片中有一个节点宕机, 则间接影响所有节点的运行. 是否优化?
实现策略: 采纳 Redis 哨兵机制实现 Redis 节点高可用.
5.2 Redis 节点主从配置
5.2.1 筹备主从节点
1). 敞开 redis 分片的节点, 之后复制配置文件筹备哨兵的配置.
2). 复制分片的目录 改名为 sentinel
3). 删除多余的长久化文件, 保留 redis 配置文件
4). 启动 3 台 Redis 服务器
5.2.2 实现 redis 主从
命令: info replication 查看 redis 节点的状态信息
节点划分: 6379 当主机 6380/81 当从机
命令 2: 实现主从挂载 slaveof host port
3). 查看 6379 主机的状态
论断: redis 所有节点都能够雷同通信. 并且门路以后的主从的状态.
数据主从同步的状态
5.3 哨兵机制工作原理
1). 当哨兵启动时, 会链接 redis 主节点, 同时获取所有节点的状态信息
2). 当哨兵间断 3 次通过心跳检测机制(PING-PONG), 如果发现主机宕机, 则开始选举.
3). 哨兵外部通过随机算法筛选一台从机入选新的主机. 其余的节点应该当新主机的从.
5.4 哨兵机制配置
5.4.1 敞开保护模式
5.4.2 开启后盾运行
5.4.3 配置投票机制
5.4.4 批改投票工夫
主机宕机 3 秒之后开始选举
5.5 哨兵高可用测试
1. 启动哨兵 redis-sentinel sentinel.conf
2). 查看哨兵配置
3) 将主机宕机, 之后查看从机是否入选主机
4). 启动之前的主机, 查看是否入选新主机的从
5). 如果搭建异样 则删除重做
敞开所有 redis 服务器.
