一篇彻底弄懂redis的文章

文章目录

• 一、redis的基本介绍
• 1.1、redis简介：
• 1.2、redis的优点
• 1.3、redis的缺点
• 1.4、redis速度快的原因
• 1.5、redis的应用场景
• 二、redis支持的数据类型
• 2.1、字符串spring：
• 2.2、列表List：
• 2.3、无序集合Set：
• 2.4、哈希Hash：
• 2.5、有序集合Zset
• 三、redis做缓存使用
• 3.1、redis的持久化方案
• 3.1.1、RDB模式
• 3.1.2、AOF模式
• 3.1.3、如何选择使用哪种持久化方式？
• 3.2、缓存穿透
• 3.3、缓存雪崩
• 3.4、过期策略与内存淘汰机制
• 3.5、redis的主从复制

一、redis的基本介绍

搭建redis集群参考：在windows环境下搭建redis集群（搭建redis集群二）

1.1、redis简介：

速度快的优点：Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。

速度快的优点：因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value DB。

支持丰富数据类型的优点：Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存多种数据结构，此外单个value的最大限制是1GB，不像 memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能。

比方说用他的List来做FIFO双向链表，实现一个轻量级的高性 能消息队列服务，用他的Set可以做高性能的tag系统等等。

另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一 个功能加强版的memcached来用。 Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上

1.2、redis的优点

• 速度快

因为数据存在内存中，类似于 HashMap ，HashMap 的优势就是查找和操作的时间复杂度都是O (1)

• 支持丰富数据类型: String ，List，Set，Sorted Set，Hash 。
• 丰富的特性

订阅发布 Pub / Sub 功能、Key 过期策略、事务、支持多个 DB、计数

• 持久化存储

Redis 提供 RDB 和 AOF 两种数据的持久化存储方案，解决内存数据库最担心的万一 Redis 挂掉，数据会消失掉。

1.3、redis的缺点

• 1、由于 Redis 是内存数据库，所以，单台机器，存储的数据量，跟机器本身的内存大小。虽然 Redis 本身有 Key 过期策略，但是还是需要提前预估和节约内存。如果内存增长过快，需要定期删除数据。
• 2、redis是单线程的，单台服务器无法充分利用多核服务器的CPU

1.4、redis速度快的原因

• redis把所有数据都是存放在内存中的
• redis是用C语言实现的，一般来说C语言实现的程序"距离"操作系统最近，执行速度相对更快
• Redis使用了单线程架构，预防了多线程可能产生的竞争问题

1.5、redis的应用场景

• 缓存（数据查询、短连接、新闻内容、商品内容等等）。（最多使用）
• 分布式集群架构中的session分离。
• 聊天室的在线好友列表。
• 任务队列。（秒杀、抢购、12306等等）
• 应用排行榜。
• 网站访问统计。
• 数据过期处理（可以精确到毫秒）

二、redis支持的数据类型

Redis 是速度非常快的非关系型（NoSQL）内存键值数据库，可以存储键和五种不同类型的值之间的映射。键的类型只能为字符串，值支持五种数据类型：字符串、列表、集合、散列表、有序集合。

2.1、字符串spring：

String是Redis最基本的数据类型，结构为一个key对应一个value。
String类型是二进制安全的，意味着可以包含任何数据，比如jpg图片或者序列化的对象。
String类型的最大能存储512M。

2.2、列表List：

Redis列表是简单的字符串列表，按照插入顺序排序。支持添加一个元素到列表头部（左边）或者尾部（右边）的操作。

一个列表最多可以包含 232- 1 ，即超过40亿个元素。

2.3、无序集合Set：

Redis集合是String类型的无序集合。集合成员是唯一的，这就意味着集合中不能出现重复的数据。

Redis集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。

集合中最大的成员数为 232- 1 ，即每个集合最多可存储40多亿个成员。

集合的一大特点就是不能有重复元素，如果插入重复元素，Redis会忽略该操作
Redis集合还有两大特点，一是支持随机获取元素，二是支持集合间的取差集、交集与并集操作。

2.4、哈希Hash：

Redis的哈希是field和value之间的映射，即键值对的集合，所以特别适合用于存储对象。

Redis 中每个 hash 最多可以存储 232 - 1 键值对（40多亿）。

2.5、有序集合Zset

Redis 有序集合和集合一样也是String类型元素的集合，且不允许重复的成员。

不同的是每个元素都会关联一个double类型的分数。Redis正是通过分数来为集合中的成员进行从小到大的排序。有序集合的成员是唯一的，但分数(score)却可以重复。

集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。

集合中最大的成员数为 232- 1 ，即每个集合最多可存储40多亿个成员。
需要注意的是，Redis有序集合是默认升序的，score越低排名越靠前，即score越低的元素下标越小。

