Redis基础

一、Redis 是什么
Redis 是一个开源的、key-value 结构的、非关系型数据库。它支持存储的 value 类型相对更多，包括 String(字符串)、List(列表)、Set(集合)、Sorted Set(有序集合) 和 Hash(哈希)，而且这些操作都是原子性的。在此基础上，Redis 支持各种不同方式的排序。为了保证效率，数据都是缓存在内存中。Redis 可以周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。

使用 Redis 有哪些好处
(1)速度快，因为数据存在内存中。
(2)支持丰富数据类型，支持 string，list，set，sorted set，hash等。
(3)支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行。
(4)丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除。

二、单线程？
Redis 的数据存储在内存中，如果数据全都在内存里，单线程的去操作就是效率最高的。因为多线程的本质就是 CPU 模拟出来多个线程的情况，这种模拟出来的情况就有一个代价，就是上下文的切换，对于一个内存的系统来说，它没有上下文的切换就是效率最高的。因为上下文切换所花费的时间远大于直接从内存中读取数据所花费的时间。

Redis 用单个 CPU 绑定一块内存的数据，然后针对这块内存的数据进行多次读写的时候，都是在一个CPU上完成的，所以它是单线程处理这个事。在内存的情况下，这个方案就是最佳方案。

这里我们一直在强调的单线程，只是在处理我们的网络请求的时候只有一个线程来处理，一个正式的 Redis Server 运行的时候肯定是不止一个线程的，例如 Redis 进行持久化的时候会以子进程或者子线程的方式执行。
 

三丶redis安装

下载地址:Releases · tporadowski/redis · GitHub

 解压后打开redis-server.exe

 打开redis-cli.exe输入ping,返回PONG则表示启动

 四丶Redis基本数据类型

1、String
String 数据结构是简单的 key-value 类型，value 其实不仅可以是 String，也可以是数字。需要注意是一个键值最大存储 512MB。

2、Hash（哈希）
Hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象。 比如我们可以 Hash 数据结构来存储用户信息，商品信息等等。

3、List（列表）
是 Redis 的简单的字符串列表。list 的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销。

 

4、Set
Set 对外提供的功能与 list 类似是一个列表的功能，特殊之处在于 set 不允许重复元素，可以自动排重的，并且 set 提供了判断某个成员是否在一个 set 集合内的重要接口，这个也是 list 所不能提供的。

在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。Redis 可以非常方便的实现如共同关注、共同喜好、二度好友等功能。
 

5、Sorted Set
与 set 相比，Sorted set 增加了一个权重参数 score，使得集合中的元素能够按 score 进行有序排列。

 五丶Redis持久化

Redis的持久化有两种方式：RDB和AOF，redis默认采用的是RDB的方式。

RDB

什么是RDB

在指定时间间隔内，将内存中的数据集快照写入磁盘，也就是Snapshot快照，它恢复时是将快照文件直接读到内存中，来达到恢复数据的。

如何持久化

Redis会单独创建(fork)一个子进程来进行持久化，会先将数据写进一个临时文件中，等到持久化过程结束了，再用这个临时文件替换上次持久化好的文件。在这个过程中，只有子进程来负责IO操作，主进程仍然处理客户端的请求，这就确保了极高的性能。

Snapshot

在默认情况下， Redis 将数据库快照保存在名字为 dump.rdb 的二进制文件中。通过触发快照的形式，来做到将指定时间间隔内的数据持久化到dump.rdb。例如，可以2分钟内持久化一次，将对数据库的写操作，备份到磁盘上的dump.rdb。如何触发持久化呢？可以通过查看或者设置redis.conf配置文件来指定触发规则。

以下是redis配置文件的触发快照的默认配置

 900S内有一个key发生变化则进行数据库保存-持久化

 300S内有10个key发生变化则进行数据库保存-持久化

 60S内有10000个key发生变化则进行数据库保存-持久化

dump.rdb生成位置：

配置文件的生成位置可以通过配置文件指定，然后需要将dump.rdb文件放在redis的启动目录；
查询redis的启动目录命令：congfig get dir

 ./表示当前目录;即配置文件所在目录,默认跟conf文件同目录

RDB优点与缺点

优点

如果要进行大规模数据的恢复，RDB方式要比AOF方式恢复速度要快。
RDB可以最大化Redis性能，父进程做的就是fork子进程，然后继续接受客户端请求，让子进程负责持久化操作，父进程无需进行IO操作。

RDB是一个非常紧凑(compact)的文件,它保存了某个时间点的数据集，非常适合用作备份，同时也非常适合用作灾难性恢复，它只有一个文件，内容紧凑，通过备份原文件到本机外的其他主机上，一旦本机发生宕机，就能将备份文件复制到redis安装目录下，通过启用服务就能完成数据的恢复。

缺点

RDB这种持久化方式不太适应对数据完整性要求严格的情况，因为，尽管我们可以用过修改快照实现持久化的频率，但是要持久化的数据是一段时间内的整个数据集的状态，如果在还没有触发快照时，本机就宕机了，那么对数据库所做的写操作就随之而消失了并没有持久化本地dump.rdb文件中。

