共计 2414 个字符，预计需要花费 7 分钟才能阅读完成。
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 所有节点都能够雷同通信,
5.2 哨兵机制的工作原理
5.3 哨兵机制的配置