三、redis做缓存使用

3.1、redis的持久化方案

持久化是指将数据存放在硬盘上，而Redis是一个内存数据库，数据只是存放在内存里。但毕竟内存空间有限，为了保证数据的持久性，Redis提供了两种持久化方案:RDB方式（默认）和AOF方式。

• RDB：能够在指定的时间间隔能对你的数据进行快照存储。（redis默认）
• AOF：记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾。

3.1.1、RDB模式

配置：
在redis.conf中修改持久化快照的条件，如下：

如果900秒(15分钟)内 发生过修改1次修改则 持久化一次数据到磁盘
如果300秒(5分钟)内 发生过10次修改则 持久化一次数据到磁盘
如果60秒(1分钟)内 发生过修10000次改则 持久化一次数据到磁盘

在redis.conf中可以指定持久化文件存储的目录

修改后需要重启才能切换存储方式

快照恢复过程：Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存，一般情况下1GB的快照文件载入到内存的时间约为20~30秒钟

实现原理：
Redis使用fork函数复制一份当前进程（父进程）的副本（子进程）；
父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入到硬盘中的临时文件；
当子进程写入完所有数据后会用该临时文件替换旧的RDB文件。

RDB优点：

• RDB文件非常适合备份。例如，您可以在最近的24小时内每小时存档一次RDB文件，并在30天内每天保存一个RDB快照。允许您在发生灾难时轻松恢复数据集的不同版本。
• RDB是一个紧凑的单一文件，很方便传送到另一个远端数据中心，非常适用于灾难恢复。
• RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能。
• 与AOF相比，在恢复大的数据集的时候，RDB方式会更快一些。

RDB缺点：

• Redis要完整的保存整个数据集是一个比较繁重的工作，通常会每隔5分钟或者更久做一次完整的保存，万一在Redis意外宕机，你可能会丢失几分钟的数据。
• RDB 需要经常fork子进程来保存数据集到硬盘上，当数据集比较大的时候，fork的过程是非常耗时的，可能会导致Redis在一些毫秒级内的请求不能响应客户端。

注意：由于Redis使用fork来复制一份当前进程，那么子进程就会占有和主进程一样的内存资源，比如说主进程8G内存，那么在备份的时候必须保证有16G的内存，要不然会启用虚拟内存，性能非常差。

3.1.2、AOF模式

Redis默认是不使用该方式持久化的。Aof方式的持久化，是操作一次redis数据库，则将操作的记录存储到aof持久化文件中。

• 默认情况下Redis没有开启AOF（append only file）方式的持久化
• 开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件，这一过程显然会降低Redis的性能，但大部分情况下这个影响是能够接受的，另外使用较快的硬盘可以提高AOF的性能。
• 可以通过修改redis.conf配置文件中的appendonly参数开启：appendonly yes
• 可以通过修改dir参数设置文件名，默认的文件名是appendonly.aof，可以通过appendfilename参数修改：appendfilename：appendonly.aof

配置：
第一步：开启aof方式的持久化方案
将redis.conf中的appendonly改为yes，即开启aof方式的持久化方案。

Aof文件存储的目录和rdb方式的一样。

Aof文件存储的名称

修改后需要重启服务

实现原理：

• Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写；
• 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合；
• 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作；
• AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行解析也很轻松。

Redis每次更改数据的时候， AOF 机制都会将命令记录到AOF 文件，但是实际上由于操作系统的缓存机制，数据并没有实时写入到硬盘，而是进入硬盘缓存，再通过硬盘缓存机制去刷新到保存到文件。

AOF优点：

• fsync策略：无fsync，每秒fsync（默认且推荐），每次查询fsync。使用fsync的默认策略，每秒的写入性能仍然很好。您只可能丢失一秒的写入操作。
• AOF文件是一个只进行追加的日志文件，即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令，你也也可使用redis-check-aof工具修复这些问题。
• 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写：重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
• AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易读懂， 对文件进行分析（parse）也很轻松。

AOF缺点：

• 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
• 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。

3.1.3、如何选择使用哪种持久化方式？

• 一般来说,如果对数据的安全性要求非常高的话，应该同时使用两种持久化功能；

• 如果可以承受数分钟以内的数据丢失，那么可以只使用RDB持久化；

• 有很多用户都只使用 AOF 持久化， 但并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快 ;

• 两种持久化策略可以同时使用，也可以使用其中一种。如果同时使用的话， 那么Redis重启时，会优先使用AOF文件来还原数据

3.2、缓存穿透

3.3、缓存雪崩

3.4、过期策略与内存淘汰机制

3.5、redis的主从复制