Redis学习笔记

视频教程 尚硅谷-Spring5框架最新版教程（idea版）

入门概述

概念

Redis:REmote DIctionary Server(远程字典服务器)
是一个高性能的(key/value)分布式内存数据库，基于内存运行并支持持久化的NoSQL数据库，完全开源免费，用c语言编写的，遵守BSD协议，是当前最热门的NoSql数据库之一，也被人们称为数据结构服务器。

Redis 与其他 key-value 缓存产品有以下三个特点

Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用
Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储
Redis支持数据的备份，即master-slave模式的数据备份

用途

内存存储和持久化：redis支持异步将内存中的数据写到硬盘上，同时不影响继续服务
取最新N个数据的操作，如：可以将最新的10条评论的ID放在Redis的List集合里面
模拟类似于HttpSession这种需要设定过期时间的功能
发布、订阅消息系统
定时器、计数器

下载

http://redis.io

http://www.redis.cn

Redis命令http://redisdoc.com

常见配置redis.conf介绍

redis.conf配置项说明：
1.Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程daemonize no
2.当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定pidfile /var/run/redis.pid
3.指定Redis监听端口，默认端口为6379port 6379
4.绑定的主机地址bind 127.0.0.1
5.当客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能timeout 300
6.指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为verbose。loglevel verbose
7.日志记录方式，默认为标准输出，如果配置Redis为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给/dev/null。
logfile stdout
8.设置数据库的数量，默认数据库为0，可以使用SELECT 命令在连接上指定数据库id。databases 16
9.指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合save
Redis默认配置文件中提供了三个条件：save 900 1、save 300 10、save 60 10000
分别表示900秒(15分钟)内有1个更改、300秒(5分钟)内有10个更改、60秒内有10000个更改。
10.指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大
rdbcompression yes
11.指定本地数据库文件名，默认值为dump.rdb。dbfilename dump.rdb
12.指定本地数据库存放目录dir ./
13.设置当本机为slav服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master进行数据同步
slaveof
14.当master服务设置了密码保护时，slav服务连接master的密码masterauth
15.设置Redis连接密码，若配置了连接密码，客户端在连接Redis时需要通过AUTH 命令提供密码，默认关闭。
requirepass foobared
16.设置同一时间最大客户端连接数，默认无限制，Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数，如果设置maxclients 0，表示不作限制。当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回max number of clients reached错误信息
maxclients 128
17.指定Redis最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把Key存放内存，Value会存放在swap区maxmemory
18.指定是否在每次更新操作后进行日志记录，Redis在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为redis本身同步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为no
appendonly no
19.指定更新日志文件名，默认为appendonly.aof。appendfilename appendonly.aof
20.指定更新日志条件，共有3个可选值：
no：表示等操作系统进行数据缓存同步到磁盘（快）
always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全）
everysec：表示每秒同步一次（折中，默认值）
appendfsync everysed
21.指定是否启用虚拟内存机制、默认值为no，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中vm-enabled no
22.虚拟内存文件路径，默认值为/tmp/redis.swap，才可多个Redis实例共享。vm-swap-file /tmp/redis.swap
23.将所有大于vm-max-memory的数据存入虚拟内存，无论vm-max-memory设置多小，所有索引数据都是内存存储的（Redis的索引数据就是keys），即 当vm-max-memory设置为0时，其实是所有value都存在于磁盘。默认值为0。vm-max-memory 0
24.Redis swap文件分成了很多的page，一个对象可以保存在多个page上面，但一个page上不能被多个对象共享，vm-page-size是要根据存储的数据大小来设定的，若存储很多小对象，page大小最好设置为32或者64bytes；若存储很大的对象，则可以使用更大的page，若不确定，就使用默认值vm-page-size 32
25，设置swap文件中的page数量，由于页表（一种表示页面空闲或使用的bitmap）是在放在内存中的，在磁盘上每8个pages将消耗1byte的内存。vm-pages 134217728
26.设置访问swap文件的线程数，最好不要超过机器的核数，如果设置为0，则所有对swap文件的操作都是串行的，可能会造成比较长时间的延迟。默认值为4。vm-max-threads 4
27.设置在向客户端应答时，是否把较小的包合并为一个包发送，默认为开启。glueoutputbuf yes
28.指定在超过一定的数量或者最大的元素超过某一临界值时，采用一种特殊的哈希算法
hash-max-zipmap-entries 64
hash-max-zipmap-value 512
29.指定是否激活重置哈希，默认为开启。activerehashing yes
30.指定包含其它的配置文件，可以在同一主机上多个Redis实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件
include /path/to/local.conf

