目录

1. 概述
2. 安装
   1. Linux 下安装 Redis
   2. Windows 下安装 Redis
3. 杂项知识
4. Key 关键字
5. Redis 常用数据类型
   1. String
   2. Hash
   3. List
   4. Set
   5. Zset
6. Redis 配置文件
   1. 语法
   2. 参数说明
7. 持久化 Redis
   1. RDB
      1. 触发 RDB 快照
      2. 快照恢复
      3. 停止 RDB
      4. 总结
   2. AOF（Append Only File）
      1. AOF 操作
      2. rewrite
      3. 总结
   3. 持久化总结
8. Redis 事务
   1. 常用命令
   2. 事务中的错误
      1. 全体连坐
      2. 冤头债主
      3. 为什么 redis 不支持回滚（roll back）
   3. 放弃事务
   4. watch 监控
   5. 事务执行阶段
9. 消息队列
   1. 观察者模式（发布订阅模式）
      1. 常用命令
10. redis 高可用与集群
11. 主从复制
    1. 配置
    2. 常见主从配置三招
       1. 一主两从
       2. 薪火相传
       3. 反客为主
    3. 复制原理
12. 哨兵模式（sentinel）
    1. 使用步骤
13. 附录

¶概述

Redis：REmote DIctionary Server（远程字典服务器）是一个高性能的( key / value )分布式内存数据库，基于内存运行并支持持久化的 NoSQL 数据库，是当前最热门的 NoSql 数据库之一

🤔 Redis 能干嘛？

🤔学习 Redis 的步骤

¶安装

根据操作系统不同， Redis 的安装分为两种：Linux 与 Windows

¶Linux 下安装 Redis

1
2
3
4

wget http://download.redis.io/releases/redis-6.0.8.tar.gz
tar xzf redis-6.0.8.tar.gz
cd redis-6.0.8
make

1
2
3

cd src
redis-server #使用默认配置
redis-server /SOMEWHERE/CONFIG/FILE #使用指定文件作为启动配置文件

使用redis-cli命令可以访问对应地址上的 redis 服务

¶Windows 下安装 Redis

至此redis-server启动成功，需要使用redis-cli工具去连接服务端，输入redis-cli.exe -h 127.0.0.1 -p 6379命令，看到命令提示符改变，说明 redis 安装成功，并且已经访问了 redis 提供的服务

¶杂项知识

• 在redis安装目录下redis-benchmark.exe将会测试 redis 在机器运行的效能

• redis 是单进程

  • 单进程模型来处理客户端的请求。对读写等事件的响应式通过对epoll函数的包装来做到的，Redis 的实际处理速度完全依靠主进程的执行效率
  • Epoll是 Linux 内核为处理大批量文件描述符而做了改进的 epoll，是 Linux 下多路复用 IO 接口select/poll的增强版本，它能显著提供程序在大量并发连接中只有少量活跃的情况下的系统 CPU 利用率

• 和 MySQL 启动拥有默认数据库相同，Redis 启动默认有 16 个数据库，类似数组下标从零开始，初始默认使用零号库，可以在配置文件中配置

• Redis 索引都是从零开始

• 默认端口是：6379

🎶Redis 统一密码管理，16 个库都是同样的密码，要么都 OK 要么一个也连接不上

¶Key 关键字

与 HashMap 中 Key 含义相同

¶Redis 常用数据类型

Redis 常用数据结构如下图，具体每个类型的特点在下文进行阐述

¶String

¶Hash

¶List

¶Set

¶Zset

📚更多详细的用法可以访问Redis 命令参考

¶Redis 配置文件

Redis 的配置文件位于 Redis 安装目录下,文件名为 redis.conf,可以通过 CONFIG 命令查看或设置配置项

¶语法

1
2
3
4
5

redis 127.0.0.1:6379> CONFIG GET CONFIG_SETTING_NAME
redis 127.0.0.1:6379> CONFIG GET loglevel

1)"loglevel"
2)"notice"

¶参数说明

redis.conf配置项说明如下

Redis 的默认配置文件中提供了三个 save 配置条件

1
2
3

save 900 1    ## 900秒内发生一次更改,则保存
save 300 10   ## 300秒内发生十次更改,则保存
save 60 1000  ## 60秒内发生一千次更改,则保存

¶持久化 Redis

Redis 是内存数据库，当物理机关闭或者宕机之后，内存中的数据必然会消失，所以就需要对 Redis 中的数据进行持久化存储，RDB 就是 Redis 持久化存储的一种方式

¶RDB

❓RDB 是什么?

❓RDB 是如何进行的？

✨RDB 的配置

¶触发 RDB 快照

在配置文件中开启 RDB 之后，并不存在备份文件，则自动触发快照

命令方式触发

¶快照恢复

将备份文件（dump.rdb）移动到 redis 安装目录并重新启动服务即可

¶停止 RDB

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

¶总结

RDB 的作用如下图所示：

👍RDB 优点如下：

😣RDB 缺点如下：

¶AOF（Append Only File）

❓AOF 是如何进行的？

✨AOF 配置

¶AOF 操作

