保姆级Redis教程

1. 入门概述

1.1 为什么用 nosql

Web1.0 的时代，数据访问量很有限，用一夫当关的高性能的单点服务器可以解决大部分

问题。

Web2.0 的时代的到来，用户访问量大幅度提升，同时产生了大量的用户数据。加上后来

的智能移动设备的普及，所有的互联网平台都面临了巨大的性能挑战。

解决 cpu 及内存压力

解决 IO 压力

NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是 SQL”，泛指非关系型的数据库。

NoSQL 不依赖业务逻辑方式存储，而以简单的 key-value 模式存储。因此大大的增加了数

据库的扩展能力。

➢ 不遵循 SQL 标准。

➢ 不支持 ACID。

➢ 远超于 SQL 的性能。

➢ 对数据高并发的读写

➢ 海量数据的读写

➢ 对数据高可扩展性的。

所以，出现了内存数据库，如 redis，memcache、mongoDB 等。

1.2 使用场景

1、 配合关系型数据库做高速缓存

➢ 高频次，热门访问的数据，降低数据库 IO

➢ 分布式架构，做 session 共享

多样的数据结构存储持久化数据 北大青鸟郴州科泰中心 — 唐际雄

2. Redis 基础

2.1 Redis 是什么

redis 是一个开源的、使用 C 语言编写的、支持网络交互的、可基于内存也可持久化的

Key-Value 数据库。

redis 的官网地址，非常好记，是 redis.io。（特意查了一下，域名后缀 io 属于国家域名，

是 british Indian Ocean territory，即英属印度洋领地）

目前，Vmware 在资助着 redis 项目的开发和维护。

【redis 的作者何许人也】

开门见山，先看照片：

是不是出乎了你的意料，嗯，高手总会有些地方与众不同的。

这位便是 redis 的作者，他叫 Salvatore Sanfilippo，来自意大利的西西里岛，现在居住在

卡塔尼亚。目前供职于 Pivotal 公司。

他使用的网名是 antirez，如果你有兴趣，可以去他的博客逛逛，地址是 antirez.com，当

然也可以去 follow 他的 github，地址是 http://github.com/antirez。

在面试的时候，常被问比较下 Redis 与 Memcache 的优缺点 ，个人觉得这二者并不适合

一起比较，一个是非关系型数据库 不仅可以做缓存还能干其他事情 ，一个是仅用做 缓存 。常常

让我们对这二者进行比较，主要也是由于 Redis 最广泛的应用场景就是 Cache，那么 Redis 到

底能干什么？又不能干什么呢？

Redis 都可以干什么事儿

缓存，毫无疑问这是 Redis 当今最为人熟知的使用场景，再提升服务器性能方面非常有效。

1. 排行榜 ，如果使用传统的关系型数据库来做，非常麻烦，而利用 Redis 的 SortSet 数

据结构能够非常方便搞定；

2. 计算器/限速器 ，利用 Redis 中原子性的自增操作，我们可以统计类似用户点赞数、用

户访问数等，这类操作如果用 MySQL，频繁的读写会带来相当大的压力；限速器比较

典型的使用场景是限制某个用户访问某个 API 的频率，常用的有抢购时，防止用户疯

狂点击带来不必要的压力；

3. 好友关系 ，利用集合的一些命令，比如求交集、并集、差集等，可以方便搞定一些共同

好友、共同爱好之类的功能；

4. 简单消息队列 ，除了 Redis 自身的发布/订阅模式，我们也可以利用 List 来实现一个队

列机制，比如到货通知、邮件发送之类的需求，不需要高可靠，但是会带来非常大的

DB 压力，完全可以用 List 来完成异步解耦；

5. Session 共享 ，以 PHP 为例，默认 Session 是保存在服务器的文件中，如果是集群服

务，同一个用户过来可能落在不同机器上，这就会导致用户频繁登陆；采用 Redis 保

存 Session 后，无论用户落在那台机器上都能够获取到对应的 Session 信息。

Redis 不能干什么事儿

Redis 感觉能干的事情特别多，但它不是万能的，合适的地方用它事半功倍，如果滥用

可能导致系统的不稳定、成本增高等问题。

比如，用 Redis 去保存用户的基本信息，虽然它能够支持持久化，但是它的持久化方

案并不能保证数据绝对的落地，并且还可能带来 Redis 性能下降，因为 持久化太过频繁会

增大 Redis 服务的压力 。

简单总结就是 数据量太大、数据访问频率非常低的业务 都不适合使用 Redis，数据太大

会增加成本，访问频率太低，保存在内存中纯属浪费资源。

选择 Redis 的理由

上面说了 Redis 的一些使用场景，那么这些场景的解决方案也有很多其它选择，比如

缓存可以用 Memcache，Session 共享还能用 MySql 来实现，消息队列可以用

RabbitMQ，我们为什么一定要用 Redis 呢？

速度快，完全基于内存 ，使用 C 语言实现，网络层使用 epoll 解决高并发问题，单线

程模型避免了不必要的上下文切换及竞争条件；

注意：单线程仅仅是说在网络请求这一模块上用一个请求处理客户端的请求，像持久化它就会

重开一个线程/进程去进行处理。

丰富的数据类型 ，Redis 有 8 种数据类型，当然常用的主要是 String、Hash、List、Set、

第4页 ,共67页 北大青鸟郴州科泰中心 — 唐际雄

SortSet 这 5 种类型，他们都是基于键值的方式组织数据。每一种数据类型提供了非常丰富的

操作命令，可以满足绝大部分需求，如果有特殊需求还能自己通过 lua 脚本自己创建新的命令

（具备原子性）；

除了提供的丰富的数据类型，Redis 还提供了像 慢查询分析、性能测试、Pipeline、事务、

Lua 自定义命令、Bitmaps、HyperLogLog、发布/订阅、Geo 等个性化功能。

Redis 的代码开源在 GitHub， 代码非常简单优雅，任何人都能够吃透它的源码 ；它的编译

安装也是非常的简单，没有任何的系统依赖；有非常活跃的社区，各种客户端的语言支持也是

非常完善。另外它还支持事务、持久化、主从复制让高可用、分布式成为可能。

2.2 Redis 安装配置

2.2.1 Windows 环境安装及操作

下载地址： https://github.com/MSOpenTech/redis/releases

Redis 支持 32 位和 64 位。这个需要根据你系统平台的实际情况选择，这里我们下载 Redis

x64-xxx.zip 压缩包到 C 盘，解压后，将文件夹重新命名为 redis 。

2.2.2 Windows 启动服务

打开一个 cmd 窗口

使用 cd 命令切换目录到 C:\redis 运行 redis-server.exe redis.windows.conf

如果想方便的话，可以把 redis 的路径加到系统的环境变量里，这样就省得再输路径了，后面的那个

redis.windows.conf 可以省略，如果省略，会启用默认的。输入之后，会显示如下界面：

这时候另启一个 cmd 窗口，原来的不要关闭，不然就无法访问服务端了。

2.2.3 命令窗口简单测试

切换到 redis 目录下运行 redis-cli.exe -h 127.0.0.1 -p 6379 。

设置键值对 set myKey abc

取出键值对 get myKey

2.3 redis 常用命令

keys pattern

列出所有 key，*表示区配所有。

set

设置 key 对应的值为 string 类型的 value。

setnx

设置 key 对应的值为 string 类型的 value。 如果 key 已经存在，返回 0 ，nx 是 not exist 的意

思。

del

删除某个 key，第一次返回 1 删除了 第二次返回 0

expire

设置过期时间（单位秒）

TTL

查看剩下多少时间，返回负数则 key 失效，key 不存在了

setex

设置 key 对应的值为 string 类型的 value，并指定此键值对应的有效期。

mset

一次设置多个 key 的值，成功返回 ok 表示所有的值都设置了，失败返回 0 表示没有任何值被

设置。

getset

设置 key 的值，并返回 key 的旧值。

mget

一次获取多个 key 的值，如果对应 key 不存在，则对应返回 nil。

incr

对 key 的值做加加操作,并返回新的值。注意 incr 一个不是 int 的 value 会返回错误，incr 一个

不存在的 key，则设置 key 为 1

incrby

同 incr 类似，加指定值 ，key 不存在时候会设置 key，并认为原来的 value 是 0

decr

对 key 的值做的是减减操作，decr 一个不存在 key，则设置 key 为-1

decrby

同 decr，减指定值。

append

给指定 key 的字符串值追加 value,返回新字符串值的长度。

strlen

取指定 key 的 value 值的长度。

persist xxx(取消过期时间)

选择数据库（0-15 库）

select 0

选择数据库

move age 1

把 age 移动到 1 库

randomkey

随机返回一个 key

rename

重命名

type

返回数据类型

2.4 Redis 数据结构

redis 是一种高级的 key:value 存储系统，其中 value 支持五种数据类型：

1. 字符串（string）

2. 字符串列表（list）

3. 字符串集合（set）

4. 有序字符串集合（sorted set）

5. 哈希（hashe）

而关于 key，有几个点要提醒大家：

1. key 不要太长 ，尽量不要超过 1024 字节，这不仅消耗内存，而且会降低查找的效率；

第7页 ,共67页 北大青鸟郴州科泰中心 — 唐际雄

2. key 也不要太短 ，太短的话，key 的可读性会降低；

3. 在一个项目中， key 最好使用统一的命名模式 ，例如 user:10000:passwd。

2.4.1 strings

有人说，如果只使用 redis 中的字符串类型，且不使用 redis 的持久化功能，那么，redis

就和 memcache 非常非常的像了。这说明 strings 类型是一个很基础的数据类型，也是任何存

储系统都必备的数据类型。

我们来看一个最简单的例子：

set mystr "hello world!" //设置字符串类型

get mystr //读取字符串类型

字符串类型的用法就是这么简单，因为是二进制安全的，所以你完全可以把一个图片文件的内

容作为字符串来存储。

另外，我们还可以通过字符串类型进行数值操作：

127.0.0.1:6379> set mynum "2"

OK

127.0.0.1:6379> get mynum

"2"

127.0.0.1:6379> incr mynum

(integer) 3

127.0.0.1:6379> get mynum

"3"

看，在遇到数值操作时，redis 会将字符串类型转换成数值。

由于 INCR 等指令本身就具有原子操作的特性，所以我们完全可以利用 redis 的 INCR、

INCRBY、DECR、DECRBY 等指令来实现原子计数的效果，假如，在某种场景下有 3 个客户端

同时读取了 mynum 的值（值为 2），然后对其同时进行了加 1 的操作，那么，最后 mynum

的值一定是 5。不少网站都利用 redis 的这个特性来实现业务上的统计计数需求。

2.4.2 Lists

redis 的另一个重要的数据结构叫做 lists，翻译成中文叫做“列表”。

首先要明确一点，redis 中的 lists 在底层实现上并不是数组，而是链表，也就是说对于一

个具有上百万个元素的 lists 来说，在头部和尾部插入一个新元素，其时间复杂度是常数级别的，

比如用 LPUSH 在 10 个元素的 lists 头部插入新元素，和在上千万元素的 lists 头部插入新元素

的速度应该是相同的。

虽然 lists 有这样的优势，但同样有其弊端，那就是，链表型 lists 的元素 定位会比较慢 ，而

数组型 lists 的元素定位就会快得多。

lists 的常用操作包括 LPUSH、RPUSH、LRANGE 等。我们可以用 LPUSH 在 lists 的左侧

插入一个新元素，用 RPUSH 在 lists 的右侧插入一个新元素，用 LRANGE 命令从 lists 中指定

一个范围来提取元素。我们来看几个例子：

//新建一个 list 叫做 mylist，并在列表头部插入元素"1"

127.0.0.1:6379> lpush mylist "1"

//返回当前 mylist 中的元素个数

(integer) 1

//在 mylist 右侧插入元素"2"

127.0.0.1:6379> rpush mylist "2"

(integer) 2

//在 mylist 左侧插入元素"0"

127.0.0.1:6379> lpush mylist "0"

(integer) 3

//列出 mylist 中从编号 0 到编号 1 的元素

127.0.0.1:6379> lrange mylist 0 1

1) "0"

2) "1"

//列出 mylist 中从编号 0 到倒数第一个元素

127.0.0.1:6379> lrange mylist 0 -1

1) "0"

2) "1"

3) "2"

lists 的应用相当广泛，随便举几个例子：

1.我们可以利用 lists 来实现一个 消息队列 ，而且可以确保先后顺序，不必像 MySQL 那样还需

要通过 ORDER BY 来进行排序。

2.利用 LRANGE 还可以很方便的 实现分页 的功能。

3.在博客系统中，每片博文的评论也可以存入一个单独的 list 中。

2.4.3 Set 集合

redis 的集合，是一种无序的集合，集合中的元素没有先后顺序。

集合相关的操作也很丰富，如添加新元素、删除已有元素、取交集、取并集、取差集等。我们

来看例子：

//向集合 myset 中加入一个新元素"one"

127.0.0.1:6379> sadd myset "one"

(integer) 1

127.0.0.1:6379> sadd myset "two"

(integer) 1

//列出集合 myset 中的所有元素

127.0.0.1:6379> smembers myset

1) "one"

2) "two"

//判断元素 1 是否在集合 myset 中，返回 1 表示存在

127.0.0.1:6379> sismember myset "one"

(integer) 1

//判断元素 3 是否在集合 myset 中，返回 0 表示不存在

127.0.0.1:6379> sismember myset "three"