Redis持久化

RDB（Redis DataBase）

是什么

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

Redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。
若需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
RDB的缺点是最后一次持久化后的数据可能丢失。

RDB保存的是dump.rdb文件

Fork

Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

配置位置

save 秒钟 写操作次数
RDB是整个内存的压缩过的Snapshot，RDB的数据结构，可以配置复合的快照触发条件，
默认是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次。

如何触发RDB快照

命令save或者是bgsave

Save：save时只管保存，其它不管，全部阻塞。
BGSAVE：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间。

执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义

如何恢复

将备份文件(dump.rdb)移动到redis安装目录并启动服务即可

CONFIG GET dir获取目录

优势

适合大规模的数据恢复
对数据完整性和一致性要求不高

劣势

在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改
Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

如何停止

动态所有停止RDB保存规则的方法：redis-cli config set save ""

RDB总结

• RDB是一个非常紧凑的文件。
• RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，接下来的工作全部由子进程来做，父进程不需要再做其他lO操作，所以RDB持久化方式可以最大化redis的性能。
• 与AOF相比，在恢复大的数据集的时候，RDB方式会更快一些。

• 数据丢失风险大。
• RDB需要经常fork子进程来保存数据集到硬盘上，当数据集比较大时，fork的过程是非常耗时的，可能会导致Redis在一些毫秒级不能响应客户端请求。
  

AOF（Append Only File）

是什么

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

AOF保存的是appendonly.aof文件

配置位置

Append Only Mode追加

• appendonly

• appendfilename

• Appendfsync

  Always：同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好。每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全）
  Everysec：出厂默认推荐，异步操作，每秒记录，若一秒内宕机，有数据丢失。每秒同步一次（折中，默认值）
  No

• No-appendfsync-on-rewrite：重写时是否可以运用Appendfsync，用默认no即可，保证数据安全性。

• Auto-aof-rewrite-min-size：设置重写的基准值

• Auto-aof-rewrite-percentage：设置重写的基准值

AOF启动/修复/恢复

正常恢复：

启动：修改配置文件默认的appendonly no，改为yes
将有数据的AOF文件复制一份保存到对应目录（config get dir）
恢复：重启redis然后重新加载

异常恢复：

启动：修改配置文件默认的appendonly no，改为yes
备份被写坏的AOF文件
修复：Redis-check-aof --fix进行修复
恢复：重启redis然后重新加载

Rewrite

是什么

AOF采用文件追加方式，文件会越来越大。为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。可以使用命令bgrewriteaof

重写原理

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

触发机制

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

优势

每秒同步：appendfsync always同步持久化。每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好。
每修改同步：appendfsync everysec异步操作，每秒记录。如果一秒内宕机，有数据丢失。
不同步：appendfsync no从不同步。

劣势

相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
Aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同

AOF总结

• AOF文件是一个只进行追加的日志文件
• Redis 可以在AOF文件体积变得过大时，自动地在后台对AOF进行重写
• AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以Redis协议的格式保存，因此AOF 文件的内容很容易被人读懂，对文件进行分析也很轻松
• 对于相同的数据集来说，AOF文件的体积通常要大于RDB文件的体积
• 根据所使用的fsync策略，AOF的速度可能会慢于RDB
  

总结

RDB持久化方式 能在指定的时间间隔对数据进行快照存储

AOF持久化方式 记录每次对服务器写的操作，当服务器重启时会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾。Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。

只做缓存：若只希望数据在服务器运行的时候存在，则可以不使用任何持久化方式。

同时开启两种持久化方式：
在这种情况下，redis重启时会优先载入AOF文件来恢复原始数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集更完整。
RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。但仍建议不要只使用AOF，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。

性能建议

因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。

如果Enable AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件即可。
代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
只要硬盘许可，应该尽量减少AOF rewrite的频率。
AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。

如果不Enable AOF，仅靠Master-Slave Replication实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。
代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启助脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。新浪微博就选用了这种架构

Redis事务

是什么

可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序地串行化执行执行而不会被其它命令插入，不许加塞。

Redis对事务的支持是部分支持。