¶rewrite

❓ rewrite 是什么？

✨ rewrite 重写原理

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

¶总结

👍 AOF 优点

😣 AOF 缺点

¶持久化总结

RDB 在恢复大的数据集的时候比 AOF 快，但是 RDB 数据丢失风险大。根据 aof 所使用的 fsync 策略，aof 的速度可能会慢于 rdb，对于相同的数据集来说，aof 文件的体机通常要大于 RDB 文件的体积

¶Redis 事务

MULTI,EXEC,DISCARD和WATCH是 Redis 事务相关的命令，事务可以一次执行多个命令，并且带有以下两个重要的保证：

✨ redis 中的事务和 RDB 中的事务不同，redis 中的事务将所有命令放到一个队列中，一次性、顺序性、排他性的执行一系列命令

¶常用命令

1
2
3
4
5
6
7
8
9

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set foo 1
QUEUED
127.0.0.1:6379> INCR foo
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) (integer) 2

EXEC 命令的回复是一个数组， 数组中的每个元素都是执行事务中的命令所产生的回复。 其中， 回复元素的先后顺序和命令发送的先后顺序一致。当客户端处于事务状态时， 所有传入的命令都会返回一个内容为 QUEUED 的状态回复（status reply）， 这些被入队的命令将在 EXEC 命令被调用时执行。

¶事务中的错误

事务中的错误存在两种形式：全体连坐和冤头债主两种，事务在执行 EXEC 之前，入队的命令可能会出错（全体连坐）；命令可能在 EXEC 调用之后失败（冤头债主）

¶全体连坐

命令可能会产生语法错误（参数数量错误，参数名错误等等）或者其他更严重的错误，比如内存不足（如果服务器使用 maxmemory 设置了最大内存限制的话），类似 Java 编译异常，出现错误全部不能执行

1
2
3
4
5
6
7
8
9
10
11
12
13
14

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set name z3
QUEUED
127.0.0.1:6379> get name
QUEUED
127.0.0.1:6379> set email
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379> exce
(error) ERR unknown command `exce`, with args beginning with:
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379>

对于发生在 EXEC 执行之前的错误，客户端以前的做法是检查命令入队所得的返回值：如果命令入队时返回 QUEUED ，那么入队成功；否则，就是入队失败。如果有命令在入队时失败，那么大部分客户端都会停止并取消这个事务。不过，从 Redis 2.6.5 开始，服务器会对命令入队失败的情况进行记录，并在客户端调用 EXEC 命令时，拒绝执行并自动放弃这个事务。

¶冤头债主

在 EXEC 命令执行之后所产生的错误，并没有对它们进行特别处理：即使事务中有某个/某些命令在执行时产生了错误，事务中的其他命令仍然会继续执行，类似于 Java 运行异常

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set age 11
QUEUED
127.0.0.1:6379> incr age
QUEUED
127.0.0.1:6379> set email abc@163.com
QUEUED
127.0.0.1:6379> incr email
QUEUED
127.0.0.1:6379> get age
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) (integer) 12
3) OK
4) (error) ERR value is not an integer or out of range
5) "12"

¶为什么 redis 不支持回滚（roll back）

❓ 在冤头债主模式中，为什么当事务失败了，不进行回滚而是继续执行余下的命令，这种做法可能会感觉十分奇怪？

👍这么做的优点是

举个例子， 如果你本来想通过 INCR 命令将键的值加上 1 ， 却不小心加上了 2 ，又或者对错误类型的键执行了 INCR ， 回滚是没有办法处理这些情况的。

¶放弃事务