(integer) 0

//新建一个新的集合 yourset

127.0.0.1:6379> sadd yourset "1"

(integer) 1

127.0.0.1:6379> sadd yourset "2"

(integer) 1

127.0.0.1:6379> smembers yourset

1) "1"

2) "2"

//对两个集合求并集

127.0.0.1:6379> sunion myset yourset

1) "1"

2) "one"

3) "2"

4) "two"

对于集合的使用，也有一些常见的方式，比如，QQ 有一个社交功能叫做“好友标签”，

大家可以给你的好友贴标签，比如“大美女”、“土豪”、“欧巴”等等，这时就可以使用

redis 的集合来实现，把每一个用户的标签都存储在一个集合之中。

2.4.4 有序集合 zset

redis 不但提供了无需集合（sets），还很体贴的提供了有序集合（sorted sets）。有序集

合中的每个元素都关联一个序号（score），这便是排序的依据。

很多时候，我们都将 redis 中的有序集合叫做 zsets，这是因为在 redis 中，有序集合相关

的操作指令都是以 z 开头的，比如 zrange、zadd、zrevrange、zrangebyscore 等等

老规矩，我们来看几个生动的例子：

//新增一个有序集合 myzset，并加入一个元素 baidu.com，给它赋予的序号是 1：

127.0.0.1:6379> zadd myzset 1 baidu.com

(integer) 1

//向 myzset 中新增一个元素 360.com，赋予它的序号是 3

127.0.0.1:6379> zadd myzset 3 360.com

(integer) 1

//向 myzset 中新增一个元素 google.com，赋予它的序号是 2

127.0.0.1:6379> zadd myzset 2 google.com

(integer) 1

//列出 myzset 的所有元素，同时列出其序号，可以看出 myzset 已经是有序的了。

127.0.0.1:6379> zrange myzset 0 -1 with scores

1) "baidu.com"

2) "1"

3) "google.com"

4) "2"

5) "360.com"

6) "3"

//只列出 myzset 的元素

127.0.0.1:6379> zrange myzset 0 -1

1) "baidu.com"

2) "google.com"

3) "360.com"

2.4.5 Hash( 哈希 )

最后要给大家介绍的是 hashes，即哈希。哈希是从 redis-2.0.0 版本之后才有的数据结构。

hashes 存的是字符串和字符串值之间的映射，比如一个用户要存储其全名、姓氏、年龄等等，

就很适合使用哈希。

我们来看一个例子：

//建立哈希，并赋值

127.0.0.1:6379> HMSET user:001 username antirez password P1pp0 age 34

OK

//列出哈希的内容

127.0.0.1:6379> HGETALL user:001

1) "username"

2) "antirez"

3) "password"

4) "P1pp0"

5) "age"

6) "34"

//更改哈希中的某一个值

127.0.0.1:6379> HSET user:001 password 12345

(integer) 0

//再次列出哈希的内容

127.0.0.1:6379> HGETALL user:001

1) "username"

2) "antirez"

3) "password"

4) "12345"

5) "age"

6) "34"

有关 hashes 的操作，同样很丰富，需要时，大家可以从 这里 查询。

2.5 redis 持久化 – 两种方式

持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失。

redis 提供了两种持久化的方式，分别是 RDB（Redis DataBase）(默认)和 AOF

（Append Only File）。

RDB，简而言之，就是在不同的时间点，将 redis 存储的数据生成快照并存储到磁盘等介

质上；

AOF，则是换了一个角度来实现持久化，那就是将 redis 执行过的 所有写指令记录下来 ，

在下次 redis 重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。

其实 RDB 和 AOF 两种方式也可以 同时使用 ，在这种情况下，如果 redis 重启的话，则会

优先采用 AOF 方式来进行数据恢复，这是因为 AOF 方式的数据恢复完整度更高。

如果你没有数据持久化的需求，也完全可以关闭 RDB 和 AOF 方式，这样的话，redis 将变

成一个纯内存数据库，就像 memcache 一样。

2.5.1 redis 持久化 – RDB

RDB 方式，是将 redis 某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法。

功能核心函数 rdbSave(生成 RDB 文件)和 rdbLoad（从文件加载内存）两个函数：

redis 在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结

束了，才会用这个临时文件替换上次持久化好的文件。正是这种特性，让我们可以随时来进行

备份，因为快照文件总是完整可用的。

对于 RDB 方式，redis 会单独创建（fork）一个子进程来进行持久化，而主进程是不会进

行任何 IO 操作的，这样就确保了 redis 极高的性能。

RDB 手动触发

1、SAVE 直接调用 rdbSave ，阻塞 Redis 主进程，导致无法提供服务。

2、BGSAVE 则 fork 出一个子进程，子进程负责调用 rdbSave ，在保存完成后（先将数据集写

入临时文件，写入成功之后再替换之前的文件，用二进制压缩存储）向主进程发送信号告知完

成。在 BGSAVE 执行期间仍可以继续处理客户端的请求

如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方式要

比 AOF 方式更加的高效。

虽然 RDB 有不少优点，但它的缺点也是不容忽视的。如果你对数据的完整性非常敏感，那

么 RDB 方式就不太适合你，因为即使你每 5 分钟都持久化一次，当 redis 故障时，仍然会有近

5 分钟的数据丢失。所以，redis 还提供了另一种持久化方式，那就是 AOF。

2.5.2 redis 持久化 – AOF

AOF，英文是 Append Only File，即只允许追加不允许改写的文件。

如前面介绍的，AOF 方式是将执行过的写指令记录下来，在数据恢复时按照从前到后的顺

序再将指令都执行一遍，就这么简单。

AOF 整个流程分两步：

第一步是命令的实时写入，不同级别可能有 1 秒数据损失。命令先追加到 aof_buf 然后再

同步到 AO 磁盘，如果实时写入磁盘会带来非常高的磁盘 IO，影响整体性能

第二步是对 aof 文件的重写，目的是为了减少 AOF 文件的大小，可以自动触发或者手动触

发(BGREWRITEAOF)，是 Fork 出子进程操作，期间 Redis 服务仍可用。

我们通过配置 redis.conf 中的 appendonly yes 就可以打开 AOF 功能。如果有写操作（如

SET 等），redis 就会被追加到 AOF 文件的末尾。

默认的 AOF 持久化策略是每秒钟 fsync 一次（fsync 是指把缓存中的写指令记录到磁盘

中），因为在这种情况下，redis 仍然可以保持很好的处理性能，即使 redis 故障，也只会丢失

最近 1 秒钟的数据。

如果在追加日志时，恰好遇到磁盘空间满、inode 满或断电等情况导致日志写入不完整，

也没有关系，redis 提供了 redis-check-aof 工具，可以用来进行日志修复。

因为采用了追加方式，如果不做任何处理的话，AOF 文件会变得越来越大，为此，redis

提供了 AOF 文件重写（rewrite）机制，即当 AOF 文件的大小超过所设定的阈值时，redis 就

会启动 AOF 文件的内容压缩，只保留可以恢复数据的最小指令集。举个例子或许更形象，假如

我们调用了 100 次 INCR 指令，在 AOF 文件中就要存储 100 条指令，但这明显是很低效的，

完全可以把这 100 条指令合并成一条 SET 指令，这就是重写机制的原理。

在进行 AOF 重写时，仍然是采用先写临时文件，全部完成后再替换的流程，所以断电、磁

盘满等问题都不会影响 AOF 文件的可用性，这点大家可以放心。

AOF 方式的另一个好处，我们通过一个“场景再现”来说明。某同学在操作 redis 时，不

小心执行了 FLUSHALL，导致 redis 内存中的数据全部被清空了，这是很悲剧的事情。不过这

也不是世界末日，只要 redis 配置了 AOF 持久化方式，且 AOF 文件还没有被重写（rewrite），

我们就可以用最快的速度暂停 redis 并编辑 AOF 文件，将最后一行的 FLUSHALL 命令删除，然

后重启 redis，就可以恢复 redis 的所有数据到 FLUSHALL 之前的状态了。是不是很神奇，这就

是 AOF 持久化方式的好处之一。但是如果 AOF 文件已经被重写了，那就无法通过这种方法来

恢复数据了。

虽然优点多多，但 AOF 方式也同样存在缺陷，比如在同样数据规模的情况下，AOF 文件要

比 RDB 文件的体积大。而且，AOF 方式的恢复速度也要慢于 RDB 方式。

如果你直接执行 BGREWRITEAOF 命令，那么 redis 会生成一个全新的 AOF 文件，其中便

包括了可以恢复现有数据的最少的命令集。

如果运气比较差，AOF 文件出现了被写坏的情况，也不必过分担忧，redis 并不会贸然加

载这个有问题的 AOF 文件，而是报错退出。这时可以通过以下步骤来修复出错的文件：

1.备份被写坏的 AOF 文件

2.运行 redis-check-aof –fix 进行修复

3.用 diff -u 来看下两个文件的差异，确认问题点

4.重启 redis，加载修复后的 AOF 文件

每当执行服务器(定时)任务或者函数时 flushAppendOnlyFile 函数都会被调用， 这个函数

执行以下两个工作

aof 写入保存：

WRITE：根据条件，将 aof_buf 中的缓存写入到 AOF 文件

SAVE：根据条件，调用 fsync 或 fdatasync 函数，将 AOF 文件保存到磁盘中。

存储结构:

内容是 redis 通讯协议(RESP )格式的命令文本存储。

什么是 RESP？有什么特点？

RESP 是 redis 客户端和服务端之前使用的一种通讯协议；

RESP 的特点：实现简单、快速解析、可读性好

For Simple Strings the first byte of the reply is "+" 回复

For Errors the first byte of the reply is "-" 错误

For Integers the first byte of the reply is ":" 整数

For Bulk Strings the first byte of the reply is "$" 字符串

For Arrays the first byte of the reply is "*" 数组

2.5.3 redis 持久化 – AOF 重写

AOF 重写的内部运行原理，我们有必要了解一下。

在重写即将开始之际，red 这个子进 is 会创建（fork）一个“重写子进程”，程会首先读

取现有的 AOF 文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。

与此同时，主工作进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到

原有的 AOF 文件中，这样做是保证原有的 AOF 文件的可用性，避免在重写过程中出现意外。

当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将

内存中缓存的写指令追加到新 AOF 文件中。

当追加结束后，redis 就会用新 AOF 文件来代替旧 AOF 文件，之后再有新的写指令，就都

会追加到新的 AOF 文件中了。

2.5.4 redis 持久化 – 如何选择 RDB 和 AOF

1、aof 文件比 rdb 更新频率高，优先使用 aof 还原数据。

2、aof 比 rdb 更安全也更大

3、rdb 性能比 aof 好

4、如果两个都配了优先加载 AOF

对于我们应该选择 RDB 还是 AOF，官方的建议是两个同时使用。这样可以提供更可靠的

持久化方案。

2.6 Redis 配置文件

我们可以在启动 redis-server 时指定应该加载的配置文件，方法如下：

$ ./redis-server /path/to/redis.conf

接下来，我们就来讲解下 redis 配置文件的各个配置项的含义，注意，本文是基于 redis-

2.8.4 版本进行讲解的。

redis 官方提供的 redis.conf 文件，足有 700+行，其中 100 多行为有效配置行，另外的

600 多行为注释说明。

在配置文件的开头部分，首先明确了一些度量单位：

# 1k => 1000 bytes

# 1kb => 1024 bytes

# 1m => 1000000 bytes

# 1mb => 1024*1024 bytes

# 1g => 1000000000 bytes

# 1gb => 1024*1024*1024 bytes

可以看出，redis 配置中对单位的大小写不敏感，1GB、1Gb 和 1gB 都是相同的。由此也

说明，redis 只支持 bytes，不支持 bit 单位。

redis 支持“主配置文件中引入外部配置文件”，很像 C/C++中的 include 指令，比如：

include /path/to/other.conf

如果你看过 redis 的配置文件，会发现还是很有条理的。redis 配置文件被分成了几大块区

域，它们分别是：

1.通用（general）

2.快照（snapshotting）

3.复制（replication）

4.安全（security）

5.限制（limits)

6.追加模式（append only mode)

7.LUA 脚本（lua scripting)

8.慢日志（slow log)

9.事件通知（event notification）

下面我们就来逐一讲解。

2.6.1 redis 配置 - 通用

默认情况下，redis 并不是以 daemon 形式来运行的。通过 daemonize 配置项可以控制

redis 的运行形式，如果改为 yes，那么 redis 就会以 daemon 形式运行：

daemonize no

当以 daemon 形式运行时，redis 会生成一个 pid 文件，默认会生成在/var/run/redis.pid。

当然，你可以通过 pidfile 来指定 pid 文件生成的位置，比如：

pidfile /path/to/redis.pid

默认情况下，redis 会响应本机所有可用网卡的连接请求。当然，redis 允许你通过 bind 配

置项来指定要绑定的 IP，比如：

bind 192.168.1.2 10.8.4.2

redis 的默认服务端口是 6379，你可以通过 port 配置项来修改。如果端口设置为 0 的话，

redis 便不会监听端口了。

port 6379

有些同学会问“如果 redis 不监听端口，还怎么与外界通信呢”，其实 redis 还支持通过

unix socket 方式来接收请求。可以通过 unixsocket 配置项来指定 unix socket 文件的路径，

并通过 unixsocketperm 来指定文件的权限。

unixsocket /tmp/redis.sock

