乐趣区

关于redis:Redis哨兵3

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 哨兵机制的配置
退出移动版