关于redis:Redis缓存

1.redis

1.1 什么事 redis

Redis 是一个开源（BSD 许可）的，内存中的数据结构存储系统，它能够用 作数据库、缓存和消息中间件。 它反对多种类型的数据结构，如 字符串（strings），散列（hashes），列表（lists），汇合（sets），有序汇合（sorted sets） 与范畴查问，bitmaps，hyperloglogs 和 天文空间（geospatial）索引半径查问。Redis 内置了 复制（replication），LUA 脚本（Lua scripting），LRU 驱动事件（LRU eviction），事务（transactions）和不同级别的 磁盘长久化（persistence），并通过 Redis 哨兵（Sentinel）和主动 分区（Cluster）提供高可用性（high availability）。

速度: 读: 11.2 万 / 秒 写:8.6 万 / 秒 50 万 / 秒

1.2redis 的做用

引入缓存机制能够无效的缩小用户拜访物理设施的次数, 从而进步相应速度;

1.2 如何设计缓存?

1. 缓存数据如何存储? 应该采纳什么样的数据结构呢? K-V key 的唯一性
2. 缓存数据的容量大小 应该动静保护缓存数据, 将不须要的数据提前删除. LRU 算法 /LFU 算法 / 随机算法 /TTL 算法
3. 缓存数据保留到内存中, 然而内存的特点断电即擦除. 定期将内存数据长久化(写入磁盘中)
4. 单台缓存服务器性能有余, 所以个别须要搭建集群(实现高可用).
5. 应用 C 语言开发.

2 Redis 属性阐明

2.1 Redis 长久化策略

2.1.1 为什么要长久化

Redis 中的记录都保留在内存中, 如果内存断电或者服务器宕机, 则内存数据间接失落. 业务中不容许产生. 所以须要将数据定期进行保护.

2.1.2 RDB 模式

阐明: RDB 模式是 Redis 的默认的长久化策略. 无需手动的开启.
特点:
1.Redis 会定期的执行 RDB 长久化操作. 毛病:可能导致内存数据失落 .
2.RDB 记录的是 内存数据的快照, 并且后续的快照会笼罩之前的快照. 每次只保留最新数据. 效率更高.

命令:
1).save 命令 要求立刻执行长久化操作 save 会造成线程的阻塞.
2).bgsave 命令 后盾执行长久化操作 后盾运行不会造成阻塞. 异步操作, 不能保障立刻执行

2.1.3 AOF 模式

阐明: AOF 模式默认条件下是敞开的, 须要手动的开启, 如果开启了 AOF 模式则 RDB 模式将生效. 然而如果手动执行 save 命令, 则也会生成 RDB 文件.

1). 开启 AOF 模式

特点:
1.AOF 模式记录程序的 执行的过程 . 所以能够 保证数据不失落 .
2. 因为 AOF 记录程序运行的过程, 所以整个 长久化文件绝对大, 所以须要定期维护. 效率低

.1.4 RDB 与 AOF 模式长久化比照

1).RDB 模式
save 900 1 如果在 900 秒内, 执行了一次更新操作则长久化一次
save 300 10
save 60 10000 操作越快 , 长久化的周期越短.

2).AOF 模式
appendfsync always 用户执行一次更新操作, 则长久化一次 异步操作
appendfsync everysec 每秒操作一次
appendfsync no 不被动操作 个别不必.

2.1.5 对于 RDB 与 AOF 总结

策略: 如果数据容许大量失落, 首选 RDB 模式,
如果数据不容许失落则首选 AOF 模式.

企业策略: 又要满足效率, 同时满足数据不失落.
主机: 采纳 RDB 模式
从机: 采纳 AOF 模式

2.1.6 问题

问题 1: 误操作将 redis 服务器执行了 flushAll 命令, 问你如何解决??

解决方案: 须要将从库中的 AOF 文件 进行编辑, 删除多余的 flushAll 命令, 之后重启 redis 即可.

问题 2: 误将 aof 文件一并删除, 问如何解决???
答: 杀人祭天!!!

2.2Redis 内存策略

2.2.1 LRU 算法

LRU 是 Least Recently Used 的缩写，即最近起码应用 ，是一种罕用的页面置换算法，抉择最近最久未应用的页面予以淘汰。该算法赋予每个页面一个拜访字段，用来记录一个页面自上次被拜访以来所经验的工夫 t，当须淘汰一个页面时，抉择现有页面中其 t 值最大的，即最近起码应用的页面予以淘汰。
判断维度: 工夫 T

2.2.2 LFU 算法

LFU（least frequently used (LFU) page-replacement algorithm）。即最不常常应用页置换算法 ，要求在页置换时置换援用计数最小的页，因为常常应用的页应该有一个较大的援用次数。然而有些页在开始时应用次数很多，但当前就不再应用，这类页将会长工夫留在内存中，因而能够将援用计数寄存器定时 右移一位 ，造成指数衰减的均匀应用次数。
判断维度: 应用次数

2.2.3 随机算法

随机算法

2.2.4 TTL 算法

将剩余时间短的数据, 提前删除.

2.2.5 Redis 的内存优化策略

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 设定了超时工夫之后采纳 TTL 算法
8. noeviction 不做任何操作, 只是返回报错信息.
   

2.3 对于 Redis 常见问题

2.3.1 缓存穿透

阐明: 用户高并发环境下拜访 数据库 和缓存 中都 不存在的数据 称之为缓存穿透景象.

解决方案:
1). 禁用 IP 限度 IP 拜访.
2). 限流 每秒最多拜访 3 次
3). 布隆过滤器