unixsocketperm 755

当一个 redis-client 一直没有请求发向 server 端，那么 server 端有权主动关闭这个连接，

可以通过 timeout 来设置“空闲超时时限”，0 表示永不关闭。

timeout 0

TCP 连接保活策略，可以通过 tcp-keepalive 配置项来进行设置，单位为秒，假如设置为

60 秒，则 server 端会每 60 秒向连接空闲的客户端发起一次 ACK 请求，以检查客户端是否已

经挂掉，对于无响应的客户端则会关闭其连接。所以关闭一个连接最长需要 120 秒的时间。如

果设置为 0，则不会进行保活检测。

tcp-keepalive 0

redis 支持通过 loglevel 配置项设置日志等级，共分四级，即 debug、verbose、notice、

warning。

loglevel notice

redis 也支持通过 logfile 配置项来设置日志文件的生成位置。如果设置为空字符串，则

redis 会将日志输出到标准输出。假如你在 daemon 情况下将日志设置为输出到标准输出，则

日志会被写到/dev/null 中。

logfile ""

如果希望日志打印到 syslog 中，也很容易，通过 syslog-enabled 来控制。另外，syslog

ident 还可以让你指定 syslog 里的日志标志，比如：

syslog-ident redis

而且还支持指定 syslog 设备，值可以是 USER 或 LOCAL0-LOCAL7。具体可以参考

syslog 服务本身的用法。

syslog-facility local0

对于 redis 来说，可以设置其数据库的总数量，假如你希望一个 redis 包含 16 个数据库，

那么设置如下：

databases 16

这 16 个数据库的编号将是 0 到 15。默认的数据库是编号为 0 的数据库。用户可以使用

select <DBid>来选择相应的数据库。

2.6.2 redis 配置 – 快照

快照，主要涉及的是 redis 的 RDB 持久化相关的配置，我们来一起看一看。

我们可以用如下的指令来让数据保存到磁盘上，即控制 RDB 快照功能：

save <seconds> <changes>

举例来说：

save 900 1 //表示每 15 分钟且至少有 1 个 key 改变，就触发一次持久化

save 300 10 //表示每 5 分钟且至少有 10 个 key 改变，就触发一次持久化

save 60 10000 //表示每 60 秒至少有 10000 个 key 改变，就触发一次持久化

如果你想禁用 RDB 持久化的策略，只要不设置任何 save 指令就可以，或者给 save 传入一

个空字符串参数也可以达到相同效果，就像这样：

save ""

如果用户开启了 RDB 快照功能，那么在 redis 持久化数据到磁盘时如果出现失败，默认情

况下，redis 会停止接受所有的写请求。这样做的好处在于可以让用户很明确的知道内存中的数

据和磁盘上的数据已经存在不一致了。如果 redis 不顾这种不一致，一意孤行的继续接收写请求，

就可能会引起一些灾难性的后果。

如果下一次 RDB 持久化成功，redis 会自动恢复接受写请求。

当然，如果你不在乎这种数据不一致或者有其他的手段发现和控制这种不一致的话，你完

全可以关闭这个功能，以便在快照写入失败时，也能确保 redis 继续接受新的写请求。

配置项如下：

stop-writes-on-bgsave-error yes

对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis 会采用 LZF 算

法进行压缩。如果你不想消耗 CPU 来进行压缩的话，可以设置为关闭此功能，但是存储在磁盘

上的快照会比较大。

rdbcompression yes

在存储快照后，我们还可以让 redis 使用 CRC64 算法来进行数据校验，但是这样做会增加

大约 10%的性能消耗，如果你希望获取到最大的性能提升，可以关闭此功能。

rdbchecksum yes

我们还可以设置快照文件的名称，默认是这样配置的：

dbfilename dump.rdb

最后，你还可以设置这个快照文件存放的路径。比如默认设置就是当前文件夹：

dir ./

2.6.3 redis 配置 – 复制

redis 提供了 主从同步功能 。

通过 slaveof 配置项可以控制某一个 redis 作为另一个 redis 的从服务器，通过指定 IP 和

端口来定位到主 redis 的位置。一般情况下，我们会建议用户为从 redis 设置一个不同频率的快

照持久化的周期，或者为从 redis 配置一个不同的服务端口等等。

slaveof <masterip> <masterport>

如果主 redis 设置了验证密码的话（使用 requirepass 来设置），则在从 redis 的配置中要

使用 masterauth 来设置校验密码，否则的话，主 redis 会拒绝从 redis 的访问请求。

masterauth <master-password>

当从 redis 失去了与主 redis 的连接，或者主从同步正在进行中时，redis 该如何处理外部 北大青鸟郴州科泰中心 — 唐际雄

发来的访问请求呢？这里，从 redis 可以有两种选择：

第一种选择：如果 slave-serve-stale-data 设置为 yes（默认），则从 redis 仍会继续响应

客户端的读写请求。

第二种选择：如果 slave-serve-stale-data 设置为 no，则从 redis 会对客户端的请求返回

“SYNC with master in progress”，当然也有例外，当客户端发来 INFO 请求和 SLAVEOF

请求，从 redis 还是会进行处理。

你可以控制一个从 redis 是否可以接受写请求。将数据直接写入从 redis，一般只适用于那

些生命周期非常短的数据，因为在主从同步时，这些临时数据就会被清理掉。自从 redis2.6 版

本之后，默认从 redis 为只读。

slave-read-only yes

只读的从 redis 并不适合直接暴露给不可信的客户端。为了尽量降低风险，可以使用

rename-command 指令来将一些可能有破坏力的命令重命名，避免外部直接调用。比如：

rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52

从 redis 会周期性的向 redis 发出 PING 包。你可以通过 repl_ping_slave_period 指令来

控制其周期。默认是 10 秒。

repl-ping-slave-period 10

在主从同步时，可能在这些情况下会有超时发生：

1.以从 redis 的角度来看，当有大规模 IO 传输时。

2.以从 redis 的角度来看，当数据传输或 PING 时，主 redis 超时

3.以主 redis 的角度来看，在回复从 redis 的 PING 时，从 redis 超时

用户可以设置上述超时的时限，不过要确保这个时限比 repl-ping-slave-period 的值要大，

否则每次主 redis 都会认为从 redis 超时。

repl-timeout 60

我们可以控制在主从同步时是否禁用 TCP_NODELAY。如果开启 TCP_NODELAY，那么主

redis 会使用更少的 TCP 包和更少的带宽来向从 redis 传输数据。但是这可能会增加一些同步的

延迟，大概会达到 40 毫秒左右。如果你关闭了 TCP_NODELAY，那么数据同步的延迟时间会

降低，但是会消耗更多的带宽。（如果你不了解 TCP_NODELAY，可以到这里来科普一下）。

repl-disable-tcp-nodelay no

我们还可以设置同步队列长度。队列长度（backlog)是主 redis 中的一个缓冲区，在与从

redis 断开连接期间，主 redis 会用这个缓冲区来缓存应该发给从 redis 的数据。这样的话，当

从 redis 重新连接上之后，就不必重新全量同步数据，只需要同步这部分增量数据即可。

repl-backlog-size 1mb

如果主 redis 等了一段时间之后，还是无法连接到从 redis，那么缓冲队列中的数据将被清

理掉。我们可以设置主 redis 要等待的时间长度。如果设置为 0，则表示永远不清理。默认是 1

个小时。

repl-backlog-ttl 3600

我们可以给众多的从 redis 设置优先级，在主 redis 持续工作不正常的情况，优先级高的从

redis 将会升级为主 redis。而编号越小，优先级越高。比如一个主 redis 有三个从 redis，优先

级编号分别为 10、100、25，那么编号为 10 的从 redis 将会被首先选中升级为主 redis。当优

先级被设置为 0 时，这个从 redis 将永远也不会被选中。默认的优先级为 100。

slave-priority 100

假如主 redis 发现有超过 M 个从 redis 的连接延时大于 N 秒，那么主 redis 就停止接受外

来的写请求。这是因为从 redis 一般会每秒钟都向主 redis 发出 PING，而主 redis 会记录每一

个从 redis 最近一次发来 PING 的时间点，所以主 redis 能够了解每一个从 redis 的运行情况。

min-slaves-to-write 3

min-slaves-max-lag 10

上面这个例子表示，假如有大于等于 3 个从 redis 的连接延迟大于 10 秒，那么主 redis 就

不再接受外部的写请求。上述两个配置中有一个被置为 0，则这个特性将被关闭。默认情况下

min-slaves-to-write 为 0，而 min-slaves-max-lag 为 10。

2.6.4 redis 配置 – 安全

我们可以要求 redis 客户端在向 redis-server 发送请求之前，先进行密码验证。当你的

redis-server 处于一个不太可信的网络环境中时，相信你会用上这个功能。由于 redis 性能非常

高，所以每秒钟可以完成多达 15 万次的密码尝试，所以你最好设置一个足够复杂的密码，否则

很容易被黑客破解。

requirepass ketaijiaoyu

这里我们通过 requirepass 将密码设置成“芝麻开门”。

redis 允许我们对 redis 指令进行更名，比如将一些比较危险的命令改个名字，避免被误执

行。比如可以把 CONFIG 命令改成一个很复杂的名字，这样可以避免外部的调用，同时还可以

满足内部调用的需要：

rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c89

我们甚至可以禁用掉 CONFIG 命令，那就是把 CONFIG 的名字改成一个空字符串：

rename-command CONFIG ""

但需要注意的是，如果你使用 AOF 方式进行数据持久化，或者需要与从 redis 进行通信，

那么更改指令的名字可能会引起一些问题。

2.6.5 redis 配置 - 限制

我们可以设置 redis 同时可以与多少个客户端进行连接。默认情况下为 10000 个客户端。

当你无法设置进程文件句柄限制时，redis 会设置为当前的文件句柄限制值减去 32，因为 redis

会为自身内部处理逻辑留一些句柄出来。

如果达到了此限制，redis 则会拒绝新的连接请求，并且向这些连接请求方发出“max

number of clients reached”以作回应。

maxclients 10000

我们甚至可以设置 redis 可以使用的内存量。一旦到达内存使用上限，redis 将会试图移除

内部数据，移除规则可以通过 maxmemory-policy 来指定。

如果 redis 无法根据移除规则来移除内存中的数据，或者我们设置了“不允许移除”，那么

redis 则会针对那些需要申请内存的指令返回错误信息，比如 SET、LPUSH 等。但是对于无内

存申请的指令，仍然会正常响应，比如 GET 等。

maxmemory <bytes>

需要注意的一点是，如果你的 redis 是主 redis（说明你的 redis 有从 redis），那么在设置

内存使用上限时，需要在系统中留出一些内存空间给同步队列缓存，只有在你设置的是“不移

除”的情况下，才不用考虑这个因素。

对于内存移除规则来说，redis 提供了多达 6 种的移除规则。他们是：

1.volatile-lru：使用 LRU 算法移除过期集合中的 key

2.allkeys-lru：使用 LRU 算法移除 key

3.volatile-random：在过期集合中移除随机的 key

4.allkeys-random：移除随机的 key

5.volatile-ttl：移除那些 TTL 值最小的 key，即那些最近才过期的 key。

6.noeviction：不进行移除。针对写操作，只是返回错误信息。

无论使用上述哪一种移除规则，如果没有合适的 key 可以移除的话，redis 都会针对写请求

返回错误信息。

maxmemory-policy volatile-lru

LRU 算法和最小 TTL 算法都并非是精确的算法，而是估算值。所以你可以设置样本的大小。

假如 redis 默认会检查三个 key 并选择其中 LRU 的那个，那么你可以改变这个 key 样本的数量。

maxmemory-samples 3

最后，我们补充一个信息，那就是到目前版本（2.8.4）为止，redis 支持的写指令包括了如

下这些：

set setnx setex append

incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd

sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby

zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby

getset mset msetnx exec sort

2.6.6 redis 配置 – 追加模式

默认情况下，redis 会异步的将数据持久化到磁盘。这种模式在大部分应用程序中已被验证

是很有效的，但是在一些问题发生时，比如断电，则这种机制可能会导致数分钟的写请求丢失。

如博文上半部分中介绍的，追加文件（Append Only File）是一种更好的保持数据一致性

的方式。即使当服务器断电时，也仅会有 1 秒钟的写请求丢失，当 redis 进程出现问题且操作

系统运行正常时，甚至只会丢失一条写请求。

我们建议大家，AOF 机制和 RDB 机制可以同时使用，不会有任何冲突。对于如何保持数

据一致性的讨论，请参见本文。

appendonly no

我们还可以设置 aof 文件的名称：

appendfilename "appendonly.aof"

fsync()调用，用来告诉操作系统立即将缓存的指令写入磁盘。一些操作系统会“立即”进

行，而另外一些操作系统则会“尽快”进行。

redis 支持三种不同的模式：

1.no：不调用 fsync()。而是让操作系统自行决定 sync 的时间。这种模式下，redis 的性能

会最快。

2.always：在每次写请求后都调用 fsync()。这种模式下，redis 会相对较慢，但数据最安

全。

3.everysec：每秒钟调用一次 fsync()。这是性能和安全的折衷。

默认情况下为 everysec。有关数据一致性的揭秘，可以 参考 本文 。

appendfsync everysec

当 fsync 方式设置为 always 或 everysec 时，如果后台持久化进程需要执行一个很大的磁

盘 IO 操作，那么 redis 可能会在 fsync()调用时卡住。目前尚未修复这个问题，这是因为即使我