当执行 [DISCARD 命令时， 事务会被放弃， 事务队列会被清空， 并且客户端会从事务状态中退出：

1
2
3
4
5
6
7
8
9
10

127.0.0.1:6379> SET foo 1
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> INCR foo
QUEUED
127.0.0.1:6379> DISCARD
OK
127.0.0.1:6379> get foo
"1"

¶watch 监控

WATCH 使得 EXEC 命令需要有条件地执行：事务只能在所有被监视键都没有被修改的前提下执行，如果这个前提不能满足的话，事务就不会被执行

WATCH 命令可以为 Redis 事务提供 CAS 行为，

1
2
3

val = GET mykey
val = val + 1
SET mykey $val

上面的这个实现在只有一个客户端的时候可以执行得很好。 但是， 当多个客户端同时对同一个键进行这样的操作时， 就会产生竞争条件。举个例子， 如果客户端 A 和 B 都读取了键原来的值， 比如 10 ， 那么两个客户端都会将键的值设为 11 ， 但正确的结果应该是 12 才对。

存在 WATCH，就可以轻松地解决这类问题

1
2
3
4
5
6

WATCH mykey
val = GET mykey
val = val + 1
MULTI
SET mykey $val
EXEC

使用上面的代码， 如果在 [WATCH 执行之后， [EXEC] 执行之前， 有其他客户端修改了 mykey 的值， 那么当前客户端的事务就会失败。 程序需要做的， 就是不断重试这个操作， 直到没有发生碰撞为止。

这种形式的锁被称作乐观锁， 它是一种非常强大的锁机制。 并且因为大多数情况下， 不同的客户端会访问不同的键， 碰撞的情况一般都很少， 所以通常并不需要进行重试。

当 [EXEC] 被调用时， 不管事务是否成功执行， 对所有键的监视都会被取消

另外， 当客户端断开连接时， 该客户端对键的监视也会被取消。

使用无参数的 [UNWATCH 命令可以手动取消对所有键的监视。 对于一些需要改动多个键的事务， 有时候程序需要同时对多个键进行加锁， 然后检查这些键的当前值是否符合程序的要求。 当值达不到要求时， 就可以使用 [UNWATCH 命令来取消目前对键的监视， 中途放弃这个事务， 并等待事务的下次尝试。

¶事务执行阶段

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

✨事务特性

• 单独的隔离操作：事务中所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断
• 没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交钱任何指令都不会被实际执行，也就不存在事务内的查询要看到事务里的更新，在事务外查询不能看到这个问题
• 不保证原子性：redis 同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

🎶不遵循传统的 ACIA 中的 AI

¶消息队列

消息队列主要分为两种，分别是：生产者消费者模式和发布订阅模式，这两种模式 Redis 都支持

🎶虽然 Redis 拥有这个功能，但是存在专门进行消息队列的中间件，所以到时候还是使用专门的消息队列中间件比较好

¶观察者模式（发布订阅模式）

进程间的一种消息通信模式：发送者（pub）发送消息，订阅者（sub）接收消息

下图展示了频道 channel1 ， 以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系

当有新消息通过 PUBLISH 命令发送给频道 channel1 时， 这个消息就会被发送给订阅它的三个客户端：

¶常用命令

¶redis 高可用与集群

虽然 redis 可以实现单机的数据持久化，但无论是 RDB 也好或者 AOF 也好，都解决不了单点宕机问题，即一旦单台 redis 服务器本身出现系统故障、硬件故障等问题后，就会直接造成数据的丢失，因此需要使用另外的技术来解决单点问题

¶主从复制

❓是什么

• 以防止单机部署时出现问题，整个服务就不能访问这种情况，主从复制可以做到自动将主机上的内容同步到从机中

✨能干嘛

• 读写分离
• 容灾恢复

Master-Slaver机制,Master 以写为主，Slave 以读为主

¶配置

🎶配从不配主

slaver 配置命令：slaveof 主库IP 主库端口

每次与 master 断开后，都需要重新连接，除非配置到 redis.conf 文件（具体位置在##### REPLICATION ####）

可以通过如下命令查看 redis 主从复制的状态

1
2
3
4
5
6
7
8
9
10
11
12

127.0.0.1:6379> info replication
## Replication
role:master
connected_slaves:0
master_replid:81c4ffb7155436aa176fd8e71c5b35454dbc3d08
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

修改配置文件细节操作

• 拷贝多个 redis.conf 文件，按’redis[port].conf’重命名
• 开启 daemonize yes
• pid 文件名字
• 指定端口
• log 文件名字
• dump.rdb 名字

¶常见主从配置三招

Redis Slave 也要开启持久化并设置和 master 同样的连接密码，因为后期 slave 会有提升为 master 的可能，slave 端切换 master 后，会丢失之前的所有数据

一旦某个 slaver 成为一个 master 的 slave，redis slave 服务会清空当前 redis 服务器上的所有数据并将 master 的数据导入到自己的内存，但是断开同步关系后不会删除当前已经同步过的数据

¶一主两从

¶薪火相传

• 上一个 Slave 可以是下一个 slave 的 Master，Slave 同样可以接收其他 slaves 的连接和同步请求，那么该 slave 作为了链条中下一个的 master, 可以有效减轻 master 的写压力（奴隶的奴隶还是奴隶）
• 中途变更转向：会清除之前的数据，重新建立拷贝最新的

¶反客为主

SLAVEOF no one

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

¶复制原理

slave 启动成功连接到 master 后会发送一个 sync 命令

master 接收到命令，启动后台的存盘进程，同时收集所有接受到的用于修改数据集命令，在后台进程执行完毕后，master 将传送整个数据文件到 slave，以完成一次完全同步

全量复制：而 slave 服务在接收到数据库文件数据后，将其存盘并加载到内存中

增量复制：master 继续将新的所有收集到的修改命令依次传给 slave，完成哦同步

但是只要是重新连接 master，一次完全同步将被自动执行

¶哨兵模式（sentinel）

一组 sentinel 能同时监控多个 master

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

¶使用步骤

新建sentinel.conf文件

配置哨兵

• sentinel monitor 被监控数据库名字（自己起名字）127.0.0.1 6379 1
• sentinel monitor <master-group-name> <ip> <port> <quorum>
• 最后一个数字 1，表示主机挂掉后 slave 投票看让谁接替成为主机，票数多者成为 master

启动哨兵

redis-sentinel ./sentinel.conf

🎶如果之前的 master 宕机之后重新加入到 redis 集群中，原本的 master 将变成 slave

复制的缺点

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

¶附录

官网对事务的介绍
深入理解 redis scan