布隆过滤器

布隆过滤器（Bloom Filter）是 1970 年由布隆提出的。它实际上是一个 很长的二进制向量和一系列随机映射函数 。布隆过滤器能够 用于检索一个元素是否在一个汇合中。它的长处是空间效率和查问工夫都比个别的算法要好的多，毛病是有肯定的误识别率和删除艰难。

原理:

布隆过滤器优化:
问题: 如何解决 hash 碰撞问题
知识点: 因为hash 碰撞问题, 可能由多个 key 有雷同的地位, 所以得出结论, 布隆过滤器认为数据存在, 那么数据可能存在. 如果布隆过滤器认为数据不存在, 则数据肯定不在.

如何升高 hash 碰撞的几率:
答:
1. 扩容二进制向量位数.
2. 减少 hash 函数的个数
当位数减少 / 函数适当减少, 则能够无效的升高 hash 碰撞的几率. 默认值 0.03

2.3.2 什么是缓存击穿

阐明: 某个 (一个) 热点数据在缓存中忽然生效.导致大量的用户间接拜访数据库. 导致并发压力过高造成异样.

解决方案:
1. 尽可能将热点数据的超时工夫 设定的长一点
2. 设定多级缓存 超时工夫采纳随机算法.

2.3.3 什么是缓存雪崩

阐明: 在缓存服务器中, 因为大量的缓存数据生效, 导致用户拜访的命中率过低. 导致间接拜访数据库.
问题剖析:

1. fluashAll 命令可能导致缓存雪崩.
2. 设定超时工夫时, 应该采纳随机算法
3. 采纳多级缓存能够无效避免.

3.linux 零碎装置 redis

3.1 上传 Redis

1). 上传 redis

2). 解压 redis 服务
[root@localhost src]# tar -xvf redis-5.0.4.tar.gz

3). 挪动文件 / 批改文件名称

3.2 装置 Redis

阐明: 在 Redis 根目录中执行如下命令

1).make

2). make install

3.3 批改 redis 配置文件

批改 redis 根目录下的 redis.conf 文件
1). 去除 IP 绑定

2). 批改保护模式

3). 开启后盾启动

3.4 Redis 服务器命令

阐明: Redis 服务在运行时, 必须依赖于配置文件 redis.conf. 操作 redis 时最好在根目录中操作
1). 启动 redis
redis-server redis.conf

2). 进入 redis 客户端
redis-cli -p 6379
ctrl + c 退出客户端

3). 敞开 redis 服务器

办法二:

 redis-cli -p 6379 shutdown

阐明: 如果操作端口是默认端口(6379) 6379 能够不写;

4 redis 分片机制

4.1 redis 性能优化

阐明: 单台 redis 内存容量是无限的. 然而如果有海量的数据要求实现缓存存储, 则应该应用多个 Redis 节点.

4.2 Redis 分片机制定义

4.3 Redis 分片机制配置

4.3.1 配置布局

阐明: 筹备 3 台 redis 服务器 别离为 6379/6380/6381

4.3.2 筹备 3 个配置文件

批改各自端口号 改为 6380 6381

4.3.3 启动 redis 服务器

4.3.4 查看 redis 启动状态

5.Redis 哨兵机制

5.1 Redis 分片机制问题

阐明: 如果 redis 分片中有一个节点宕机, 则可能会影响整个服务的运行. redis 分片没有实现高可用.

5.2 Redis 主从构造搭建

5.2.1 复制配置文件

5.2.2 筹备 3 台 redis

5.2.3 主从搭建

命令 1: info replication

命令 2: slaveof IP PORT 主从挂载命令

查看主从构造状态


对于主从构造阐明:
主和从都晓得 以后的主从的状态, 并且只有主机能够写操作. 从机只能读操作.

5.2 Redis 哨兵机制工作原理

1). 当哨兵启动时, 首先会监控主机, 从主机中获取以后所有的节点的状态, 同时哨兵开启心跳检测机制.
2). 当主机产生宕机的景象时, 因为哨兵有 PING-PONG 机制 发现主机宕机, 则哨兵开始进行选举.
3). 当选举胜利之后, 新的主机入选之后, 其余的节点当新主机的从.

5.3 编辑哨兵配置文件

1）敞开保护模式

2). 开启后盾运行

3). 编辑监控配置

4). 批改选举工夫

5.4 启动哨兵服务

命令: redis-sentinel sentinel.conf

6. 集群机制

就是联合分片和哨兵机制, 且用不到哨兵服务, 主机宕机由残余的主机选取主机, 就不必放心哨兵宕机而影像整个服务运行, 个别一主两或三从, 起码三个主机

6.1 搭建集群:

打算三台主机三台从机, 端口号 7000~7005;

1. 在 redis 下创立一个 cluster 文件夹, 在 cluster 目录下创立 7000~7005 六个目录, 在其中一个目录下复制一个 redis.conf 文件(redis 集体目录下的, 没被净化过)
2. 批改配置文件, 详情见 redis 集群搭建步骤, 将批改好的配置文件复制给其余五个目录, 之后将这五个目录下的配置文件中的 7000 换成对应的数据(:%S/7000/7001/g)
3. 通过创立脚本命令来启动 / 敞开
4. 创立 redis 集群:redis-cli –cluster create –cluster-replicas 1 192.168.126.129:7000 192.168.126.129:7001 192.168.126.129:7002 192.168.126.129:7003 192.168.126.129:7004 192.168.126.129:7005

6.2 搭建胜利