们在另一个新的线程中去执行 fsync()，也会阻塞住同步写调用。

为了缓解这个问题，我们可以使用下面的配置项，这样的话，当 BGSAVE 或

BGWRITEAOF 运行时，fsync()在主进程中的调用会被阻止。这意味着当另一路进程正在对

AOF 文件进行重构时，redis 的持久化功能就失效了，就好像我们设置了“appendsync none”

一样。如果你的 redis 有时延问题，那么请将下面的选项设置为 yes。否则请保持 no，因为这

是保证数据完整性的最安全的选择。

no-appendfsync-on-rewrite no

我们允许 redis 自动重写 aof。当 aof 增长到一定规模时，redis 会隐式调用

BGREWRITEAOF 来重写 log 文件，以缩减文件体积。

redis 是这样工作的：redis 会记录上次重写时的 aof 大小。假如 redis 自启动至今还没有

进行过重写，那么启动时 aof 文件的大小会被作为基准值。这个基准值会和当前的 aof 大小进

行比较。如果当前 aof 大小超出所设置的增长比例，则会触发重写。另外，你还需要设置一个

最小大小，是为了防止在 aof 很小时就触发重写。

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

如果设置 auto-aof-rewrite-percentage 为 0，则会关闭此重写功能。

2.6.7 redis 配置 – LUA 脚本

lua 脚本的最大运行时间是需要被严格限制的，要注意单位是毫秒：

lua-time-limit 5000

如果此值设置为 0 或负数，则既不会有报错也不会有时间限制。

2.6.8 redis 配置 – 慢日志

redis 慢日志是指一个系统进行日志查询超过了指定的时长。这个时长不包括 IO 操作，比

如与客户端的交互、发送响应内容等，而仅包括实际执行查询命令的时间。

第22页 ,共67页 北大青鸟郴州科泰中心 — 唐际雄

针对慢日志，你可以设置两个参数，一个是执行时长，单位是微秒，另一个是慢日志的长

度。当一个新的命令被写入日志时，最老的一条会从命令日志队列中被移除。

单位是微秒，即 1000000 表示一秒。负数则会禁用慢日志功能，而 0 则表示强制记录每一

个命令。

slowlog-log-slower-than 10000

慢日志最大长度，可以随便填写数值，没有上限，但要注意它会消耗内存。你可以使用

SLOWLOG RESET 来重设这个值。

slowlog-max-len 128

2.6.9 redis 配置 – 高级配置

有关哈希数据结构的一些配置项：

hash-max-ziplist-entries 512

hash-max-ziplist-value 64

有关列表数据结构的一些配置项：

list-max-ziplist-entries 512

list-max-ziplist-value 64

有关集合数据结构的配置项：

set-max-intset-entries 512

有关有序集合数据结构的配置项：

zset-max-ziplist-entries 128

zset-max-ziplist-value 64

关于是否需要再哈希的配置项：

activerehashing yes

关于客户端输出缓冲的控制项：

client-output-buffer-limit normal 0 0 0

client-output-buffer-limit slave 256mb 64mb 60

client-output-buffer-limit pubsub 32mb 8mb 60

有关频率的配置项：

hz 10

有关重写 aof 的配置项：

aof-rewrite-incremental-fsync yes

redis 集群、redis 工作原理、redis 源码、redis 相关 LIB 库等内容

3. redis 集群

3.1 Redis 有哪些架构模式？讲讲各自的特点

3.1.1 单机版

特点：简单

问题：1、内存容量有限 2、处理能力有限 3、无法高可用。

3.1.2 主从复制

工作机制：

Redis 的复制（replication）功能允许用户根据一个 Redis 服务器来创建任意多个该服务

器的复制品，其中被复制的服务器为主服务器（master），而通过复制创建出来的服务器复制

品则为从服务器（slave）。 只要主从服务器之间的网络连接正常，主从服务器两者会具有相同

的数据，主服务器就会一直将发生在自己身上的数据更新同步 给从服务器，从而一直保证主从

服务器的数据相同。

特点：

1、master/slave 角色

2、master/slave 数据相同

3、降低 master 读压力在转交从库

问题：

无法保证高可用

没有解决 master 写的压力

3.1.3 哨兵

Redis sentinel 是一个分布式系统中监控 redis 主从服务器，并在主服务器下线时自动进行

故障转移。其中三个特性：

➢ 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

➢ 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过

API 向管理员或者其他应用程序发送通知。

➢ 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开

始一次自动故障迁移操作。

特点：

1、保证高可用

2、监控各个节点

3、自动故障迁移

缺点：主从模式，切换需要时间，丢数据

没有解决 master 写的压力

3.1.4 集群（ proxy 型）

Twemproxy 是一个 Twitter 开源的一个 redis 和 memcache 快速/轻量级代理服务器；

Twemproxy 是一个快速的单线程代理程序，支持 Memcached ASCII 协议和 redis 协议。

特点：

1、多种 hash 算法：MD5、CRC16、CRC32、CRC32a、hsieh、murmur、Jenkins

2、支持失败节点自动删除

3、后端 Sharding 分片逻辑对业务透明，业务方的读写方式和操作单个 Redis 一致

缺点：增加了新的 proxy，需要维护其高可用。

failover 逻辑需要自己实现，其本身不能支持故障的自动转移可扩展性差，进行扩缩容都需要手

动干预

3.1.5 集群（ redis-cluster ，直连型） 6 台

从 redis 3.0 之后版本支持 redis-cluster 集群，Redis-Cluster 采用无中心结构，每个节点

保存数据和整个集群状态，每个节点都和其他所有节点连接。

特点：

1、无中心架构（不存在哪个节点影响性能瓶颈），少了 proxy 层。

2、数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布。

3、可扩展性，可线性扩展到 1000 个节点，节点可动态添加或删除。

4、高可用性，部分节点不可用时，集群仍可用。通过增加 Slave 做备份数据副本

5、实现故障自动 failover，节点之间通过 gossip 协议交换状态信息，用投票机制完成 Slave

到 Master 的角色提升。

缺点：

1、资源隔离性较差，容易出现相互影响的情况。

2、数据通过异步复制，不保证数据的强一致性

3.2 window 搭建 redis 主从复制集群

主从复制模式中包含一个主数据库实例（master）与一个或多个从数据库实例（slave），

数据的复制是单向的，只能由主节点到从节点，从节点一般只读 ，如下图：

第一步：创建“redis_replication”目录，把 redis 复制三份分别命名为“redis-6379”

“redis-6380”“redis-6381”,以“6379”端口的 redis 作为主节点，以“6380”“6381”

端口的 redis 作为从节点，构成“ 一主二从 ”:

第二步：修改主节点配置文件：

1、修改 bind 或注释掉

bind 0.0.0.0

2、保护模式关闭，因为用 docker 否则无法访问

protected-mode no

3、设置密码

requirepass 设置密码

4、开启 aof 日志

appendonly yes

第三步：修改从节点配置文件：

在上述的主节点配置的基础上

1、修改自己的端口号（二从的端口号不要相同）

port 6380 和 6381

2、配置与主节点验证的密码

masterauth 设置密码

3、配置主节点的 ip 端口，认证主节点主从复制

slaveof 主机 IP 主机端口（新版 redis：replicaof 主机 IP 主机端口）

第四步：启动客户端程序，往 redis 的主节点，添加数据：

第五步：在 redis 可视化工具中，查看从节点是否有数据：

三个节点都有数据，说明“主从复制”集群搭建成功！

3.3 主从 – 用法

像 MySQL 一样，redis 是支持主从同步的，而且也支持一主多从以及多级从结构。

主从结构，一是为了纯粹的冗余备份，二是为了提升读性能，比如很消耗性能的 SORT 就

可以由从服务器来承担。

redis 的主从同步是异步进行的，这意味着主从同步不会影响主逻辑，也不会降低 redis 的

处理性能。

主从架构中，可以考虑关闭主服务器的数据持久化功能，只让从服务器进行持久化，这样

可以提高主服务器的处理性能。

在主从架构中，从服务器通常被设置为只读模式，这样可以避免从服务器的数据被误修改。

但是从服务器仍然可以接受 CONFIG 等指令，所以还是不应该将从服务器直接暴露到不安全的

网络环境中。如果必须如此，那可以考虑给重要指令进行重命名，来避免命令被外人误执行。

3.3.1 主从 – 同步原理

从服务器会向主服务器发出 SYNC 指令，当主服务器接到此命令后，就会调用 BGSAVE 指

第29页 ,共67页 北大青鸟郴州科泰中心 — 唐际雄

令来创建一个子进程专门进行数据持久化工作，也就是将主服务器的数据写入 RDB 文件中。在

数据持久化期间，主服务器将执行的写指令都缓存在内存中。

在 BGSAVE 指令执行完成后，主服务器会将持久化好的 RDB 文件发送给从服务器，从服

务器接到此文件后会将其存储到磁盘上，然后再将其读取到内存中。这个动作完成后，主服务

器会将这段时间缓存的写指令再以 redis 协议的格式发送给从服务器。

另外，要说的一点是，即使有多个从服务器同时发来 SYNC 指令，主服务器也只会执行一

次 BGSAVE，然后把持久化好的 RDB 文件发给多个下游。在 redis2.8 版本之前，如果从服务器

与主服务器因某些原因断开连接的话，都会进行一次主从之间的全量的数据同步；而在 2.8 版

本之后，redis 支持了效率更高的增量同步策略，这大大降低了连接断开的恢复成本。

主服务器会在内存中维护一个缓冲区，缓冲区中存储着将要发给从服务器的内容。从服务

器在与主服务器出现网络瞬断之后，从服务器会尝试再次与主服务器连接，一旦连接成功，从

服务器就会把“希望同步的主服务器 ID”和“希望请求的数据的偏移位置（replication

offset）”发送出去。主服务器接收到这样的同步请求后，首先会验证主服务器 ID 是否和自己

的 ID 匹配，其次会检查“请求的偏移位置”是否存在于自己的缓冲区中，如果两者都满足的话，

主服务器就会向从服务器发送增量内容。

增量同步功能，需要服务器端支持全新的 PSYNC 指令。这个指令，只有在 redis-2.8 之后才具

有。

3.4 Window 搭建 redis cluster 集群

“主从复制”模式数据都是在一个节点上的，单个节点存储是存在上限的。集群模式就是

把数据进行 分片存储 ，当一个分片数据达到上限的时候，就分成多个分片。Redis3.0 加入了

Redis 的集群模式，对数据进行分片，将不同的数据存储在不同的 master 节点上面，从而实现

了海量数据的分布式存储和在线扩容的问题。

➢ Redis Cluster 集群模式通常具有 高可用、可扩展性、分布式、容错 等特性。

➢ Redis Cluster 集群节点 最小配置 6 个节点以上(3 主 3 从) ，其中主 节点提供读写操作，从

节点作为备用节点，不提供请求 ，只作为故障转移使用。

➢ Redis Cluster 采 用虚拟槽分区 ，所有的键根据哈希函数映射到 0～16383 个整数槽内，每

个节点负责维护一部分槽以及槽所印映射的键值数据。

如上图所示，Redis 集群可以看成多个主从架构组合起来的，每一个主从架构可以看成一个

节点（其中，只有 master 节点具有处理请求的能力，slave 节点主要是用于节点的高可用）

第一步：在 redis 官网只能下载到 Linux 版本的 redis，若想下载 windows 版本的 redis 需要

去 github 下载，地址如下： https://github.com/tporadowski/redis/releases。 此处下载的

版本为 Redis-x64-5.0.14.1.zip，放在指定目录解压即可。

第二步：创建“redis-cluster”目录，在目录下，复制解压的 redis 文件夹，粘贴 5 次，分别命

名为 redis-6739、redis-6780、redis-6381、redis-6382、redis-6383、redis-6384，然后修

改配置 redis.windows.conf 文件，如下：

第三步：修改“redis.windows.conf”内容修改如下：

# 端口 （注意：改为每个文件夹对应的端口，分别为 6379、6380、6381、6382、

6383、6384）

port 6379

# 日志 (说明：不想给空就输入绝对地址)

logfile ""

# 允许创建集群

appendonly yes

cluster-enabled yes

# 节点配置文件，分别为 6379、6380、6381、6382、6383、6384

cluster-config-file nodes-6379.conf

# 连接超时时间

cluster-node-timeout 15000

# 允许远程

protected-mode no

把修改完的内容的配置文件，替换其他 redis 目录中的配置文件，把 port 和 cluster-config

file 的值修改为对应端口号即可。

第四步：启动集群，启动每个文件夹中的 redis 实例，如下：

或自己编写一个 bat 文件，一次启动多个 redis 实例， bat 文件代码如下：

start cmd /k "title redis-6379 & %~dp0\redis-6379\redis-server %~dp0\redis-

6379\redis.windows.conf & exit"

start cmd /k "title redis-6380 & %~dp0\redis-6380\redis-server %~dp0\redis-

6380\redis.windows.conf & exit"

start cmd /k "title redis-6381 & %~dp0\redis-6381\redis-server %~dp0\redis-

6381\redis.windows.conf & exit"

start cmd /k "title redis-6382 & %~dp0\redis-6382\redis-server %~dp0\redis-

6382\redis.windows.conf & exit"

start cmd /k "title redis-6383 & %~dp0\redis-6383\redis-server %~dp0\redis-

6383\redis.windows.conf & exit"