能干嘛

一个队列中，一次性、顺序性、排他性的执行一系列命令

怎么玩

Redis事务命令

命令	描述
DISCARD	取消事务，放弃执行事务块内的所有命令
EXEC	执行所有事务块内的命令
MULTI	标记一个事务块的开始
UNWATCH	取消WATCH命令对所有key的监视
WATCH key [key …]	监视一个(或多个) key，如果在事务执行之前这个(或这些) key被其他命令所改动，那么事务将被打断。

Case1:正常执行

Case2:放弃事务

Case3:全体连坐

Case4:冤头债主

Case5: watch监控

悲观锁/乐观锁/CAS(Check And set)

悲观锁(Pessimistic Lock)，顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

乐观锁(Optimistic Lock)，顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。
乐观锁策略：提交版本必须大于记录当前版本才能执行更新

初始化可用余额balance和欠额debt

一旦执行了exec之前加的监控锁都会被取消掉了

小结

Watch指令，类似乐观锁，事务提交时，如果Key的值已被别的客户端改变，比如某个list已被别的客户端push/pop过了，整个事务队列都不会被执行。
通过WATCH命令在事务执行之前监控了多个Keys，倘若在WATCH之后有任何Key的值发生了变化，EXEC命令执行的事务都将被放弃，同时返回Nullmulti-bulk应答以通知调用者事务执行失败。

3阶段

开启：以MULTI开始一个事务
入队：将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面
执行：由EXEC命令触发事务

3特性

单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断、

没有隔离级别的概念：队列中的命令在提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在“事务内的查询要看到事务里的更新，在事务外查询不能看到”这个问题

不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚。

Redis的复制（Master/Slave）

是什么

也就是我们所说的主从复制，主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主。

能干嘛

读写分离 容灾恢复 等

怎么玩

配从(库)不配主(库)

从库配置：slaveof 主库IP 主库端口。

每次与master断开之后都要重新连接，除非配置进redis.conf文件

Info replication查看信息

修改配置文件细节操作

拷贝多个redis.conf文件

开启daemonize yes

**Pid文件名字：**pidfile /var/run/redis6379.pid

指定端口

**Log文件名字：**log文件名字 logfile “6379.log”

**Dump.rdb名字：**dbfilename dump6379.rdb

常用3招

一主二仆

1. Init
   

2. 一个Master两个Slave

   最初是相互独立的
   
   设置成一个Master两个Slave，79是主，80和81是从

3. 日志查看

4. 主从问题演示

这说明只要转成slave，那么就把master从头到尾全部复制一遍、

只有主机能写，从只能读

主机掉了，两个从机都还是slave，状态是down、

此时主机再回来，则一切照旧，从机无需重新配置
从机挂了 重启该从机，若没有写进配置文件，则需要命令重新连接主机，否则它自己作为master，而不是作为原来主机的从机、

薪火相传

1、上一个Slave可以是下一个slave的Master，Slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master，可以有效减轻master的写压力。
2、中途变更转向：会清除之前的数据，重新建立拷贝最新的。
3、Slaveof 新主库IP 新主库端口

对81那个服务执行slaveof 127.0.0.1 6380之后

反客为主

SLAVEOF no one 使当前数据库停止与其他数据库的同步，转成主数据库

slaveof 127.0.0.1 6379恢复成一主二从
此时79再重启回来 相当于光杆司令

复制原理

• Slave启动成功连接到master后会发送一个sync命令
• Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，以完成一次完全同步。
• 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
• 增量复制：Master继续将新的所有收集到的修改命令依次传给slave，完成同步。但是只要是重新连接master，一次完全同步（全量复制）将被自动执行

哨兵模式

反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库

一组sentinel能同时监控多个Master

使用步骤

调整结构，6379带着80、81

自定义的/myredis目录下新建sentinel.conf文件，名字绝不能错

配置哨兵，填写内容：sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1 其中最后一个数字1，表示主机挂掉后salve投票看让谁接替成为主机，得票数多少后成为主机

启动哨兵：Redis-sentinel /myredis/sentinel.conf 上述目录依照各自的实际情况配置，可能目录不同

正常主从演示

原有的master挂了
投票新选
重新主从继续开工，info replication查看

问题：如果之前的master重启回来，会不会双master冲突？

复制的缺点

复制延时：由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。