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服务器.