start cmd /k "title redis-6384 & %~dp0\redis-6384\redis-server %~dp0\redis-

6384\redis.windows.conf & exit"

双击“bat”文件，即可启动多个实例：

第五步：组建集群，在任意一个节点下，执行命令如下：

redis-cli.exe --cluster create 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381

127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384 --cluster-replicas 1

第六步：组建 redis 集群时会弹出输入 yes，类似如下：

第七步：在任意节点登录 redis 集群：redis-cli.exe -c -h 127.0.0.1 -p 6379，然后通过

cluster nodes 查看集群中节点状态：

看见如上，则说明集群组建成功。

注意：当集群内一个 Master 以及其对应的 Slave 同时宕机，集群将无法提供服务；当存活的

主节点数小于总节点数的一半时，整个集群就无法提供服务了；

4. Redis 原理

4.1 Redis 事件

redis 事件分为：文件事件和时间事件。

文件事件

Redis 基于 Reactor 模式开发了自己的 网络事件处理器 :这个处理器被称为 文件事件处理器 ( fle

event handler ):

➢ 文件事件处理器使用 IO 多路复用(multiplexing)程序 来同时监听多个套接字，并根据套接

字目前执行的任务来为套接字关联不同的事件处理器。

➢ 当被监听的套接字准备好执行连接应答(accept)、读取(read)、写人(write)、关闭(close)等

操作时，与操作相对应的文件事件就会产生，这时文件事件处 理器就会调用套接字之前关

联好的事件处理器来处理这些事件。

时间事件

redis 的时间事件分为两大类。

➢ 定时事件： 让一段程序在指定的时间之后执行一次。比如说，让程序 X 在当前时间的 30 毫

秒之后执行一次。

➢ 周期性事件： 让一段程序每隔指定时间就执行一次。比如说，让程序 Y 每隔 30 毫秒就执行

一次

4.2 Redis 的架构原理

Redis 组件的系统架构如图所示，主要包括事件处理、数据存储及管理、用于系统扩展的

主从复制/集群管理，以及为插件化功能扩展的 Module System 模块。

事件处理机制

Redis 中的事件处理模块，采用的是作者自己开发的 ae 事件驱动模型，可以进行高效的网

络 IO 读写、命令执行，以及时间事件处理。

其中， 网络 IO 读写处理采用的是 IO 多路复用技术 ，通过对 evport、epoll、kqueue、

select 等进行封装，同时监听多个 socket，并根据 socket 目前执行的任务，来为 socket 关联

不同的事件处理器。

当监听端口对应的 socket 收到连接请求后，就会创建一个 client 结构，通过 client 结构

来对连接状态进行管理。在请求进入时，将请求命令读取缓冲并进行解析，并存入到 client 的

参数列表。

然后根据请求命令找到 对应的 redisCommand ，最后根据命令协议，对请求参数进一步

的解析、校验并执行。Redis 中，时间事件比较简单，目前主要是执行 serverCron，来做一些

统计更新、过期 key 清理、AOF 及 RDB 持久化等辅助操作。

数据管理

redis 的内存数据都存在 redisDB 中。Redis 支持多 DB，每个 DB 都对应一个 redisDB 结

构。Redis 的 8 种数据类型，每种数据类型都采用一种或多种内部数据结构进行存储。同时这

些内部数据结构及数据相关的辅助信息，都以 kye/value 的格式存在 redisDB 中的各个 dict 字

典中。

数据在写入 redisDB 后，这些执行的写指令还会及时追加到 AOF 中，追加的方式是先实

时写入 AOF 缓冲，然后按策略刷缓冲数据到文件。由于 AOF 记录每个写操作，所以一个 key

的大量中间状态也会呈现在 AOF 中，导致 AOF 冗余信息过多，因此 Redis 还设计了一个 RDB

快照操作，可以通过定期将内存里所有的数据快照落地到 RDB 文件，来以最简洁的方式记录

Redis 的所有内存数据。

Redis 进行数据读写的核心处理线程是单线程模型，为了保持整个系统的高性能，必须避

免任何线程导致阻塞的操作。为此，Redis fock 子线程，来处理容易导致阻塞的文件 close、

fsync 等操作，确保系统处理的性能和稳定性。

在 server 端，存储内存永远是昂贵且短缺的，Redis 中，过期的 key 需要及时清理，不活跃的

key 在内存不足时也可能需要进行淘汰。为此，Redis 设计了 8 种淘汰策略，借助新引入的

eviction pool，进行高效的 key 淘汰和内存回收。

4.3 IO 多路复用机制

简单来说，就是。我们的 redis-client 在操作的时候，会产生具有不同事件类型的 socket。

在服务端，有一段 I/0 多路复用程序，将其置入队列之中。然后，IO 事件分派器，依次去队列

中取，转发到不同的事件处理器中。

我自己理解就是：

1、不同用户操作的时候会建立不同的 socket。

2、在服务端，主线程会 folck 出多个子线程，这多个线程会不断的将用户的请求添加到队列中。

所以是多路复用。

3、主线程在从队列中顺序取出请求交给事件处理器进行处理。

4、在这其中，真正对用户进行操作的是主线程，子线程只是负责运输用户请求而已，所以在

redis 处理层面，确实是主线程完成的数据处理。子线程不算在内，所以是 redis 操作是单线程

操作。

4.4 redis 为什么快

➢ Redis 是基于内存的操作，CPU 不是 Redis 的瓶颈

➢ 省去了很多上下文切换线程的时间，不用去考虑各种锁的问题

➢ 多路 I/O 复用：使用了单线程来轮询描述符，减少了线程切换时上下文的切换和竞争

➢ 能带来更好的可维护性，方便开发和调试

4.5 redis 内存回收

4.5.1 内存过期策略

通常有以下三种：

1、 定时过期（主动） ：每个设置过期时间的 key 都需要创建一个定时器，到过期时间就会立即

对 key 进行清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的 CPU 资

源去处理过期的数据，从而影响缓存的响应时间和吞吐量。

2、 惰性过期（被动） ：只有当访问一个 key 时，才会判断该 key 是否已过期，过期则清除。该

策略可以最大化地节省 CPU 资源，却对内存非常不友好。极端情况可能出现大量的过期 key 没

有再次被访问，从而不会被清除，占用大量内存。

3、 定期过期 ：每隔一定的时间，会扫描一定数量的数据库的 expires 字典中一定数量的 key，

并清除其中已过期的 key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和

每次扫描的限定耗时，可以在不同情况下使得 CPU 和内存资源达到最优的平衡效果。

Redis 采用的过期策略：惰性删除 + 定期删除。

如果所有的 key 都没有设置过期属性，redis 内不足了怎么处理？这就是内存淘汰。

4.5.2 数据淘汰策略

数据淘汰策略是指 在 Redis 的用于缓存的内存不足时 ，怎么处理需要新写入且需要申请额外空

间的数据。

➢ volatile 针对设置了 ttl 的 key

➢ allkeys 是针对所有 key

➢ LRU，Least Recently Used 最近最少使用

➢ LFU，Least Frequently Used 最不常用

提供了八种淘汰策略：

分析: 这个问题其实相当重要，到底 redis 有没用到家，这个问题就可以看出来。比如你 redis

只能存 5G 数据，可是你写了 10G，那会删 5G 的数据。怎么删的，这个问题思考过么？还有，

你的数据已经设置了过期时间，但是时间到了，内存占用率还是比较高，有思考过原因么?

redis 采用的是定期删除+惰性删除策略。

为什么不用定时删除策略?

定时删除,用一个定时器来负责监视 key,过期则自动删除。虽然内存及时释放，但是十分消耗

CPU 资源。在大并发请求下，CPU 要将时间应用在处理请求，而不是删除 key,因此没有采用这

一策略.

定期删除+惰性删除是如何工作的呢?

定期删除，redis 默认每个 100ms 检查，是否有过期的 key,有过期 key 则删除。需要说明

的是，redis 不是每个 100ms 将所有的 key 检查一次，而是随机抽取进行检查(如果每隔

100ms,全部 key 进行检查，redis 岂不是卡死)。因此，如果只采用定期删除策略，会导致很多

key 到时间没有删除。

于是，惰性删除派上用场。也就是说在你获取某个 key 的时候，redis 会检查一下，这个

key 如果设置了过期时间那么是否过期了？如果过期了此时就会删除。

采用定期删除+惰性删除就没其他问题了么?

不是的，如果定期删除，没删除 key。然后你也没及时去请求 key，也就是说惰性删除也没

生效。这样，redis 的内存会越来越高。那么就应该采用内存淘汰机制。

在 redis.conf 中有一行配置

# maxmemory-policy allkeys-lru

该配置就是配内存淘汰策略的(什么，你没配过？好好反省一下自己)

1）noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。应该没人用吧。

2） allkeys-lru ：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key。推

荐使用。

3）allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个 key。应该

也没人用吧，你不删最少使用 Key,去随机删。

4）volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最

少使用的 key。这种情况一般是把 redis 既当缓存，又做持久化存储的时候才用。不推荐

5）volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机

移除某个 key。依然不推荐

6）volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期

时间的 key 优先移除。不推荐

ps：如果没有设置 expire 的 key, 不满足先决条件(prerequisites); 那么 volatile-lru,

volatile-random 和 volatile-ttl 策略的行为, 和 noeviction(不删除) 基本上一致。

4.6 持久化流程

1.RDB（默认开启）

按照一定的时间将内存的数据以快照的形式保存到硬盘中，对应产生的数据文件为

dump.rdb；如果系统发生故障，将会丢失最后一次创建快照之后的数据。

save 900 1

save 300 10

save 60 10000

保存流程（BGSAVE）

需要注意的是：

➢ RDB 写入，每次都是全量，在数据量特别大时，服务器负载会比较高

➢ RDB 会在服务器宕机时，丢失几分钟的数据，主要是根据 save 策略来的。

2.AOF

配置文件

appendonly yes

appendfsync everysec

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

重写流程

需要注意的是：

➢ 重写是直接把当前内存的数据生成对应命令，不需要分析老的 AOF 文件；

➢ 恢复数据时，会先判断有没有 AOF，没有的话，在加载 RDB，因为 AOF 文件相对完整；

4.7 常见问题解决方案

1、雪崩

现象： 缓存雪崩是指在我们设置缓存时 采用了相同的过期时间 ，导致缓存在某一时刻同时失效，

请求全部转发到 DB，DB 瞬时压力过重雪崩（由于原有缓存失效，新缓存未到期间）；

解决方案:

(一)给缓存的失效时间，加上一个随机值，避免集体失效。

(二)使用互斥锁，但是该方案吞吐量明显下降了。

(三)双缓存。我们有两个缓存，缓存 A 和缓存 B。缓存 A 的失效时间为 20 分钟，缓存 B 不设失

效时间。自己做缓存预热操作。然后细分以下几个小点

I 从缓存 A 读数据，有则直接返回

II A 没有数据，直接从 B 读数据，直接返回，并且异步启动一个更新线程。

III 更新线程同时更新缓存 A 和缓存 B。

2、穿透

现象： 查询一个一定 不存在的数据 ，由于缓存是不命中时被动写的，并且出于容错考虑，如果

从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，

失去了缓存的意义；

解决方案:

(一)利用互斥锁，缓存失效的时候，先去获得锁，得到锁了，再去请求数据库。没得到锁，则休

眠一段时间重试。

(二)采用异步更新策略，无论 key 是否取到值，都直接返回。value 值中维护一个缓存失效时间，

缓存如果过期，异步起一个线程去读数据库，更新缓存。需要做缓存预热(项目启动前，先加载

缓存)操作。也就是如果一个查询返回的数据为空，我们仍然把这个空结果进行缓存，但它的过

期时间会很短，最长不超过五分钟；

(三) 提供一个能迅速判断请求是否有效的拦截机制 ，比如，利用布隆过滤器，内部维护一系列合

法有效的 key。迅速判断出，请求所携带的 Key 是否合法有效。如果不合法，则直接返回。

3、击穿（热点 Key）

现象： 缓存在某个时间点过期的时候，恰好在这个时间点对这个 Key 有大量的并发请求过来，

这些请求发现缓存过期一般都会从后端 DB 加载数据并回设到缓存，这个时候大并发的请求可

能会瞬间把后端 DB 压垮；

解决方案： 对缓存查询加锁，如果 KEY 不存在，就加锁，然后查 DB 入缓存，然后解锁；其他

进程如果发现有锁就等待，然后等解锁后返回数据或者进入 DB 查询；其实不现实。就是每次

设置 key 的时候，就设置随机的过期时间。

4、如何解决 redis 的并发竞争 key 问题

分析： 这个问题大致就是，同时有多个子系统去 set 一个 key。这个时候要注意什么呢？大家思

考过么。需要说明一下，提前百度了一下，发现答案基本都是推荐用 redis 事务机制。我不推荐

使用 redis 的事务机制。因为我们的生产环境，基本都是 redis 集群环境，做了数据分片操作。

你一个事务中有涉及到多个 key 操作的时候，这多个 key 不一定都存储在同一个 redis-server

上。因此，redis 的事务机制，十分鸡肋。

回答:

如下所示

(1)如果对这个 key 操作，不要求顺序

这种情况下，准备一个分布式锁，大家去抢锁，抢到锁就做 set 操作即可，比较简单。

(2)如果对这个 key 操作，要求顺序

