1.Redis长久化策略
1.1 什么是长久化:
阐明:
Redis运行环境在内存中,如果服务器敞开则内存数据讲话失落;
需要: 如何放弃内存数据
解决方案:能够定期将内存数据长久化到磁盘中
长久化策略规定:
当redis失常运行时,定期的将数据保留到磁盘中,当redis服务器重启时,则依据配置文件中指定的长久化形式,事项数据的回复(读取数据之后回复数据)
1.2 RDB模式:
1.2.1 RDB模式 是Redis默认的策略;
1.2.2 RDB模式 可能定期长久化(工夫距离),弊病_可能导致数据的失落;
1.2.3 RDB模式 记录的是内存数据的快照,长久化效率较高,快照只保留最新记录;
1.2.4 RDB模式命令:
- save 命令:将内存数据长久化到磁盘中 —-主动式操作
毛病___ 会造成线程的阻塞
- bgsave 命令:将内存数据采纳后盾运行的形式,长久化到磁盘中
- 默认的长久化的机制:
a. save 900 1 如果在900秒内执行了1次更新操作,则长久化一次
b. save 300 10 如果在300秒内执行了10次更新操作,则长久化一次
c. save 60 10000 如果在60秒内执行了10000次更新操作,则长久化一
1.3 AOF模式:
1.3.1 AOF模式特点:
- AOF模式默认条件下是敞开的,须要手动开启;
- AOF模式记录的是用户的操作过程,所以能够实现实时长久化操作;
- AOF模式因为记录的是实时的操作过程,所以长久化文件较大,须要定期维护;
1.3.2 启动AOF模式:
(redis 重启 redis-cli sutd缩写)
- 阐明: 如果开启AOF模式 则一AOF模式为准
如何开启:进入 vim redis.conf 批改appendonly no 批改为yes
1.4 对于长久化操作总结:
- 当内存数据容许大量失落是,应用RDB模式(快);
- 当内存数据不容许数据失落是,采纳AOF(定期须要保护);
- 个别在工作中采纳AOF+RDB模式独特作用,保证数据的有效性
2. Redis内存策略
2.1为什么须要内存优化
- 阐明:因为redis在内存中保留数据,如果始终存储,则内存必然溢出
所以须要定期维护内存数据的大小
- 保护策略:
删除旧的不必的数据,保留新的罕用的数据;
2.2 LRU算法:
- 阐明:
LRU最近起码应用,是一种罕用的页面置换算法,抉择最近最久未应用的数据予以淘汰; - 计算维度
工夫T - 注意事项:
是迄今为止内存中最好用的数据置换算法;
2.3 LFU算法
- 阐明:
最不常常应用数据置换算法 ,要求在数据置换是置换援用计数最下的数据,因为常常应用的数据应该有一个较大的援用次数; - 计算维度:
应用次数
2.4 随机算法
2.5 TTL算法
- 阐明
依据存活工夫,将马上要超时的数据提前删除;
2.6 配置内存优化策略
- valatile-lru 在设定了超时工夫的数据,采纳lru算法
- allkeys-lru 在所有的数据中采纳lru算法
- volatile-lfu 在设定了超时工夫的诗句中采纳lfu算法
- allkeys-lfu 所有数据采纳lfu算法
- volatile-random 设置超时工夫数据的随机算法
- allkeys-random 所有数据随机
- volatile-ttl 将设定了超时工夫的数据 提前删除
- noeviction 如果设置了noeviction 则不删除数据 间接保留返回
3. 对于缓存的面试问题
问题出发点:
因为缓存生效,导致大量用户间接拜访后盾数据库,
- 3.1 缓存穿透
阐明:
用户频繁拜访数据库中不存在的数据是,可能呈现缓存穿透的景象,如果该操作是高斌发操作,则肯能间接威逼数据库服务器;
解决办法:
A. 能够采纳IP限流的形式,升高用户拜访服务器次数;
B. 微服务解决形式:
利于断路器 返回指定的业务数据即可;不执行数据操作爱护数据库
C. 微服务解决形式:API网关设计,
- 3.2 缓存击穿
阐明:
因为REdis中某个热点数据超时/删除等操作,导致数据生效,如果用户高并发拜访该数据,则可能导致数据可宕机,该操作称之为 缓存击穿
解决方案:
能够采纳多级缓存的设计;
- 3.3 缓存雪崩
阐明:
因为redis数据大量生效,导致用户拜访命中率太低,=>大量用户间接拜访数据库,导致服务器宕机;
解决方案:
能够采纳多级缓存的设计;
设定不同超时工夫
禁止直行flushall等敏感操作;
### 4. Redis分片阐明
- 阐明:
4.2部署
4.2.1 编制配置文件和批改端口
- 搭建端口号 6379 6380 6381
- 进入redis 根目录 cd /usr/local/src/redis
- 启动redis-server 6380.conf (redis-cli -p 6380 进入服务器)
4.2.2 redis分片测试
-
一致性HASH算法:
A. 概念:是一种非凡的哈希算法,目标就是解决分布式缓存的问题,在移除和增加服务器的时候,可能尽可能小的扭转映射关系;
B. 原理阐明:1). 惯例hash由8位16进制数组成; 2). uuid由23位16进制数组成
C. 只负责管理 不负责存储数据
4.2.3 hash个性一 平衡性
实现平衡性的计划: 引入虚构节点
4.2.4 hash个性二 枯燥性
特点:在进行数据迁徙时尽可能小的扭转的扭转数据
4.2.5 hash个性三 分散性
4.2.6 redis的扩散布局
第一步:配置文件
第二步:编辑配置类
API: ShardedJedis对象
5. Redis哨兵机制
5.1 分片机制存在的问题
- 阐明:
实现内存数据的扩容,如果redis其中有一个节点宕机,就会间接影响所有节点的运行; - 采纳哨兵机制,实现节点的高可用;
5.2 redis主从的部署
- 敞开redis分片的节点,
- 复制分片的目录 改名为sentinel
- 删除多余的长久化文件,保留redis的配置文件
- 启动三台redis服务器
实现redis的主从
- 命令: info replication 查看节点的状态(默认redis都是主机)
实现redis的主从的挂载
- 批改redis服务器状态 (主机和从机的批改)
A.slave of (进入80) 6379 为主机~~~~
B. redis所有节点都能够雷同通信,