每次进行RDB时，父进程都会fork一个子进程，由子进程来进行实际的持久化操作，如果数据集庞大，那么fork出子进程的这个过程将是非常耗时的，就会出现服务器暂停客户端请求，将内存中的数据复制一份给子进程，让子进程进行持久化操作。

AOF

什么是AOF

以日志的形式记录Redis每一个写操作,将Redis执行过的所有写指令记录下来（读操作不记录），只许追加文件不可以改写文件，redis启动之后会读取appendonly.aof文件来实现重新恢复数据，完成恢复数据的工作。默认不开启，需要将redis.conf中的appendonly no改为yes启动Redis。

持久化 

Redis的AOF是如何做到持久化的呢？从配置文件中，我们可以发现

appendfsync always:每修改同步，每一次发生数据变更都会持久化到磁盘上，性能较差，但数据完整性较好。

appendfsync everysec: 每秒同步，每秒内记录操作，异步操作，如果一秒内宕机，有数据丢失。

appendfsync no:不同步。
数据恢复

重启Redis时，如果dump.rdb与appendfsync.aof同时都存在时，Redis会自动读取appendfsync.aof文件，通过该文件中对数据库的日志操作，来实现数据的恢复。当然如果该文件被破坏，我们可以通过redis-check-aof工具来修复，如redis-check-aof --fix能修复破损的appendfsync.aof文件，当然如果dump.rdb文件有破损，我们也可以用redis-check-rdb工具来修复，如果appendfsync.aof文件破损了，是启动不客户端的，也就是无法完成数据的恢复。
重写

当然如果AOF 文件一直被追加，这就可能导致AOF文件过于庞大。因此，为了避免这种状况，Redis新增了重写机制，当AOF文件的大小超过所指定的阈值时，Redis会自动启用AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewiteaof。

重写原理：AOF文件持续增长过大时，会fork出一条新进程来将文件重写（也是临时文件最后再rename）,遍历新进程的内存中的数据，每条记录都会有一条set语句，重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，有点类似于快照。

触发机制：Redis会记录上一次重写时的AOF大小，默认配置是当AOF文件大小是上一次的一倍并且大于64m时，会触发从写机制。

优点

AOF有着多种持久化策略：

appendfsync always:每修改同步，每一次发生数据变更都会持久化到磁盘上，性能较差，但数据完整性较好。

appendfsync everysec: 每秒同步，每秒内记录操作，异步操作，如果一秒内宕机，有数据丢失。

appendfsync no:不同步。

AOF文件是一个只进行追加操作的日志文件，对文件写入不需要进行seek，即使在追加的过程中，写入了不完整的命令（例如：磁盘已满），可以使用redis-check-aof工具可以修复这种问题

Redis可以在AOF文件变得过大时，会自动地在后台对AOF进行重写：重写后的新的AOF文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的，因为Redis在创建AOF文件的过程中，会继续将命令追加到现有的AOF文件中，即使在重写的过程中发生宕机，现有的AOF文件也不会丢失。一旦新AOF文件创建完毕，Redis就会从旧的AOF文件切换到新的AOF文件，并对新的AOF文件进行追加操作。

AOF文件有序地保存了对数据库执行的所有写入操作。这些写入操作一Redis协议的格式保存，易于对文件进行分析；例如，如果不小心执行了FLUSHALL命令，但只要AOF文件未被重写，通过停止服务器，移除AOF文件末尾的FLUSHALL命令，重启服务器就能达到FLUSHALL执行之前的状态。

缺点

对于相同的数据集来说，AOF文件要比RDB文件大。
根据所使用的持久化策略来说，AOF的速度要慢与RDB。一般情况下，每秒同步策略效果较好。不使用同步策略的情况下，AOF与RDB速度一样快。

数据淘汰策略

最为大家所熟悉的，就是我们在进行redis存值的时候，可以针对每个key-value设置过期时间，时间到，数据自动删除。但是，当我们每个key-value都设置不过期的话，redis是不是就会被撑爆了呢？答案是不太会的，为什么这样说？是因为当我们的redis内存达到设置的maxmemory的时候，就会使用数据淘汰策略来保证redis的高可用性。

redis的六种淘汰策略：

volatile-lru： 从已设置过期的数据中中随机挑选最近最少使用的多个key进行数据淘汰。
volatile-ttl： 从已设置过期的数据中挑选即将要过期的数据进行淘汰。
volatile-random：从已设置过期的数据中任意淘汰数据。
allkeys-lru： 从数据集中挑选最近最少使用的数据淘汰。
allkeys-random：从数据集中任意选择数据淘汰。
noeviction: 不进行删除，达到最大内存时，直接返回错误信息。
以上六点的配置是在redis的配置是文件中maxmemory-policy来决定具体使用哪种淘汰策略。我们可以根据业务场景的不同使用不同的淘汰策略。