假设有一个 key1,系统 A 需要将 key1 设置为 valueA,系统 B 需要将 key1 设置为 valueB,系统 C

需要将 key1 设置为 valueC.

期望按照 key1 的 value 值按照 valueA-->valueB-->valueC 的顺序变化。这种时候我们在数

据写入数据库的时候，需要保存一个时间戳。假设时间戳如下

系统 A key 1 {valueA 3:00}

系统 B key 1 {valueB 3:05}

系统 C key 1 {valueC 3:10}

那么，假设这会系统 B 先抢到锁，将 key1 设置为{valueB 3:05}。接下来系统 A 抢到锁，

发现自己的 valueA 的时间戳早于缓存中的时间戳，那就不做 set 操作了。以此类推。

其他方法，比如利用队列，将 set 方法变成串行访问也可以。总之，灵活变通。

5、双写一致性问题

第42页 ,共67页

读写过程

1、读：

（1）先读 cache，如果数据命中则返回

（2）如果数据未命中则读 db

（3）将 db 中读取出来的数据入缓存

2、写：

（1）先淘汰 cache

（2）再写 db

5、数据不一致问题

先操作缓存，在写数据库成功之前，如果有读请求发生，可能导致旧数据入缓存，引发数

据不一致。

在分布式环境下，数据的读写都是并发的，上游有多个应用，通过一个服务的多个部署（为

了保证可用性，一定是部署多份的），对同一个数据进行读写，在数据库层面并发的读写并不

能保证完成顺序，也就是说后发出的读请求很可能先完成（读出脏数据）。

上图解析： 写操作先执行 1，删除缓存，再执行 2，更新 db；而读操作先执行 3，读取 cache

数据，未找到数据时执行 4，查询 db。 北大青鸟郴州科泰中心 — 唐际雄

问题所在： 写操作 2 没执行完时，读操作 4 执行了，则读到了脏数据到 cache 中，造成了

cache 和 db 的数据不一致问题。

分析： 一致性问题是分布式常见问题，还可以再分为最终一致性和强一致性。数据库和缓存双

写，就必然会存在不一致的问题。答这个问题，先明白一个前提。就是如果对数据有强一致性

要求，不能放缓存。我们所做的一切，只能保证最终一致性。另外，我们所做的方案其实从根

本上来说，只能说降低不一致发生的概率，无法完全避免。因此， 有强一致性要求的数据，不

能放缓存。

回答：首先，采取正确更新策略，先更新数据库，再删缓存。其次，因为可能存在删除缓存失

败的问题，提供一个补偿措施即可，例如利用消息队列。

解决方案

方案 1：Redis 设置 key 的过期时间。

方案 2：采用延时双删策略。

（1）先淘汰缓存

（2）再写数据库（这两步和原来一样）

（3）休眠 100 毫秒，再次淘汰缓存

这么做，可以将 100 毫秒内所造成的缓存脏数据，再次删除。(为何是 100 毫秒？需要评估自

己的项目的读数据业务逻辑的耗时。这么做的目的，就是确保读请求结束，写请求可以删除读

请求造成的缓存脏数据。当然这种策略还要考虑 redis 和数据库主从同步的耗时。

方案 3：

用阿里的 Canal 框架，监控数据库。

mysql 会将操作记录在 Binary log 日志中，通过 canal 去监听数据库日志二进制文件，解析

log 日志，同步到 redis 中进行增删改操作。

canal 的工作原理： canal 模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向

MySQL master 发送 dump 协议；MySQL master 收到 dump 请求，开始推送 binary log 给

slave (即 canal )；canal 解析 binary log 对象(原始为 byte 流)。

4.8 redis 的事务处理

众所周知，事务是指“一个完整的动作，要么全部执行，要么什么也没有做”。

在聊 redis 事务处理之前，要先和大家介绍四个 redis 指令，即 MULTI、EXEC、DISCARD、

WATCH。这四个指令构成了 redis 事务处理的基础。

1.MULTI 用来组装一个事务；

2.EXEC 用来执行一个事务；

3.DISCARD 用来取消一个事务；

4.WATCH 用来监视一些 key，一旦这些 key 在事务执行之前被改变，则取消事务的执行。

纸上得来终觉浅，我们来看一个 MULTI 和 EXEC 的例子：

redis> MULTI //标记事务开始

OK

redis> INCR user_id //多条命令按顺序入队

QUEUED

redis> INCR user_id

QUEUED

redis> INCR user_id

QUEUED

redis> PING

QUEUED

redis> EXEC //执行

1) (integer) 1

2) (integer) 2

3) (integer) 3

4) PONG

在上面的例子中，我们看到了 QUEUED 的字样，这表示我们在用 MULTI 组装事务时，每

一个命令都会进入到内存队列中缓存起来，如果出现 QUEUED 则表示我们这个命令成功插入了

缓存队列，在将来执行 EXEC 时，这些被 QUEUED 的命令都会被组装成一个事务来执行。

对于事务的执行来说，如果 redis 开启了 AOF 持久化的话，那么一旦事务被成功执行，事

务中的命令就会通过 write 命令一次性写到磁盘中去，如果在向磁盘中写的过程中恰好出现断

电、硬件故障等问题，那么就可能出现只有部分命令进行了 AOF 持久化，这时 AOF 文件就会

出现不完整的情况，这时，我们可以使用 redis-check-aof 工具来修复这一问题，这个工具会将

AOF 文件中不完整的信息移除，确保 AOF 文件完整可用。

有关事务，大家经常会遇到的是两类错误：

1.调用 EXEC 之前的错误

2.调用 EXEC 之后的错误

“调用 EXEC 之前的错误”，有可能是由于语法有误导致的，也可能时由于内存不足导致

的。只要出现某个命令无法成功写入缓冲队列的情况，redis 都会进行记录，在客户端调用

EXEC 时，redis 会拒绝执行这一事务。（这时 2.6.5 版本之后的策略。在 2.6.5 之前的版本中，

redis 会忽略那些入队失败的命令，只执行那些入队成功的命令）。我们来看一个这样的例子：

127.0.0.1:6379> multi

127.0.0.1:6379> haha //一个明显错误的指令

(error) ERR unknown command 'haha'

127.0.0.1:6379> ping

QUEUED

127.0.0.1:6379> exec

//redis 无情的拒绝了事务的执行，原因是“之前出现了错误”

(error) EXECABORT Transaction discarded because of previous errors.

而对于“调用 EXEC 之后的错误”，redis 则采取了完全不同的策略，即 redis 不会理睬这

些错误，而是继续向下执行事务中的其他命令。这是因为，对于应用层面的错误，并不是 redis

自身需要考虑和处理的问题，所以一个事务中如果某一条命令执行失败，并不会影响接下来的

其他命令的执行。我们也来看一个例子：

127.0.0.1:6379> multi

OK

127.0.0.1:6379> set age 23

QUEUED

//age 不是集合，所以如下是一条明显错误的指令

127.0.0.1:6379> sadd age 15

QUEUED

127.0.0.1:6379> set age 29

QUEUED

127.0.0.1:6379> exec //执行事务时，redis 不会理睬第 2 条指令执行错误

1) OK

2) (error) WRONGTYPE Operation against a key holding the wrong kind of value

3) OK

127.0.0.1:6379> get age

"29" //可以看出第 3 条指令被成功执行了

好了，我们来说说最后一个指令“WATCH”，这是一个很好用的指令，它可以帮我们实现

类似于“乐观锁”的效果，即 CAS（check and set）。

WATCH 本身的作用是“监视 key 是否被改动过”，而且支持同时监视多个 key，只要还没

真正触发事务，WATCH 都会尽职尽责的监视，一旦发现某个 key 被修改了，在执行 EXEC 时

就会返回 nil，表示事务无法触发。

127.0.0.1:6379> set age 23

OK

127.0.0.1:6379> watch age //开始监视 age

OK

127.0.0.1:6379> set age 24 //在 EXEC 之前，age 的值被修改了

OK

127.0.0.1:6379> multi

OK

127.0.0.1:6379> set age 25

QUEUED

127.0.0.1:6379> get age

QUEUED

127.0.0.1:6379> exec //触发 EXEC

(nil) //事务无法被执行

5. redis 分布式锁

5.1 什么是分布式锁

分布式锁其实就是， 控制分布式系统不同进程共同访问共享资源的一种锁实现的方式 ，如

果不同的系统或者同一个系统的不同主机之间共享了某个临界资源，往往需要互斥来防止彼此

干扰，以保证一致性

5.2 分布式锁的特征

➢ 互斥性： 任意时刻，只有一个客户端能持有锁

➢ 锁超时释放： 持有锁超时，可以释放，防止不必要的资源浪费，也可以防止死

锁

➢ 可重入性： 可重入锁，也叫做递归锁，指的是在同一线程内，外层函数获得锁

之后，内层递归函数仍然可以获取到该锁。 说白了就是同一个线程再次进入同

样代码时，可以再次拿到该锁。 （作用：防止在同一线程中多次获取锁导致死

锁发生）

➢ 高性能和高可用： 加锁和解锁需要开销尽可能低，同时也要保证高可用，避免

分布式锁失效（高性能：查询快，高可用：节点故障时，服务仍然能正常运行

或进行降级后提供部分服务）

➢ 安全性： 锁只能被持有的用户删除，不能被其他客户端删除

5.3 使用 Redisson 实现分布式锁

Redisson 是架设在 Redis 基础上的一个 Java 驻内存数据网格（In-Memory Data Grid）。

充分的利用了 Redis 键值数据库提供的一系列优势，基于 Java 实用工具包中常用接口，为使用

者提供了一系列具有分布式特性的常用工具类。使得原本作为协调单机多线程并发程序的工具

包获得了 协调分布式多机多线程并发系统的能力 ，大大降低了设计和研发大规模分布式系统的

难度。同时结合各富特色的分布式服务，更进一步简化了分布式环境中程序相互之间的协作。

相对于 Jedis 而言，Redisson 强大的一批。当然了，随之而来的就是它的复杂性。它里面也实现了分布式

锁，而且包含多种类型的锁，更多请参阅 分布式锁和同步器。

在 redis 基础上实现的一个分布式工具集合。在分布式系统下用到的各种各样的工具他都有，

包括分布式锁

Redisson 支持单机模式、主从模式、哨兵模式、集群模式下的分布式锁的实现，只需要通

过配置 redis 节点的主机信息即可。案例如下：

Config config = new Config();

//1.单机模式

config.useSingleServer().setAddress("redis://122.51.172.201");

//2.主从模式

Set<URI> slaveUrls = new HashSet<>();

config.useMasterSlaveServers().setMasterAddress("redis://122.51.172.201").setSlaveAdd

resses(slaveUrls);

//3.哨兵模式

config.useSentinelServers().addSentinelAddress("redis://122.51.172.201").setMasterNa

me("redis://122.51.172.201");

//4.集群模式

config.useClusterServers().addNodeAddress("redis://122.51.172.201",

"redis://122.51.172.201");

5.3.1 看门狗原理

如果负责储存这个分布式锁的 Redisson 节点宕机以后，而且这个锁正好处于锁住的状态

时，这个锁会出现锁死的状态。为了避免这种情况的发生，Redisson 内部提供了一个监控锁的

看门狗，它的作用是在 Redisson 实例被关闭前，不断的延长锁的有效期。

默认情况下，看门狗的检查锁的超时时间是 30 秒钟，也可以通过修改

Config.lockWatchdogTimeout 来另行指定。

如果我们未制定 lock 的超时时间，就使用 30 秒作为看门狗的默认时间。只要占锁成功，

就会启动一个定时任务：每隔 10 秒重新给锁设置过期的时间，过期时间为 30 秒。

当服务器宕机后，因为锁的有效期是 30 秒，所以会在 30 秒内自动解锁。（30 秒等于宕

机之前的锁占用时间+后续锁占用的时间）。

如下图所示：

5.3.2 Redisson 使用步骤

因为 Redisson 非常强大，实现分布式锁的方案非常简洁，所以称作王者方案。

原理图如下：

第一步：添加 Maven 引用

<dependency>

<groupId>org.redisson</groupId>

<artifactId>redisson</artifactId>

<version>3.19.1</version>

</dependency>

第二步：RedisConfig 配置 Redisson import org.redisson.R
edisson;

import org.redisson.api.RedissonClient;

import org.springframework.beans.factory.annotation.Value;

import org.springframework.context.annotation.Bean;

import org.springframework.context.annotation.Configuration;

@Configuration

public class RedissonConfig {

@Value("${spring.redis.host}")

private String redisAddress;

@Bean

public RedissonClient redissonClient(){

// 默认连接地址 127.0.0.1:6379

RedissonClient redisson = Redisson.create();

// Config config = new Config();

// config.useSingleServer().setAddress("redis://" + redisAddress); //redis 服务器地址

// .setDatabase(0) //制定 redis 数据库编号

// .setUsername("").setPassword() // redis 用户名密码

// .setConnectionMinimumIdleSize(10) //连接池最小空闲连接数

// .setConnectionPoolSize(50) //连接池最大线程数

// .setIdleConnectionTimeout(60000) //线程的超时时间

// .setConnectTimeout(6000) //客户端程序获取 redis 链接的超时时间

// .setTimeout(60000) //响应超时时间

// RedissonClient redisson = Redisson.create(config);

// TODO 配置类

// Config config = new Config();

// TODO 添加 Redis 地址，如单点地址（非集群）

// 我没有密码，如果有密码的话可以设.setPassword("")

// 如果是集群的话使用 config.useClusterServers()添加集群地址

// config.useSingleServer().setAddress("redis://127.0.0.1:6379");

// TODO 创建客户端

// return Redisson.create(config);

return redisson;

}

}

第三步：创建 StockRedissonService 类

@Service

public class StockRedissonService {

@Autowired

private StringRedisTemplate redisTemplate;

@Autowired

private RedissonClient redissonClient;

public void deduct() {

RLock rlock = redissonClient.getLock("lock");

rlock.lock();

try{

// 1。 查询库存

String stockStr = redisTemplate.opsForValue().get("stock");

if (!StringUtil.isNullOrEmpty(stockStr)) {

int stock = Integer.parseInt(stockStr);

// 2。 判断条件是否满足

if (stock > 0) {

// 3 更新 redis

redisTemplate.opsForValue().set("stock", String.valueOf(stock - 1));

}

}

}finally {

rlock.unlock();

}

}

}

简单来说，就是直接

RLock rlock = redissonClient.getLock(“lock”);

获取到锁，然后 lock()和 unlock()即可。

第四步：测试

并发达到了 660，比之前自己写的 redis LUA 脚本还要高。

官方文档：如果负责储存这个分布式锁的 Redisson 节点宕机以后，而且这个锁正好处于锁

住的状态时，这个锁会出现锁死的状态。为了避免这种情况的发生，Redisson 内部提供了一个

监控锁的看门狗，它的作用是在 Redisson 实例被关闭前，不断的延长锁的有效期。默认情况下，

看门狗的检查锁的超时时间是 30 秒钟，也可以通过修改 Config.lockWatchdogTimeout 来另

行指定。

不同的是，即使 redisson 节点宕机，它还是可以自动续期，保证你的业务逻辑正常结束。

5.3.3 Redisson 公平锁（ Fair Lock ）

基于 Redis 的 Redisson 分布式可重入公平锁也是实现了 java.util.concurrent.locks.Lock

接口的一种 RLock 对象。同时还提供了 异步(Async) 、 反射式(Reactive) 和 RxJava2 标准的接

口。它保证了当多个 Redisson 客户端线程同时请求加锁时，优先分配给先发出请求的线程。所

有请求线程会在一个队列中排队，当某个线程出现宕机时，Redisson 会等待 5 秒后继续下一个

线程，也就是说如果前面有 5 个线程都处于等待状态，那么后面的线程会等待至少 25 秒。

非公平锁：来个线程就先试试能不能插队，不能插队才去后面排队

公平锁：线程都乖乖去后面排队去，不准插队

5.3.4 公平锁示例

StockController 新增一个接口，用于调用公平锁

@GetMapping("fair/lock/{id}")

public String fairLock(@PathVariable("id")Long id){

stockService.fairLock(id);

return "hello fair lock";

}

StockRedissonService 增加一个获取公平锁的方法

public void fairLock(Long id) {

RLock fairLock = redissonClient.getFairLock("fairLock");

fairLock.lock();

try {

TimeUnit.SECONDS.sleep(3);

System.out.println("----- 测试公平锁 -----");

} catch (InterruptedException e) {

throw new RuntimeException(e);

} finally {

fairLock.unlock();

}

}

测试

访问 http://localhost:10010/fair/lock/1 从 1 一直访问到 5 北大青鸟郴州科泰中心 — 唐际雄

redis 中有个等待队列

访问是顺序执行。

那如果把公平锁修改为非公平锁呢？

RLock fairLock = redissonClient.getLock("fairLock");

重新测试：

redis 中并无等待队列

锁访问顺序也并不是先进先出。

5.3.5 Redisson 读写锁

写锁是一个排他锁（互斥锁），读锁是一个共享锁。

➢ 读锁 + 读锁：相当于没加锁，可以并发读。

➢ 读锁 + 写锁：写锁需要等待读锁释放锁。

➢ 写锁 + 写锁：互斥，需要等待对方的锁释放。

➢ 写锁 + 读锁：读锁需要等待写锁释放。

StockController

@GetMapping("read/lock")

public String readLock(){

stockService.readLock();

return "read read lock";

}

@GetMapping("write/lock")

public String writeLock(){

stockService.writeLock();

return "write write lock";

}

StockRedissonService

public void readLock() {

RReadWriteLock lock = redissonClient.getReadWriteLock("rwLock");

lock.readLock().lock(10, TimeUnit.SECONDS);

// TODO 疯狂的读

// lock.readLock().unlock();

}

public void writeLock() {

RReadWriteLock lock = redissonClient.getReadWriteLock("rwLock");

lock.writeLock().lock(10, TimeUnit.SECONDS);

// TODO 疯狂的写

// lock.writeLock().unlock();

}

简单测试下，两个页面分别访问

http://localhost:10010/write/lock 写操作

http://localhost:10010/read/lock 读操作

写写： 多次写操作明显等待

写读：明显等待

读写：明显等待

读锁有多个，但写锁只有一个

读读：无等待现象

5.4 Redisson 的 RSemaphore 信号量

关于信号量的使用大家可以想象一下这个场景，有三个停车位，当三个停车位满了后，其

他车就不停了。可以把车位比作信号，现在有三个信号，停一次车，用掉一个信号，车离开就

是释放一个信号。

1. Semaphore:

➢ 可以用来控制同时访问特定资源的线程数量，常用于限流场景。

➢ Semaphore 接收一个 int 整型值，表示 许可证数量。

➢ 线程通过调用 acquire()获取许可证，执行完成之后通过调用 release()归还许可证。

➢ 只有获取到许可证的线程才能运行，获取不到许可证的线程将会阻塞。

public static void main(String[] args) {

Semaphore semaphore = new Semaphore(3);

for (int i = 0; i < 6; i++) {

new Thread(()->{

try {

semaphore.acquire();

System.out.println(Thread.currentThread().getName() + ":抢到了停车位");

TimeUnit.SECONDS.sleep(new Random().nextInt(10));

System.out.println(Thread.currentThread().getName() + "停了会儿就开走了

");

semaphore.release();

} catch (InterruptedException e) {

throw new RuntimeException(e);

}

}, i + "号车").start();

}

}

每次只会停三辆车，走一辆后才可以停下一辆，完美实现限流。

2. RSemaphore：实现分布式限流

StockRedissonService

public void semaphoreLock() {

RSemaphore semaphore = redissonClient.getSemaphore("semaphore");

semaphore.trySetPermits(3); // 设置资源量，限流的线程数

try {

semaphore.acquire(); // 获取资源，获取资源成功的线程可以继续处理业务操作，否则会被阻塞住

redisTemplate.opsForList().rightPush("log",port + " 端口获取了资源，开始处理业务逻辑 " +

Thread.currentThread().getName());

TimeUnit.SECONDS.sleep(new Random().nextInt(10));

redisTemplate.opsForList().rightPush("log",port + " 端口处理完，释放了资源 " +

Thread.currentThread().getName());

semaphore.release(); // 手动释放资源，后续请求线程可以获取该资源

} catch (InterruptedException e) {

throw new RuntimeException(e);

}

}

用 redis 的 list 数据类型来记录日志，方便集群部署的日志查看。

注意：

semaphore.trySetPermits(3);// 设置资源量，限流的线程数

这会在 redis 中成 semaphore 的 key ，如果要修改资源量，必须手动把 redis 中该 key 删除，否则只在代

码中修改，重启后无法生效。

简单测试下，多次访问后

集群部署下，共用了信号量的限流，两个端口启动，同一时间限流了 3 个线程。

5.5 Redisson 的 RCountDownLatch

1. CountDownLatch:允许一个或者多个线程去等待其他线程完成操作。

➢ CountDownLatch 接收一个 int 型参数，表示要等待的工作线程的个数。

➢ await(): 使当前线程进入同步队列进行等待，直到 latch 的值被减到 0 或者当前线程被中断，

当前线程就会被唤醒。

➢ countDown(): 使 latch 的值减 1，如果减到了 0，则会唤醒所有等待在这个 latch 上的线

程。

public static void main(String[] args) throws InterruptedException { // 班长线程

CountDownLatch countDownLatch = new CountDownLatch(6);

for (int i = 0; i < 6; i++) {

new Thread(() -> {

System.out.println(Thread.currentThread().getName() + "准备出门了");

try {

TimeUnit.SECONDS.sleep(10);

} catch (InterruptedException e) {

throw new RuntimeException(e);

}

System.out.println(Thread.currentThread().getName() + "睡了一会，终于出门了

");

countDownLatch.countDown();

}, i + "号同学" ).start();

}

countDownLatch.await();

System.out.println("班长锁门了");

}

班长等六个同学全部出门后才可以锁门

2. RCountDownLatch

StockController

@GetMapping("test/countDown")

public String countDown(){

stockService.countDown();

return "出来了一位同学";

}

@GetMapping("test/latch")

public String testLatch(){

stockService.testLatch();

return "班长锁门了";

}

countDown 同学出门

public void countDown() {

RCountDownLatch cdl = redissonClient.getCountDownLatch("cdl");

// TODO 出门准备完成

cdl.countDown();

}

latch 等六位同学出门后，班长锁门

public void testLatch() {

RCountDownLatch cdl = redissonClient.getCountDownLatch("cdl");

cdl.trySetCount(6);

try {

cdl.await();

} catch (InterruptedException e) {

throw new RuntimeException(e);

}

// TODO 准备锁门

}

RCountDownLatch cdl = redissonClient.getCountDownLatch("cdl");

其中的 “cdl" 即是存放在 redis 的 key ，两个方法必须命名一致。

分别访问接口

http://localhost/test/countDown 出门

http://localhost/test/latch 班长锁门

只有访问六次出门后，才可以成功锁门

redis 中存放着 cdl 的 key ，也就是目前的等待线程数。

5.6 Redisson 总结

redisson: redis 的 java 客户端，分布式锁

玩法：

➢ 引入依赖

➢ java 配置类：RedissonConfig

➢ 代码使用

可重入锁 RLock 对象: CompletableFuture + LUA 脚本 + hash

RLock rlock = redissonClient.getLock("xxx");

rlock.lock()/unlock()

公平锁：

RLock fairLock = redissonClient.getLock("xxx");

fairLock.lock()/unlock()

联锁 和 红锁

读写锁：

RReadWriteLock lock = redissonClient.getReadWriteLock("xxx");

lock.readLock().lock()/unlock();

lock.writeLock().lock()/unlock();

信号量：

RSemaphore semaphore = redissonClient.getSemaphore("xxx");

semaphore.trySetPermits(3); //设置资源量，限流的线程数

semaphore.acquire()/release()

闭锁：

RCountDownLatch cdl = redissonClient.getCountDownLatch("xxx");

cdl.trySetCount(6);

cdl.await()/countDown()

5.7 Redisson 底层原理

只要线程一加锁成功，就会启动一个 watch dog 看门狗，它是一个后台线程，会每隔 10 秒检

查一下，如果线程 1 还持有锁，那么就会不断的延长锁 key 的生存时间。因此，Redisson 就是

使用 Redisson 解决了死锁「锁过期释放，业务没执行完」死锁问题。

6. redis 面试题

6.1 数据类型以及使用场景

1、String

这个其实没啥好说的，最常规的 set/get 操作，value 可以是 String 也可以是数字。一般做一

些复杂的计数功能的缓存。

2、list

使用 List 的数据结构，可以做简单的消息队列的功能。另外还有一个就是，可以利用 lrange 命

令，做基于 redis 的分页功能，性能极佳，用户体验好。

3、set

因为 set 堆放的是一堆不重复值的集合。所以可以做 全局去重 的功能。为什么不用 JVM 自带的

Set 进行去重？因为我们的系统一般都是集群部署，使用 JVM 自带的 Set，比较麻烦，难道为

了一个做一个全局去重，再起一个公共服务，太麻烦了。

另外，就是利用交集、并集、差集等操作

4、sorted set

sorted set 多了一个权重参数 score,集合中的元素能够按 score 进行排列。可以做 排行榜应用 ，

取 TOP N 操作。另外，参照另一篇《分布式之延时任务方案解析》，该文指出了 sorted set

可以用来做延时任务。最后一个应用就是可以做范围查找。

5、hash

这里 value 存放的是结构化的对象，比较方便的就是操作其中的某个字段。我在做 单点登录 的

时候，就是用这种数据结构存储用户信息，以 cookieId 作为 key，设置 30 分钟为缓存过期时

间，能很好的模拟出类似 session 的效果。

6.2 使用过 Redis 分布式锁么，它是怎么实现的？

先拿 setnx 来争抢锁，抢到之后，再用 expire 给锁加一个过期时间防止锁忘记了释放。

6.3 什么是缓存穿透？如何避免？什么是缓存雪崩？何如避

免？

缓存穿透

一般的缓存系统，都是按照 key 去缓存查询，如果不存在对应的 value，就应该去后端系统查

找（比如 DB）。 一些恶意的请求会故意查询不存在的 key,请求量很大，就会对后端系统造成

很大的压力 。这就叫做缓存穿透。

如何避免？

1：对查询结果为空的情况也进行缓存，缓存时间设置短一点，或者该 key 对应的数据 insert

了之后清理缓存。

2：对一定不存在的 key 进行过滤。可以把所有的可能存在的 key 放到一个大的 Bitmap(布隆过

滤器)中，查询时通过该 bitmap(布隆过滤器)过滤。

缓存雪崩

当缓存服务器重启或者 大量缓存集中在某一个时间段失效 ，这样在失效的时候，会给后端系统

带来很大压力。导致系统崩溃。

如何避免？

1：在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个 key 只允

许一个线程查询数据和写缓存，其他线程等待。

2：做二级缓存，A1 为原始缓存，A2 为拷贝缓存，A1 失效时，可以访问 A2，A1 缓存失效时

间设置为短期，A2 设置为长期

3：不同的 key，设置不同的过期时间，让缓存失效的时间点尽量均匀。

6.4 Redis 的用途是什么？

➢ 计数器 可以对 String 进行自增自减运算，从而实现计数器功能。Redis 这种内存型数据库

的读写性能非常高，很适合存储频繁读写的计数量。

➢ 缓存 将热点数据放到内存中，设置内存的最大使用量以及淘汰策略来保证缓存的命中率。

➢ 会话缓存 可以使用 Redis 来统一存储多台应用服务器的会话信息。当应用服务器不再存储

用户的会话信息，也就不再具有状态，一个用户可以请求任意一个应用服务器，从而更容

易实现高可用性以及可伸缩性。

➢ 全页缓存（FPC） 除基本的会话 token 之外，Redis 还提供很简便的 FPC 平台。以

Magento 为例，Magento 提供一个插件来使用 Redis 作为全页缓存后端。此外，对

WordPress 的用户来说，Pantheon 有一个非常好的插件 wp-redis，这个插件能帮助你以

最快速度加载你曾浏览过的页面。

➢ 查找表 例如 DNS 记录就很适合使用 Redis 进行存储。查找表和缓存类似，也是利用了

Redis 快速的查找特性。但是查找表的内容不能失效，而缓存的内容可以失效，因为缓存不

作为可靠的数据来源。

➢ 消息队列(发布/订阅功能) List 是一个双向链表，可以通过 lpush 和 rpop 写入和读取消息。

不过最好使用 Kafka、RabbitMQ 等消息中间件。

➢ 分布式锁实现 在分布式场景下，无法使用单机环境下的锁来对多个节点上的进程进行同步。

可以使用 Redis 自带的 SETNX 命令实现分布式锁，除此之外，还可以使用官方提供的

RedLock 分布式锁实现。

➢ 其它 Set 可以实现交集、并集等操作 ，从而 实现共同好友 等功能。ZSet 可以实现有序性操

作，从而 实现排行榜 等功能。

6.5 Redis 的主要特点是什么？

➢ 读写性能优异， Redis 能读的速度是 110000 次/s，写的速度是 81000 次/s。

➢ 支持数据持久化，支持 AOF 和 RDB 两种持久化方式。

➢ 支持事务，Redis 的所有操作都是原子性的，同时 Redis 还支持对几个操作合并后的原子

性执行。

➢ 数据结构丰富，除了支持 string 类型的 value 外还支持 hash、set、zset、list 等数据结

构。

➢ 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。

6.6 解释 Redis 的复制功能？

Redis 可以使用主从同步，从从同步。第一次同步时，主节点做一次 bgsave，并同时将后

续修改操作记录到内存 buffer，待完成后将 rdb 文件全量同步到复制节点，复制节点接受完成

后将 rdb 镜像加载到内存。加载完成后，再通知主节点将期间修改的操作记录同步到复制节点

进行重放就完成了同步过程。

6.7 Redis 和 RDBMS 有什么区别？

➢ Redis 是 NoSQL 数据库，而 RDBMS 是 SQL 数据库。

➢ Redis 遵循键值结构，而 RDBMS 遵循表结构。

➢ Redis 非常快，而 RDBMS 相对较慢。

➢ Redis 将所有数据集存储在主存储器中，而 RDBMS 将其数据集存储在辅助存储器中。

➢ Redis 通常用于存储小型和常用文件，而 RDBMS 用于存储大文件。

➢ Redis 仅为 Linux，BSD，Mac OS X，Solaris 提供官方支持。它目前没有为 Windows 提

供官方支持，而 RDBMS 提供对两者的支持。

6.8 为什么 Redis 不同于其他的键值存储数据库

➢ Redis 发展方向不同与其他键值数据库，它能包含很多复杂数据类型，对这些数据类型操作

都是原子的。Redis 数据类型与基本数据结构强相关，直接暴露给程序员，没有增加抽象层。

➢ Redis 是一个基于内存的，能够持久化到硬盘的数据库，因此为了实现高速读写，数据集大

小不能超过内存。内存数据库另一个优点是，内存数据库相对于硬盘数据库非常容易操作

复杂数据结构，因此 Redis 的可以做很多事情，内部复杂性低。与此同时两款磁盘存储格

式（RDB 和 AOF）不需要支持随机访问，因此他们是紧凑的，而且总是以追加形式生成

（甚至 AOF 日志轮换也是一个追加操作，因为新版本是由内存中的副本生成）。比起基于

磁盘的数据存储， Redis 用来处理重要数据时需要确保数据集及时落盘刷新。

6.9 Redis 为什么是单线程的？

1. 代码更清晰，处理逻辑更简单；

2. 不用考虑各种锁的问题，不存在加锁和释放锁的操作，没有因为可能出现死锁而导致的性

能问题；

3. 不存在多线程切换而消耗 CPU；

4. 无法发挥多核 CPU 的优势，但可以采用多开几个 Redis 实例来完善

6.10 Redis 真的是单线程的吗？

Redis6.0 之前是单线程的，Redis6.0 之后开始支持多线程；

redis 内部使用了基于 epoll 的多路服用，也可以多部署几个 redis 服务器解决单线程的问题；

redis 主要的性能瓶颈是内存和网络；

内存好说，加内存条就行了，而网络才是大麻烦，所以 redis6 内存好说，加内存条就行了；

而网络才是大麻烦，所以 redis6.0 引入了多线程的概念，

redis6.0 在网络 IO 处理方面引入了多线程，如网络数据的读写和协议解析等，需要注意的是，

执行命令的核心模块还是单线程的。

6.11 Redis 持久化有几种方式？

edis 提供了两种持久化的方式，分别是 RDB（Redis DataBase）和 AOF（Append Only

File） 。

RDB，简而言之，就是在不同的时间点，将 redis 存储的数据生成快照并存储到磁盘等介质上；

AOF，则是换了一个角度来实现持久化，那就是将 redis 执行过的所有写指令记录下来，在下次

redis 重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。

其实 RDB 和 AOF 两种方式也可以同时使用，在这种情况下，如果 redis 重启的话，则会优先

采用 AOF 方式来进行数据恢复，这是因为 AOF 方式的数据恢复完整度更高。

如果你没有数据持久化的需求，也完全可以关闭 RDB 和 AOF 方式，这样的话，redis 将变成一

个纯内存数据库，就像 memcache 一样。

6.12 Redis 和 memecache 有什么区别？

1、Redis 相比 memecache，拥有更多的数据结构和支持更丰富的数据操作。

（1）Redis 支持 key-value，常用的数据类型主要有 String、Hash、List、Set、Sorted Set。

（2）memecache 只支持 key-value。

2、内存使用率对比，Redis 采用 hash 结构来做 key-value 存储，由于其组合式的压缩，其内

存利用率会高于 memecache。

3、性能对比：Redis 只使用单核，memecache 使用多核。

4、Redis 支持磁盘持久化，memecache 不支持。

Redis 可以将一些很久没用到的 value 通过 swap 方法交换到磁盘。

5、Redis 支持分布式集群，memecache 不支持。

第64页 ,共67页 北大青鸟郴州科泰中心 — 唐际雄

6.13 Redis 支持的 java 客户端都有哪些？

Redisson、Jedis、lettuce 等等，官方推荐使用 Redisson。

6.14 jedis 和 redisson 有哪些区别？

Jedis 和 Redisson 都是 Java 中对 Redis 操作的封装。Jedis 只是简单的封装了 Redis 的 API

库，可以看作是 Redis 客户端，它的方法和 Redis 的命令很类似。Redisson 不仅封装了 redis ，

还封装了对更多数据结构的支持，以及锁等功能，相比于 Jedis 更加大。但 Jedis 相比于

Redisson 更原生一些，更灵活。

6.15 什么是缓存穿透？怎么解决？

1、缓存穿透

一般的缓存系统，都是按照 key 去缓存查询，如果不存在对用的 value，就应该去后端系统查

找（比如 DB 数据库）。一些恶意的请求会故意查询不存在的 key，请求量很大，就会对后端系

统造成很大的压力。这就叫做缓存穿透。

2、怎么解决？

对查询结果为空的情况也进行缓存，缓存时间设置短一点，或者该 key 对应的数据 insert 之后

清理缓存。

对一定不存在的 key 进行过滤。可以把所有的可能存在的 key 放到一个大的 Bitmap 中，查询

时通过该 Bitmap 过滤。

3、缓存雪崩

当缓存服务器重启或者大量缓存集中在某一时间段失效，这样在失效的时候，会给后端系统带

来很大的压力，导致系统崩溃。

4、如何解决？

1）在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个 key 只允

许一个线程查询数据和写缓存，其它线程等待；

2）做二级缓存；

3）不同的 key，设置不同的过期时间，让缓存失效的时间尽量均匀；

6.16 怎么保证缓存和数据库数据的一致性？

1、淘汰缓存

数据如果为较为复杂的数据时，进行缓存的更新操作就会变得异常复杂，因此一般推荐选择淘

汰缓存，而不是更新缓存。

2、选择先淘汰缓存，再更新数据库

假如先更新数据库，再淘汰缓存，如果淘汰缓存失败，那么后面的请求都会得到脏数据，直至

缓存过期。

假如先淘汰缓存再更新数据库，如果更新数据库失败，只会产生一次缓存穿透，相比较而言，

后者对业务则没有本质上的影响。

3、延时双删策略

如下场景：同时有一个请求 A 进行更新操作，另一个请求 B 进行查询操作。

1. 请求 A 进行写操作，删除缓存

2. 请求 B 查询发现缓存不存在

3. 请求 B 去数据库查询得到旧值

4. 请求 B 将旧值写入缓存

5. 请求 A 将新值写入数据库

如此便出现了数据不一致问题。采用延时双删策略得以解决。

public void write(String key,Object data){

redisUtils.del(key);

db.update(data);

Thread.Sleep(100);

redisUtils.del(key);

}

这么做，可以将 1 秒内所造成的缓存脏数据，再次删除。这个时间设定可根据业务场景进行一

个调节。

4、数据库读写分离的场景

两个请求，一个请求 A 进行更新操作，另一个请求 B 进行查询操作。

1) 请求 A 进行写操作，删除缓存

2) 请求 A 将数据写入数据库了，

3) 请求 B 查询缓存发现，缓存没有值

4) 请求 B 去从库查询，这时，还没有完成主从同步，因此查询到的是旧值

5) 请求 B 将旧值写入缓存

6) 数据库完成主从同步，从库变为新值

依旧采用延时双删策略解决此问题。

6.17 Redis ，什么是缓存穿透？怎么解决？

1、缓存穿透

一般的缓存系统，都是按照 key 去缓存查询，如果不存在对用的 value，就应该去后端系统查

找（比如 DB 数据库）。一些恶意的请求会故意查询不存在的 key，请求量很大，就会对后端系

统造成很大的压力。这就叫做缓存穿透。

2、怎么解决？

对查询结果为空的情况也进行缓存，缓存时间设置短一点，或者该 key 对应的数据 insert 之后

清理缓存。

对一定不存在的 key 进行过滤。可以把所有的可能存在的 key 放到一个大的 Bitmap 中，查询

时通过该 Bitmap 过滤。

3、缓存雪崩

当缓存服务器重启或者大量缓存集中在某一时间段失效，这样在失效的时候，会给后端系统带

来很大的压力，导致系统崩溃。

4、如何解决？

1. 在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个 key 只

允许一个线程查询数据和写缓存，其它线程等待；

2. 做二级缓存；

3. 不同的 key，设置不同的过期时间，让缓存失效的时间尽量均匀；

6.18 Redis 分布式锁有什么缺陷？

Redis 分布式锁不能解决超时的问题，分布式锁有一个超时时间，程序的执行如果超出了锁的

超时时间就会出现问题。

Redis 容易产生的几个问题：

1. 锁未被释放

2. B 锁被 A 锁释放了

3. 数据库事务超时

4. 锁过期了，业务还没执行完

5. Redis 主从复制的问题

6.19 Redis 如何做内存优化？

1、缩短键值的长度

缩短值的长度才是关键，如果值是一个大的业务对象，可以将对象序列化成二进制数组；

首先应该在业务上进行精简，去掉不必要的属性，避免存储一些没用的数据；

其次是序列化的工具选择上，应该选择更高效的序列化工具来降低字节数组大小；

以 JAVA 为例，内置的序列化方式无论从速度还是压缩比都不尽如人意，这时可以选择更高效的

序列化工具，如: protostuff，kryo 等

2、共享对象池

对象共享池指 Redis 内部维护[0-9999]的整数对象池。创建大量的整数类型 redisObject 存在

内存开销，每个 redisObject 内部结构至少占 16 字节，甚至超过了整数自身空间消耗。所以

Redis 内存维护一个[0-9999]的整数对象池，用于节约内存。 除了整数值对象，其他类型如

list,hash,set,zset 内部元素也可以使用整数对象池。因此开发中在满足需求的前提下，尽量使

用整数对象以节省内存。

3、字符串优化

4、编码优化

5、控制 key 的数量