Redis

1、安装

https://registry.hub.docker.com/_/redis

  1. 准备 redis.conf

从官网下载redis.conf文件，点击超链接下载

redis官网：https://redis.io/

进入官网，直接下载 redis-xxx.tar.gz，然后解压也可以得到redis.conf

将redis.conf放在本地的一个目录,比如: D:/redis. 并对文件做一下修改:

1
2
3
4
5
6
7
8
bind 127.0.0.1 #注释掉这部分，这是限制redis只能本地访问
protected-mode no #默认yes，开启保护模式，限制为本地访问
daemonize no#默认no，改为yes意为以守护进程方式启动，可后台运行，除非kill进程，改为yes会使配置文件方式启动redis失败
databases 16 #数据库个数（可选），我修改了这个只是查看是否生效。。
dir  ./ #输入本地redis数据库存放文件夹（可选）
appendonly yes #redis持久化（可选）
requirepass  密码 #配置redis访问密码

  1. 拉取镜像
1
2
3
docker search redis
docker pull redis
docker images
  1. 在D:/redis目录下面新建data目录,用于存储redis数据
  2. 启动redis镜像(配置和数据映射到本地)
1
docker run -dit --name redis-server -p 6379:6379 -v D:\Software\Redis\conf:/etc/redis -v D:\Software\Redis\data:/data redis:latest redis-server /etc/redis/redis.conf --appendonly yes --requirepass "123456"

ps: 上面的命令里面,第一个-v是将redis.conf映射到docker的redis配置,第二个-v是将redis存储数据做映射.这里:前面的路径都是本地的路径,不要弄错了

redis-server /etc/redis/redis.conf：指定容器启动时执行的命令

–appendonly yes 开启数据持久化,

–requirepass “123456” 指定密码

这些配置回被记录在容器内部docker inspect 容器名查看

实验发现, 如果在配置文件修改这些配置，重启redis后依然不会生效，只有在启动时不加这些参数，才会有效

  1. 查看
1
2
3
docker ps
docker exec -it redis-server /bin/bash
redis-cli -a 123456

2、配置

Redis 的配置文件位于 Redis 安装目录下，文件名为 redis.conf(Windows 名为 redis.windows.conf)。

你可以通过 CONFIG 命令查看或设置配置项。

语法

Redis CONFIG 命令格式如下：

1
redis 127.0.0.1:6379> CONFIG GET CONFIG_SETTING_NAME

使用 ***** 号获取所有配置项：

编辑配置

你可以通过修改 redis.conf 文件或使用 CONFIG set 命令来修改配置。

语法

CONFIG SET 命令基本语法：

1
redis 127.0.0.1:6379> CONFIG SET CONFIG_SETTING_NAME NEW_CONFIG_VALUE

参数说明

redis.conf 配置项说明如下：

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

3、常用五大数据类型

redis常见数据类型操作命令http://www.redis.cn/commands.html

Redis 数据库支持五种数据类型。

  • 字符串（string）
  • 哈希（hash）
  • 列表（list）
  • 集合（set）
  • 有序集合（sorted set）
  • 位图 ( Bitmaps )
  • 基数统计 ( HyperLogLogs )

2.1命令

要在 redis 服务上执行命令需要一个 redis 客户端。Redis 客户端在我们之前下载的的 redis 的安装包中。

语法

Redis 客户端的基本语法为：

1
$ redis-cli

实例

以下实例讲解了如何启动 redis 客户端：

启动 redis 服务器，打开终端并输入命令 redis-cli，该命令会连接本地的 redis 服务。

1
2
3
4
5
$ redis-cli
redis 127.0.0.1:6379>
redis 127.0.0.1:6379> PING

PONG

在以上实例中我们连接到本地的 redis 服务并执行 PING 命令，该命令用于检测 redis 服务是否启动。

在远程服务上执行命令

如果需要在远程 redis 服务上执行命令，同样我们使用的也是 redis-cli 命令。

语法

1
$ redis-cli -h host -p port -a password

实例

以下实例演示了如何连接到主机为 127.0.0.1，端口为 6379 ，密码为 mypass 的 redis 服务上。

1
2
3
4
5
$redis-cli -h 127.0.0.1 -p 6379 -a "mypass"
redis 127.0.0.1:6379>
redis 127.0.0.1:6379> PING

PONG

2.2键

  • keys * 查看当前库所有key
  • exists key 判断某个key是否存在
  • type key 查看key是什么类型
  • del key 删除指定的key数据
  • unlink key 删除指定的key，该命令会执行命令之外的线程中执行实际的内存回收，因此它不是阻塞，而 DEL 是阻塞的，仅将keys从keyspace元数据中删除，真正的删除会在后续异步操作。
  • expire key 10 10s 为给定的key设置国企时间
  • ttl key 查看还有多少秒过期，-1表示永久不过期，-2表示已过期，默认是容不过期

2.1字符串

string 是 redis 最基本的类型，你可以理解成与 Memcached 一模一样的类型，一个 key 对应一个 value。

string 类型是二进制安全的。意思是 redis 的 string 可以包含任何数据。比如jpg图片或者序列化的对象。

string 类型是 Redis 最基本的数据类型，string 类型的值最大能存储 512MB。动态扩容

常用命令

下表列出了常用的 redis 字符串命令：

序号 命令及描述
1 SET key value 设置指定 key 的值。
2 GET key 获取指定 key 的值。
3 MSET key value [key value …] 同时设置一个或多个 key-value 对。
4 MGET key1 [key2..] 获取所有(一个或多个)给定 key 的值。
5 STRLEN key 返回 key 所储存的字符串值的长度。
6 INCR key 将 key 中储存的数字值增一。
7 DECR key 将 key 中储存的数字值减一。
8 INCRBY key increment 将 key 所储存的值加上给定的增量值（increment） 。
9 DECRBY key decrement key 所储存的值减去给定的减量值（decrement） 。
10 GETSET key value 将给定 key 的值设为 value ，并返回 key 的旧值(old value)。
11 SETBIT key offset value 对 key 所储存的字符串值，设置或清除指定偏移量上的位(bit)。这两个在bitmap中使用
12 GETBIT key offset 对 key 所储存的字符串值，获取指定偏移量上的位(bit)。
13 SETEX key seconds value 将值 value 关联到 key ，并将 key 的过期时间设为 seconds (以秒为单位)。
14 SETNX key value 只有在 key 不存在时设置 key 的值。
15 SETRANGE key offset value 用 value 参数覆写给定 key 所储存的字符串值，从偏移量 offset 开始。（索引从0****开始)
16 GETRANGE key start end 返回 key 中字符串值的子字符，左闭右闭
17 MSETNX key value [key value …] 同时设置一个或多个 key-value 对，当且仅当所有给定 key 都不存在。原子性，有一个失败则都失败
18 APPEND key value 如果 key 已经存在并且是一个字符串， APPEND 命令将指定的 value 追加到该 key 原来值（value）的末尾。
19 PSETEX key milliseconds value 这个命令和 SETEX 命令相似，但它以毫秒为单位设置 key 的生存时间，而不是像 SETEX 命令那样，以秒为单位。
20 INCRBYFLOAT key increment 将 key 所储存的值加上给定的浮点增量值（increment） 。

应用场景：

缓存对象

使用 String 来缓存对象有两种方式：

  • 直接缓存整个对象的 JSON，命令例子： SET user:1 '{"name":"xiaolin", "age":18}'。
  • 采用将 key 进行分离为 user:ID:属性，采用 MSET 存储，用 MGET 获取各属性值，命令例子： MSET user:1:name xiaolin user:1:age 18 user:2:name xiaomei user:2:age 20。

常规计数

分布式锁

SET 命令有个 NX 参数可以实现「key不存在才插入」，可以用它来实现分布式锁：

  • 如果 key 不存在，则显示插入成功，可以用来表示加锁成功；
  • 如果 key 存在，则会显示插入失败，可以用来表示加锁失败。

一般而言，还会对分布式锁加上过期时间，分布式锁的命令如下：

1
SET lock_key unique_value NX PX 10000
  • lock_key 就是 key 键；
  • unique_value 是客户端生成的唯一的标识；
  • NX 代表只在 lock_key 不存在时，才对 lock_key 进行设置操作；
  • PX 10000 表示设置 lock_key 的过期时间为 10s，这是为了避免客户端发生异常而无法释放锁。

而解锁的过程就是将 lock_key 键删除，但不能乱删，要保证执行操作的客户端就是加锁的客户端。所以，解锁的时候，我们要先判断锁的 unique_value 是否为加锁客户端，是的话，才将 lock_key 键删除。

可以看到，解锁是有两个操作，这时就需要 Lua 脚本来保证解锁的原子性，因为 Redis 在执行 Lua 脚本时，可以以原子性的方式执行，保证了锁释放操作的原子性。

1
2
3
4
5
6
// 释放锁时，先比较 unique_value 是否相等，避免锁的误释放
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

这样一来，就通过使用 SET 命令和 Lua 脚本在 Redis 单节点上完成了分布式锁的加锁和解锁。

2.2Hash

Redis hash 是一个键值(key=>value)对集合。

Redis hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象。

常用命令

序号 命令及描述
1 HSET key field value 将哈希表 key 中的字段 field 的值设为 value 。
2 HGET key field 获取存储在哈希表中指定字段的值。
3 HMSET key field1 value1 field2 value2 同时将多个 field-value (域-值)对设置到哈希表 key 中。
4 HMGET key field1 field2 获取所有给定字段的值
5 HEXISTS key field 查看哈希表 key 中，指定的字段是否存在。
6 HKEYS key 获取所有哈希表中的字段
7 HVALS key 获取哈希表中所有值。
8 HINCRBY key field increment 为哈希表 key 中的指定字段的整数值加上增量 increment 。
9 HSETNX key field value 只有在字段 field 不存在时，设置哈希表字段的值。
10 HDEL key field1 field2 删除一个或多个哈希表字段
11 HGETALL key 获取在哈希表中指定 key 的所有字段和值
12 HINCRBYFLOAT key field increment 为哈希表 key 中的指定字段的浮点数值加上增量 increment 。
13 HLEN key 获取哈希表中字段的数量
14 [HSCAN key cursor MATCH pattern] [COUNT count] 迭代哈希表中的键值对。 
1
2
3
4
5
6
7
8
9
HMSET user:1 username ajeet password javatpoint alexa 2000  
OK  
HGETALL  user:1  
"username"  
"ajeet"  
"password"  
"javatpoint"  
"alexa"  
"2000"

这里，HMSET 和 HGETALL 是 Redis 的命令，而 user:1 是键。

每个哈希可以存储多达 2^32^-1个字段-值对（40多亿）。

数据结构

Hash 类型的底层数据结构是由压缩列表或哈希表实现的：

  • 如果哈希类型元素个数小于 512 个（默认值，可由 hash-max-ziplist-entries 配置），所有值小于 64 字节（默认值，可由 hash-max-ziplist-value 配置）的话，Redis 会使用压缩列表作为 Hash 类型的底层数据结构；
  • 如果哈希类型元素不满足上面条件，Redis 会使用哈希表作为 Hash 类型的 底层数据结构。

在 Redis 7.0 中，压缩列表数据结构已经废弃了，交由 listpack 数据结构来实现了。

2.3列表list

Redis 列表定义为字符串列表，按插入顺序排序。可以将元素添加到 Redis 列表的头部或尾部。

列表的最大长度为 2^32 - 1，也即每个列表支持超过 40 亿个元素。

1
2
3
4
5
6
7
8
9
10
11
redis 127.0.0.1:6379> lpush k1 redis
(integer) 1
redis 127.0.0.1:6379> lpush k1 mongodb
(integer) 2
redis 127.0.0.1:6379> lpush k1 rabbitmq
(integer) 3
redis 127.0.0.1:6379> lrange k1 0 10
1) "rabbitmq"
2) "mongodb"
3) "redis"
redis 127.0.0.1:6379>

常用命令

序号 命令及描述
1 LPUSH key value1 value2 将一个或多个值插入到列表头部
2 RPUSH key value1 value2 在列表中添加一个或多个值
3 LPOP key 移出并获取列表的第一个元素
4 RPOP key 移除列表的最后一个元素，返回值为移除的元素。
5 BLPOP key1 [key2] timeout 移出并获取列表的第一个元素， 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。
6 BRPOP key1 [key2] timeout 移出并获取列表的最后一个元素， 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。
7 BRPOPLPUSH source destination timeout 从列表中弹出一个值，将弹出的元素插入到另外一个列表中并返回它； 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。
8 LINDEX key index 通过索引获取列表中的元素
9 LRANGE key start stop获取列表指定范围内的元素 ,-1可以代表最后一个
10 LLEN key 获取列表长度
11 LINSERT key BEFORE|AFTER pivot value 在列表的元素前或者后插入元素
12 LSET key index value 通过索引设置列表元素的值
13 LREM key count value 移除列表元素，count > 0 : 从表头开始向表尾搜索，移除与 VALUE 相等的元素，数量为 COUNT 。count < 0 : 从表尾开始向表头搜索；count = 0 : 移除表中所有与 VALUE 相等的值。
14 LPUSHX key value 将一个值插入到已存在的列表头部
15 RPUSHX key value 为已存在的列表添加值
16 LTRIM key start stop 对一个列表进行修剪(trim)，就是说，让列表只保留指定区间内的元素，不在指定区间之内的元素都将被删除。
17 RPOPLPUSH source destination 移除列表的最后一个元素，并将该元素添加到另一个列表并返回

数据结构

List 类型的底层数据结构是由双向链表或压缩列表实现的：

  • 如果列表的元素个数小于 512 个（默认值，可由 list-max-ziplist-entries 配置），列表每个元素的值都小于 64 字节（默认值，可由 list-max-ziplist-value 配置），Redis 会使用压缩列表作为 List 类型的底层数据结构；
  • 如果列表的元素不满足上面的条件，Redis 会使用双向链表作为 List 类型的底层数据结构；

但是在 Redis 3.2 版本之后，List 数据类型底层数据结构就只由 quicklist 实现了，替代了双向链表和压缩列表。

因为普通的链表需要的附加指针空间太大，会比较浪费空间。比如这个列表里存的只是int类型的数据，结构上还需要两个额外的指针prev和next。Redis将链表和ziplist结合起来组成了quicklist。也就是将多个ziplist使用双向指针串起来使用。这样既满足了快速的插入删除性能，又不会出现太大的空间冗余。

应用场景

消息队列

2.4集合set

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

集合对象的编码可以是 intset 或者 hashtable。

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

集合中最大的成员数为 232 - 1 (4294967295, 每个集合可存储40多亿个成员)。

1
2
3
4
5
6
7
8
9
10
11
12
13
redis 127.0.0.1:6379> SADD w3ckey redis
(integer) 1
redis 127.0.0.1:6379> SADD w3ckey mongodb
(integer) 1
redis 127.0.0.1:6379> SADD w3ckey mysql
(integer) 1
redis 127.0.0.1:6379> SADD w3ckey mysql
(integer) 0
redis 127.0.0.1:6379> SMEMBERS w3ckey
 
1) "mysql"
2) "mongodb"
3) "redis"

常用命令

下表列出了 Redis 集合基本命令：

序号 命令及描述
1 SADD key member1 [member2] 向集合添加一个或多个成员
10 SPOP key [count] 移除并返回集合中的一个随机元素，可以实现抽奖功能，加count就是移除count个
2 SCARD key 获取集合的成员数
12 SREM key member1 [member2] 移除集合中一个或多个成员
8 SMEMBERS key 返回集合中的所有成员
7 SISMEMBER key member 判断 member 元素是否是集合 key 的成员
11 SRANDMEMBER key [count] 返回集合中随机选出count个元素，元素不会从key中删除
3 SDIFF key1 [key2] 返回给定所有集合的差集
4 SDIFFSTORE destination key1 [key2] 返回给定所有集合的差集并存储在 destination 中
5 SINTER key1 [key2] 返回给定所有集合的交集
6 SINTERSTORE destination key1 [key2] 返回给定所有集合的交集并存储在 destination 中
9 SMOVE source destination member 将 member 元素从 source 集合移动到 destination 集合
13 SUNION key1 [key2] 返回所有给定集合的并集
14 SUNIONSTORE destination key1 [key2] 所有给定集合的并集存储在 destination 集合中
15 [SSCAN key cursor MATCH pattern] [COUNT count] 迭代集合中的元素

内部实现

Set 类型的底层数据结构是由哈希表或整数集合实现的：

  • 如果集合中的元素都是整数且元素个数小于 512 （默认值，set-maxintset-entries配置）个，Redis 会使用整数集合作为 Set 类型的底层数据结构；
  • 如果集合中的元素不满足上面条件，则 Redis 使用哈希表作为 Set 类型的底层数据结构。

应用场景

点赞

Set 类型可以保证一个用户只能点一个赞，这里举例子一个场景，key 是文章id，value 是用户id。

uid:1 、uid:2、uid:3 三个用户分别对 article:1 文章点赞了。

1
2
3
4
5
6
7
8
9
# uid:1 用户对文章 article:1 点赞
> SADD article:1 uid:1
(integer) 1
# uid:2 用户对文章 article:1 点赞
> SADD article:1 uid:2
(integer) 1
# uid:3 用户对文章 article:1 点赞
> SADD article:1 uid:3
(integer) 1

uid:1 取消了对 article:1 文章点赞。

1
2
> SREM article:1 uid:1
(integer) 1

获取 article:1 文章所有点赞用户 :

1
2
3
> SMEMBERS article:1
1) "uid:3"
2) "uid:2"

获取 article:1 文章的点赞用户数量：

1
2
> SCARD article:1
(integer) 2

判断用户 uid:1 是否对文章 article:1 点赞了：

1
2
> SISMEMBER article:1 uid:1
(integer) 0  # 返回0说明没点赞，返回1则说明点赞了

共同关注

Set 类型支持交集运算，所以可以用来计算共同关注的好友、公众号等。

key 可以是用户id，value 则是已关注的公众号的id。

uid:1 用户关注公众号 id 为 5、6、7、8、9，uid:2 用户关注公众号 id 为 7、8、9、10、11。

1
2
3
4
5
6
# uid:1 用户关注公众号 id 为 5、6、7、8、9
> SADD uid:1 5 6 7 8 9
(integer) 5
# uid:2  用户关注公众号 id 为 7、8、9、10、11
> SADD uid:2 7 8 9 10 11
(integer) 5

uid:1 和 uid:2 共同关注的公众号：

1
2
3
4
5
# 获取共同关注
> SINTER uid:1 uid:2
1) "7"
2) "8"
3) "9"

给 uid:2 推荐 uid:1 关注的公众号：

1
2
3
> SDIFF uid:1 uid:2
1) "5"
2) "6"

验证某个公众号是否同时被 uid:1 或 uid:2 关注:

1
2
3
4
> SISMEMBER uid:1 5
(integer) 1 # 返回0，说明关注了
> SISMEMBER uid:2 5
(integer) 0 # 返回0，说明没关注

抽奖活动

存储某活动中中奖的用户名 ，Set 类型因为有去重功能，可以保证同一个用户不会中奖两次。

key为抽奖活动名，value为员工名称，把所有员工名称放入抽奖箱 ：

1
2
>SADD lucky Tom Jerry John Sean Marry Lindy Sary Mark
(integer) 5

如果允许重复中奖，可以使用 SRANDMEMBER 命令。

1
2
3
4
5
6
7
8
9
10
11
12
# 抽取 1 个一等奖：
> SRANDMEMBER lucky 1
1) "Tom"
# 抽取 2 个二等奖：
> SRANDMEMBER lucky 2
1) "Mark"
2) "Jerry"
# 抽取 3 个三等奖：
> SRANDMEMBER lucky 3
1) "Sary"
2) "Tom"
3) "Jerry"

如果不允许重复中奖，可以使用 SPOP 命令。

1
2
3
4
5
6
7
8
9
10
11
12
# 抽取一等奖1个
> SPOP lucky 1
1) "Sary"
# 抽取二等奖2个
> SPOP lucky 2
1) "Jerry"
2) "Mark"
# 抽取三等奖3个
> SPOP lucky 3
1) "John"
2) "Sean"
3) "Lindy"

2.5有序集合sorted set

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

不同的是每个元素都会关联一个 double 类型的分数。redis 正是通过分数来为集合中的成员进行从小到大的排序。

有序集合的成员是唯一的,但分数(score)却可以重复。

集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。 集合中最大的成员数为 2^32^ - 1 (4294967295, 每个集合可存储40多亿个成员)。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
redis 127.0.0.1:6379> ZADD runoobkey 1 redis
(integer) 1
redis 127.0.0.1:6379> ZADD runoobkey 2 mongodb
(integer) 1
redis 127.0.0.1:6379> ZADD runoobkey 3 mysql
(integer) 1
redis 127.0.0.1:6379> ZADD runoobkey 3 mysql
(integer) 0
redis 127.0.0.1:6379> ZADD runoobkey 4 mysql
(integer) 0
redis 127.0.0.1:6379> ZRANGE runoobkey 0 10 WITHSCORES

1) "redis"
2) "1"
3) "mongodb"
4) "2"
5) "mysql"
6) "4"

常用命令

下表列出了 redis 有序集合的基本命令:

序号 命令及描述
1 ZADD key score1 member1 [score2 member2] 向有序集合添加一个或多个成员，或者更新已存在成员的分数
2 ZCARD key 获取有序集合的成员数
11 ZREM key member [member …] 移除有序集合中的一个或多个成员
18 ZSCORE key member 返回有序集中，成员的分数值
4 ZINCRBY key increment member 有序集合中对指定成员的分数加上增量 increment
7 ZRANGE key start stop [WITHSCORES] 通过索引区间返回有序集合成指定区间内的成员
8 ZRANGEBYLEX key min max [LIMIT offset count] 通过字典区间返回有序集合的成员
9 ZRANGEBYSCORE key min max [WITHSCORES] [LIMIT offset count] 通过分数返回有序集合指定区间内的成员
12 ZREMRANGEBYLEX key min max 移除有序集合中给定的字典区间的所有成员
14 ZREMRANGEBYSCORE key min max 移除有序集合中给定的分数区间的所有成员
13 ZREMRANGEBYRANK key start stop 移除有序集合中给定的排名区间的所有成员
3 ZCOUNT key min max 计算在有序集合中指定区间分数的成员数
5 ZINTERSTORE destination numkeys key [key …] 计算给定的一个或多个有序集的交集并将结果集存储在新的有序集合 key 中
19 ZUNIONSTORE destination numkeys key [key …]计算给定的一个或多个有序集的并集，并存储在新的 key 中
6 ZLEXCOUNT key min max 在有序集合中计算指定字典区间内成员数量
10 ZRANK key member 返回有序集合中指定成员的索引
15 ZREVRANGE key start stop [WITHSCORES] 返回有序集中指定区间内的成员，通过索引，分数从高到底
16 ZREVRANGEBYSCORE key max min [WITHSCORES] 返回有序集中指定分数区间内的成员，分数从高到低排序
17 ZREVRANK key member 返回有序集合中指定成员的排名，有序集成员按分数值递减(从大到小)排序
20 [ZSCAN key cursor MATCH pattern] [COUNT count] 迭代有序集合中的元素（包括元素成员和元素分值）

内部实现

Zset 类型的底层数据结构是由压缩列表或跳表实现的：

  • 如果有序集合的元素个数小于 128 个，并且每个元素的值小于 64 字节时，Redis 会使用压缩列表作为 Zset 类型的底层数据结构；
  • 如果有序集合的元素不满足上面的条件，Redis 会使用跳表作为 Zset 类型的底层数据结构；

在 Redis 7.0 中，压缩列表数据结构已经废弃了，交由 listpack 数据结构来实现了。

应用场景

排行榜

有序集合比较典型的使用场景就是排行榜。例如学生成绩的排名榜、游戏积分排行榜、视频播放排名、电商系统中商品的销量排名等。

电话、姓名排序

使用有序集合的 ZRANGEBYLEX 或 ZREVRANGEBYLEX 可以帮助我们实现电话号码或姓名的排序，我们以 ZRANGEBYLEX （返回指定成员区间内的成员，按 key 正序排列，分数必须相同）为例。

注意：不要在分数不一致的 SortSet 集合中去使用 ZRANGEBYLEX和 ZREVRANGEBYLEX 指令，因为获取的结果会不准确。

2.6 新数据类型

Bitmaps

Redis提供了Bitmaps这个“数据类型”可以实现对位的操作：

（1） Bitmaps本身不是一种数据类型， 实际上它就是字符串（key-value） ， 但是它可以对字符串的位进行操作。

（2） Bitmaps单独提供了一套命令， 所以在Redis中使用Bitmaps和使用字符串的方法不太相同。 可以把Bitmaps想象成一个以位为单位的数组， 数组的每个单元只能存储0和1， 数组的下标在Bitmaps中叫做偏移量。

常用命令 作用

1、getbit key offset 用于获取指定key对应的值，中对应offset的bit ，对不存在的 key 或者不存在的 offset 进行 GETBIT， 返回 0

2、setbit key offset value 用于修改指定key对应的值，中对应offset的bit

3、 bitcount key [start end] 用于统计字符串被设置为1的bit数

4、bitop and/or/xor/not destkey key [key …] 用于一个或对多个key求逻辑与/逻辑或/逻辑异或/逻辑非，并将结果保存到 destkey 上

BITOP AND destkey key [key …] ，对一个或多个 key 求逻与，并将结果保存到 destkey

BITOP OR destkey key [key …] ，对一个或多个 key 求逻辑或，并将结果保存到 destkey 全0为0，不全0为1

BITOP XOR destkey key [key …] ，对一个或多个 key 求逻辑异或，并将结果保存到 destkey 不同为1，相同为0

BITOP NOT destkey key ，对给定 key 求逻辑非，并将结果保存到 destkey 按位取反

除了 NOT 操作之外，其他操作都可以接受一个或多个 key 作为输入，当 BITOP 处理不同长度的字符串时，较短的那个字符串所缺少的部分会被看作 0，空的 key 也被看作是包含 0 的字符串序列

BITOP AND destkey key [key …]演示：

1
2
3
4
5
6
7
8
> setbit k1 1 1
(integer) 0
> setbit k2 7 1
(integer) 0
> bitop and k3 k1 k2
(integer) 1
> get k3
"\x00"

img

​ 全1为1，不全1为0

案例

Redis 亿级用户信息存储实践：bitmap 位图存储

如果一个网站有1亿用户,假如user_id用的是整型,长度为32位,每天有5千万独立用户访问,如何判断是哪5千万用户访问了网站。

  • 方式一:用set来保存

使用set来保存数据运行一天需要占用的内存为 32bit*50000000=(4 * 50000000) / 1024 /1024 MB,约为200MB

运行一个月需要占用的内存为30 * 200 = 6G，运行一年占用的内存为72G

  • 方式二：使用bitmap的方式

user_id作为offset，如果user_id访问网站，则在user_id的索引上设置为1，没有访问网站的user_id，其索引设置为0，此种方式运行一天占用的内存为 1bit* 100000000 = 100000000 / 1024 /1024/ 8MB，约为12.5MB 运行一个月占用的内存为375MB，一年占用的内存容量为4.5G

场景

网站用户签到的天数统计

用户ID为key，天作为offset，上线置为1 366> 000000000000000

366 /8=46Byte ID为18的用户，今年的第1天签到、第30天签到

1
2
3
4
5
6
> setbit u18 1 1
(integer) 0
> setbit u18 30 1
(integer) 0
> bitcount u18 #统计id为18的用户签到总次数
(integer) 2

按天统计网站活跃用户

天作为key，用户ID为offset，上线置为1

一亿用户，运行一天占用的内存为 1bit* 100000000 = 100000000 / 1024 /1024/ 8MB，约为12.5MB 运行一个月占用的内存为375MB，一年占用的内存容量为4.5G

1
2
3
4
5
6
7
>SETBIT 20190601 5  1    #0000 0100
>SETBIT 20190602 7  1    #0000 0001 
>SETBIT 20190603 7  1    #0000 0001

求6月1日到6月10日的活跃用户数
>BITOP OR users 20190601 20190602 20190603 ... 20190610
>BITCOUNT users    #目标key为users 结果为2

用户在线状态、在线人数统计

1
2
3
4
5
6
7
8
9
10
> SETBIT online 5  1 #0000 0100 上线为1
(integer) 0
> SETBIT online 7  1 #0000 0101
(integer) 0
> bitcount online #当前在线人数
(integer) 2 
> SETBIT online 7  0
(integer) 1
> bitcount online #当前在线人数
(integer) 1
Redis HyperLogLog

Redis 在 2.8.9 版本添加了 HyperLogLog 结构。

Redis HyperLogLog 是用来做基数统计的算法，HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定 的、并且是很小的。

在 Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基 数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。

但是，因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。

GEO

Redis GEO 主要用于存储地理位置信息，并对存储的信息进行操作，该功能在 Redis 3.2 版本新增。

Redis GEO 操作方法有：

  • geoadd：添加地理位置的坐标。
  • geopos：获取地理位置的坐标。
  • geodist：计算两个位置之间的距离。
  • georadius：根据用户给定的经纬度坐标来获取指定范围内的地理位置集合。
  • georadiusbymember：根据储存在位置集合里面的某个地点获取指定范围内的地理位置集合。
  • geohash：返回一个或多个位置对象的 geohash 值。

4、发布订阅

Redis 发布订阅 (pub/sub) 是一种消息通信模式：发送者 (pub) 发送消息，订阅者 (sub) 接收消息。

Redis 客户端可以订阅任意数量的频道。

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

img

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

img

实例

以下实例演示了发布订阅是如何工作的，需要开启两个 redis-cli 客户端。

第一个 redis-cli 客户端（订阅者）

在我们实例中我们创建了订阅频道名为 runoobChat:

1
2
3
4
5
6
redis 127.0.0.1:6379> SUBSCRIBE runoobChat

Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "runoobChat"
3)(integer) 1

现在，我们先重新开启个 redis 客户端，然后在同一个频道 runoobChat 发布两次消息，订阅者就能接收到消息。

第二个 redis-cli 客户端（发布者）

1
2
3
4
5
redis 127.0.0.1:6379> PUBLISH runoobChat "Redis PUBLISH test"
(integer) 1

redis 127.0.0.1:6379> PUBLISH runoobChat "Learn redis by runoob.com"
(integer) 1

\订阅者的客户端会显示如下消息

1
2
3
4
5
6
7
1) "message"
2) "runoobChat"
3) "Redis PUBLISH test"

1) "message"
2) "runoobChat"
3) "Learn redis by runoob.com"

gif 演示如下：

  • 开启本地 Redis 服务，开启两个 redis-cli 客户端。
  • 在第一个 redis-cli 客户端输入 SUBSCRIBE runoobChat，意思是订阅 runoobChat 频道。
  • 在第二个 redis-cli 客户端输入 PUBLISH runoobChat “Redis PUBLISH test” 往 runoobChat 频道发送消息，这个时候在第一个 redis-cli 客户端就会看到由第二个 redis-cli 客户端发送的测试消息。

img

命令

序号 命令及描述
1 PSUBSCRIBE pattern [pattern …] 订阅一个或多个符合给定模式的频道。
2 [PUBSUB subcommand argument [argument …]] 查看订阅与发布系统状态。
3 PUBLISH channel message 将信息发送到指定的频道。
4 [PUNSUBSCRIBE pattern [pattern …]] 退订所有给定模式的频道。
5 SUBSCRIBE channel [channel …] 订阅给定的一个或多个频道的信息。
6 [UNSUBSCRIBE channel [channel …]] 指退订给定的频道。

5、Java 使用 Redis(Jedis)

案例

6、Redis与Spring Boot整合

1
2
3
4
5
6
7
8
9
10
11
12
13
<!-- redis -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

<!-- spring2.X集成redis所需common-pool2-->
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-pool2</artifactId>
<version>2.6.0</version>
</dependency>

application.properties配置redis配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#Redis服务器地址
spring.redis.host=192.168.140.136
#Redis服务器连接端口
spring.redis.port=6379
#Redis数据库索引（默认为0）
spring.redis.database= 0
#连接超时时间（毫秒）
spring.redis.timeout=1800000
#连接池最大连接数（使用负值表示没有限制）
spring.redis.lettuce.pool.max-active=20
#最大阻塞等待时间(负数表示没限制)
spring.redis.lettuce.pool.max-wait=-1
#连接池中的最大空闲连接
spring.redis.lettuce.pool.max-idle=5
#连接池中的最小空闲连接
spring.redis.lettuce.pool.min-idle=0

配置类，一般自定义配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
@EnableCaching
@Configuration
public class RedisConfig extends CachingConfigurerSupport {

    @Bean
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        RedisSerializer<String> redisSerializer = new StringRedisSerializer();
        Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class);
        ObjectMapper om = new ObjectMapper();
        om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
        om.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
        jackson2JsonRedisSerializer.setObjectMapper(om);
        template.setConnectionFactory(factory);
		//key序列化方式
        template.setKeySerializer(redisSerializer);
		//value序列化
        template.setValueSerializer(jackson2JsonRedisSerializer);
		//value hashmap序列化
        template.setHashValueSerializer(jackson2JsonRedisSerializer);
        return template;
    }

    @Bean
    public CacheManager cacheManager(RedisConnectionFactory factory) {
        RedisSerializer<String> redisSerializer = new StringRedisSerializer();
        Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class);
		//解决查询缓存转换异常的问题
        ObjectMapper om = new ObjectMapper();
        om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
        om.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
        jackson2JsonRedisSerializer.setObjectMapper(om);
		// 配置序列化（解决乱码的问题）,过期时间600秒
        RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
                .entryTtl(Duration.ofSeconds(600))
                .serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(redisSerializer))
                .serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(jackson2JsonRedisSerializer))
                .disableCachingNullValues();
        RedisCacheManager cacheManager = RedisCacheManager.builder(factory)
                .cacheDefaults(config)
                .build();
        return cacheManager;
    }
}

简单使用redis

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
@RestController
@RequestMapping("redis")
public class RedisController {

    @Autowired
    private RedisTemplate redisTemplate;
    @GetMapping
    public String saveRedis(){
        redisTemplate.opsForValue().set("springboot:redis:name","promsing");

        Object o = redisTemplate.opsForValue().get("springboot:redis:name");

        System.out.println("redis中存储的内容"+o);

        return o.toString();
    }

}

@RunWith(SpringRunner.class)
@SpringBootTest(classes = UserApplication.class)
public class RedisTest {

    @Autowired
    private StringRedisTemplate redisTemplate;//存储的数据进行了序列化,建议使用它

    private RedisTemplate redisTemplate2;//存储的数据没有给序列化

    @Test
    public void testRedis() {
        // 存储数据
        this.redisTemplate.opsForValue().set("key2", "value2");
        // 获取数据
        String val = this.redisTemplate.opsForValue().get("key2");
        System.out.println("val = " + val);
    }

    @Test
    public void testRedis2() {
        // 存储数据，并指定剩余生命时间,5小时
        this.redisTemplate.opsForValue().set("key2", "value2",
                5, TimeUnit.HOURS); 
    }

    @Test
    public void testHash() {
        BoundHashOperations<String, Object, Object> hashOps =
                this.redisTemplate.boundHashOps("user");
        // 操作hash数据
        hashOps.put("name", "jack");
        hashOps.put("age", "21");

        // 获取单个数据
        Object name = hashOps.get("name");
        System.out.println("name = " + name);

        // 获取所有数据
        Map<Object, Object> map = hashOps.entries();
        for (Map.Entry<Object, Object> me : map.entrySet()) {
            System.out.println(me.getKey() + " : " + me.getValue());
        }
    }
}

更多操作API

7、Redis事务

Redis 事务可以一次执行多个命令， 并且带有以下三个重要的保证：

  • 批量操作在发送 EXEC 命令前被放入队列缓存。
  • 收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。
  • 在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。

一个事务从开始到执行会经历以下三个阶段：

  • 开始事务。MULTI
  • 命令入队。组队阶段出现错误，提交会失败
  • 执行事务。EXEC

实例

以下是一个事务的例子， 它先以 MULTI 开始一个事务， 然后将多个命令入队到事务中， 最后由 EXEC 命令触发事务， 一并执行事务中的所有命令：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
redis 127.0.0.1:6379> MULTI
OK

redis 127.0.0.1:6379> SET book-name "Mastering C++ in 21 days"
QUEUED

redis 127.0.0.1:6379> GET book-name
QUEUED

redis 127.0.0.1:6379> SADD tag "C++" "Programming" "Mastering Series"
QUEUED

redis 127.0.0.1:6379> SMEMBERS tag
QUEUED

redis 127.0.0.1:6379> EXEC
1) OK
2) "Mastering C++ in 21 days"
3) (integer) 3
4) 1) "Mastering Series"
   2) "C++"
   3) "Programming"

单个 Redis 命令的执行是原子性的，但 Redis 没有在事务上增加任何维持原子性的机制，所以 Redis 事务的执行并不是原子性的。

事务可以理解为一个打包的批量执行脚本，但批量指令并非原子化的操作，中间某条指令的失败不会导致前面已做指令的回滚，也不会造成后续的指令不做。

1
2
3
4
5
6
7
8
9
10
11
12
redis 127.0.0.1:6379> MULTI
OK
redis 127.0.0.1:6379> SET book-name "Mastering C++ in 21 days"
QUEUED
redis 127.0.0.1:6379> INCR book_name
QUEUED
redis 127.0.0.1:6379> SET K2 V2
QUEUE
redis 127.0.0.1:6379> EXEC
ok
error #不会发生回滚
ok

组队失败的情况

1
2
3
4
5
6
7
8
9
10
redis 127.0.0.1:6379> MULTI
OK
redis 127.0.0.1:6379> SET book-name "Mastering C++ in 21 days"
QUEUED
redis 127.0.0.1:6379> SET K1 
ERROR
redis 127.0.0.1:6379> SET K2 V2
QUEUE
redis 127.0.0.1:6379> EXEC
ERROR

下表列出了 redis 事务的相关命令：

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

springboot整合redis的时候不要在事务中做查询，因为不会马上有结果

8、Redis脚本(Lua)

Redis 脚本使用 Lua 解释器来执行脚本。 Redis 2.6 版本通过内嵌支持 Lua 环境。执行脚本的常用命令为 EVAL。

语法

Eval 命令的基本语法如下：

1
redis 127.0.0.1:6379> EVAL script numkeys key [key ...] arg [arg ...]

实例

以下实例演示了 redis 脚本工作过程：

1
2
3
4
5
6
redis 127.0.0.1:6379> EVAL "return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}" 2 key1 key2 first second

1) "key1"
2) "key2"
3) "first"
4) "second"

Redis 脚本命令

下表列出了 redis 脚本常用命令：

序号 命令及描述
1 [EVAL script numkeys key key …] arg [arg …] 执行 Lua 脚本。
2 [EVALSHA sha1 numkeys key key …] arg [arg …] 执行 Lua 脚本。
3 SCRIPT EXISTS script [script …]查看指定的脚本是否已经被保存在缓存当中。
4 SCRIPT FLUSH 从脚本缓存中移除所有脚本。
5 SCRIPT KILL 杀死当前正在运行的 Lua 脚本。
6 SCRIPT LOAD script 将脚本 script 添加到脚本缓存中，但并不立即执行这个脚本。

9、持久化

9.1 AOF

AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。AOF是写后日志，“写后”的意思是 Redis 是先执行命令，把数据写入内存，然后才记录日志,命令执行后才记录日志，所以不会阻塞当前的写操作。

如果先记日志再执行命令的话，日志中就有可能记录了错误的命令，Redis 在使用日志恢复数据时，就可能会出错。

后写避免了对当前命令的阻塞，但可能会给下一个操作带来阻塞风险。这是因为，AOF 日志也是在主线程中执行的，如果在把日志文件写入磁盘时，磁盘写压力大，就会导致写盘很慢，进而导致后续的操作也无法执行了。

Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。

Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。你甚至可以关闭持久化功能，让数据只在服务器运行时存在。

你可以通过修改配置文件来打开 AOF 功能：

1
appendonly yes

日志重写

你可以猜得到，写操作不断执行的时候AOF文件会越来越大。例如，如果你增加一个计数器100次，你的数据集里只会有一个键存储这最终值，但是却有100条记录在AOF中。其中99条记录在重建当前状态时是不需要的。

于是Redis支持一个有趣的特性：在后台重建AOF而不影响服务客户端。每当你发送BGREWRITEAOF时，Redis将会写入一个新的AOF文件，包含重建当前内存中数据集所需的最短命令序列。如果你使用的是Redis 2.2的AOF，你需要不时的运行BGREWRITEAOF命令。Redis 2.4可以自动触发日志重写(查看Redis 2.4中的示例配置文件以获得更多信息)。

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

AOF3种写盘策略

你可以配置 Redis 多久才将数据 fsync 到磁盘一次。有三个选项：

  • 每次有新命令追加到 AOF 文件时就执行一次 fsync ：非常慢，也非常安全。
  • 每秒 fsync 一次：足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。
  • 从不 fsync ：将数据交给操作系统来处理。更快，也更不安全的选择。

推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。 总是 fsync 的策略在实际使用中非常慢， 即使在 Redis 2.0 对相关的程序进行了改进之后仍是如此 —— 频繁调用 fsync 注定了这种策略不可能快得起来。

当使用Always策略时，主线程执行完命令之后，会调用fsync()函数，把缓冲区的数据写入到硬盘的aof文件，等到硬盘操作往之后函数才会返回，如果写入的是一个大key，主线程在执行fsync()的时候就会被阻塞比较久。

大key是指key对应的value很大

对于string类型 值>10kb

hash list,set, zset 类型的元素个数超高5000个

如果 AOF 文件出错了，怎么办？

服务器可能在程序正在对 AOF 文件进行写入时崩溃（这个不应该破坏数据的一致性）， Redis不会装载已破坏的AOF文件。当发生这种情况时， 可以用以下方法来修复出错的 AOF 文件：

  • 为现有的 AOF 文件创建一个备份。
  • 使用 Redis 附带的 redis-check-aof 程序，对原来的 AOF 文件进行修复。
  • $ redis-check-aof –fix
  • （可选）使用 diff -u 对比修复后的 AOF 文件和原始 AOF 文件的备份，查看两个文件之间的不同之处。
  • 重启 Redis 服务器，等待服务器载入修复后的 AOF 文件，并进行数据恢复。

重写如何工作

日志重写采用了和快照一样的写时复制机制。下面是过程：

  • Redis调用fork()。于是我们有了父子两个进程。
  • 子进程开始向一个临时文件中写AOF。
  • 父进程在一个内存缓冲区中积累新的变更(同时将新的变更写入旧的AOF文件，所以即使重写失败我们也安全)。
  • 当子进程完成重写文件，父进程收到一个信号，追加内存缓冲区到子进程创建的文件末尾。
  • 搞定！现在Redis原子性地重命名旧文件为新的，然后开始追加新数据到新文件。

AOF重写是非阻塞的，和 AOF 日志由主线程写回不同，重写过程是由后台线程 bgrewriteaof 来完成的，这也是为了避免阻塞主线程，导致数据库性能下降。

我把重写的过程总结为“一个拷贝，两处日志”。

“一个拷贝”就是指，每次执行重写时，主线程 fork 出后台的 bgrewriteaof 子进程。此时，fork 会把主线程的内存拷贝一份给 bgrewriteaof 子进程，这里面就包含了数据库的最新数据。然后，bgrewriteaof 子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，记入重写日志。

“两处日志”又是什么呢？

因为主线程未阻塞，仍然可以处理新来的操作。此时，如果有写操作，第一处日志就是指正在使用的 AOF 日志，Redis 会把这个操作写到它的缓冲区。这样一来，即使宕机了，这个 AOF 日志的操作仍然是齐全的，可以用于恢复。

而第二处日志，就是指新的 AOF 重写日志。这个操作也会被写到重写日志的缓冲区。这样，重写日志也不会丢失最新的操作。等到拷贝数据的所有操作记录重写完成后，重写日志记录的这些最新操作也会写入新的 AOF 文件，以保证数据库最新状态的记录。此时，我们就可以用新的 AOF 文件替代旧文件了。

image-20220912153729399

AOF 的优点:

  • 使用AOF Redis会更具有可持久性(durable)：你可以有很多不同的fsync策略：没有fsync，每秒fsync，每次请求时fsync。使用默认的每秒fsync策略，写性能也仍然很不错(fsync是由后台线程完成的，主线程继续努力地执行写请求)，即便你也就仅仅只损失一秒钟的写数据。
  • AOF日志是一个追加文件，所以不需要定位，在断电时也没有损坏问题。即使由于某种原因文件末尾是一个写到一半的命令(磁盘满或者其他原因),redis-check-aof工具也可以很轻易的修复。
  • 当AOF文件变得很大时，Redis会自动在后台进行重写。重写是绝对安全的，因为Redis继续往旧的文件中追加，使用创建当前数据集所需的最小操作集合来创建一个全新的文件，一旦第二个文件创建完毕，Redis就会切换这两个文件，并开始往新文件追加。
  • AOF文件里面包含一个接一个的操作，以易于理解和解析的格式存储。你也可以轻易的导出一个AOF文件。例如，即使你不小心错误地使用FLUSHALL命令清空一切，如果此时并没有执行重写，你仍然可以保存你的数据集，你只要停止服务器，删除最后一条命令，然后重启Redis就可以。

AOF 的缺点:

  • 对同样的数据集，AOF文件通常要大于等价的RDB文件。
  • AOF可能比RDB慢，这取决于准确的fsync策略。通常fsync设置为每秒一次的话性能仍然很高，如果关闭fsync，即使在很高的负载下也和RDB一样的快。不过，即使在很大的写负载情况下，RDB还是能提供能好的最大延迟保证。
  • 在过去，我们经历了一些针对特殊命令(例如，像BRPOPLPUSH这样的阻塞命令)的罕见bug，导致在数据加载时无法恢复到保存时的样子。这些bug很罕见，我们也在测试套件中进行了测试，自动随机创造复杂的数据集，然后加载它们以检查一切是否正常，但是，这类bug几乎不可能出现在RDB持久化中。为了说得更清楚一点：Redis AOF是通过递增地更新一个已经存在的状态，像MySQL或者MongoDB一样，而RDB快照是一次又一次地从头开始创造一切，概念上更健壮。但是，1)要注意Redis每次重写AOF时都是以当前数据集中的真实数据从头开始，相对于一直追加的AOF文件(或者一次重写读取老的AOF文件而不是读内存中的数据)对bug的免疫力更强。2)我们还没有收到一份用户在真实世界中检测到崩溃的报告。

9.2 RDB 快照

AOF 方法进行故障恢复的时候，需要逐一把操作日志都执行一遍。如果操作日志非常多，Redis 就会恢复得很缓慢，影响到正常使用。这当然不是理想的结果。RDB可以在宕机时实现快速恢复

RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）

默认情况下，Redis保存数据集快照到磁盘，名为dump.rdb的二进制文件。你可以设置让Redis在N秒内至少有M次数据集改动时保存数据集，或者你也可以手动调用SAVE或者BGSAVE命令。

例如，这个配置会让Redis在每个60秒内至少有1000次键改动时自动转储数据集到磁盘：

save 60 1000

这种策略被称为快照。

快照的运作方式:

当 Redis 需要保存 dump.rdb 文件时， 服务器执行以下操作：

  • Redis 调用 fork() ，同时拥有父进程和子进程。
  • 子进程将数据集写入到一个临时 RDB 文件中。
  • 当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

这种工作方式使得 Redis 可以从写时复制（copy-on-write）机制中获益。

配置文件 redis.conf，服务重新启动时就会恢复数据

1
dbfilename dump.rdb #默认的数据备份文件名

数据备份文件的位置，默认在安装目录下

1
CONFIG GET dir #输出dump.rdb文件的位置

配置文件中的快照配置

1
2
3
4
5
6
7
8
# Unless specified otherwise, by default Redis will save the DB:
#   * After 3600 seconds (an hour) if at least 1 change was performed
#   * After 300 seconds (5 minutes) if at least 100 changes were performed
#   * After 60 seconds if at least 10000 changes were performed
#
# You can set these explicitly by uncommenting the following line.
#
# save 3600 1 300 100 60 10000

RDB 的优点:

  • RDB是一种表示某个即时点的Redis数据的紧凑文件。RDB文件适合用于备份。例如，你可能想要每小时归档最近24小时的RDB文件，每天保存近30天的RDB快照。这允许你很容易的恢复不同版本的数据集以容灾。
  • RDB非常适合于灾难恢复，作为一个紧凑的单一文件，可以被传输到远程的数据中心，或者是Amazon S3(可能得加密)。
  • RDB最大化了Redis的性能，因为Redis父进程持久化时唯一需要做的是启动(fork)一个子进程，由子进程完成所有剩余工作。父进程实例不需要执行像磁盘IO这样的操作。
  • RDB在重启保存了大数据集的实例时比AOF要快。

RDB 的缺点

  • 当你需要在Redis停止工作(例如停电)时最小化数据丢失，RDB可能不太好。你可以配置不同的保存点(save point)来保存RDB文件(例如，5分钟之后至少对数据集100次写之后，但是你可以有多个保存点)。然而，你通常每隔5分钟或更久创建一个RDB快照，所以一旦Redis因为任何原因没有正确关闭而停止工作，你就得做好最近几分钟数据丢失的准备了。
  • RDB需要经常调用fork()子进程来持久化到磁盘。如果数据集很大的话，fork()比较耗时，结果就是，当数据集非常大并且CPU性能不够强大的话，Redis会停止服务客户端几毫秒甚至一秒。AOF也需要fork()，但是你可以调整多久频率重写日志而不会有损(trade-off)持久性(durability)。

RDB 记录的是某一时刻的数据，并不是操作

我们还要考虑两个关键问题：

  • 对哪些数据做快照？这关系到快照的执行效率问题；
  • 做快照时，数据还能被增删改吗？这关系到 Redis 是否被阻塞，能否同时正常处理请求。

给哪些内存数据做快照？

Redis 的数据都在内存中，为了提供所有数据的可靠性保证，它执行的是全量快照，也就
是说，把内存中的所有数据都记录到磁盘中.
对于 Redis 而言，它的单线程模型就决定了，我们要尽量避免所有会阻塞主线程的操作，

Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave。

  • save：在主线程中执行，会导致阻塞；
  • bgsave：创建一个子进程，专门用于写入 RDB 文件，避免了主线程的阻塞，这也是Redis RDB 文件生成的默认配置

快照时数据能修改吗?

举个例子。我们在时刻 t 给内存做快照，假设内存数据量是 4GB，磁盘的写入带宽是0.2GB/s，简单来说，至少需要 20s（4/0.2 = 20）才能做完。如果在时刻 t+5s 时，一个还没有被写入磁盘的内存数据 A，被修改成了 A’，那么就会破坏快照的完整性，因为A’不是时刻 t 时的状态。因此，和拍照类似，我们在做快照时也不希望数据“动”，也就是不能被修改。但是，如果快照执行期间数据不能被修改，Redis 就不能处理对这些数据的写操作，那无疑就会给业务服务造成巨大的影响。

为了保持写操作，Redis 就会借助操作系统提供的写时复制技术（Copy-On-Write, COW），在执行快照的同时，正常处理写操作。

简单来说，bgsave 子进程是由主线程 fork 生成的，可以共享主线程的所有内存数据。bgsave 子进程运行后，开始读取主线程的内存数据，并把它们写入 RDB 文件。

此时，如果主线程对这些数据也都是读操作（例如图中的键值对 A），那么，主线程和bgsave 子进程相互不影响。但是，如果主线程要修改一块数据（例如图中的键值对 C，还未写磁盘），那么，这块数据就会被复制一份，生成该数据的副本。然后，bgsave 子进程会把这个副本数据写入 RDB 文件，而在这个过程中，主线程仍然可以直接修改原来的数据。

image-20220912162822300

多久做一次快照？

如下图所示，我们先在 T0 时刻做了一次快照，然后又在 T0+t 时刻做了一次快照，在这期间，数据块 5 和 9 被修改了。如果在 t 这段时间内，机器宕机了，那么，只能按照 T0 时刻的快照进行恢复。此时，数据块 5 和 9 的修改值因为没有快照记录，就无法恢复了。

image-20220912163132682

如果每秒做一次快照，虽然 bgsave 执行时不阻塞主线程，但是，如果频繁地执行全量快照，也会带来两方面的开销。

一方面，频繁将全量数据写入磁盘，会给磁盘带来很大压力。

另一方面，bgsave 子进程需要通过 fork 操作从主线程创建出来。虽然，子进程在创建后不会再阻塞主线程，但是，fork 这个创建过程本身会阻塞主线程，而且主线程的内存越大，阻塞时间越长。如果频繁 fork 出 bgsave 子进程，这就会频繁阻塞主线程了。

有什么方法既能利用 RDB 的快速恢复，又能以较小的开销做到尽量少丢数据呢？

混合使用 AOF 日志和内存快照

Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法。简单来说，内存快照以一定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。

T1 和 T2 时刻的修改，用 AOF 日志记录，等到第二次做全量快照时，就可以清空 AOF 日志，因为此时的修改都已经记录到快照中了，恢复时就不再用日志了。

image-20220912163546708

开启：混合持久化的配置参数为 aof-use-rdb-preamble，配置为 yes 时开启混合持久化，在 redis 4 刚引入时，默认是关闭混合持久化的，但是在 redis 5 中默认已经打开了。

9.3 如何由RDB持久化转换到AOF持久化？

Redis 2.0 和 Redis 2.2 处理流程不一样，可以很简单猜测到 Redis 2.2 处理流程更简单，并且不需要重启。

Redis >=2.2 时

  • 创建最近的RDB文件的备份。
  • 将备份保存在安全的位置。
  • 发起如下命令。
  • $redis-cli config set appendonly yes。
  • $redis-cli config set save “”。
  • 确认数据库包含相同的keys。
  • 确认write操作被正确追加到了AOF文件。

第一个CONFIG命令开启AOF。Redis会阻塞以生成初始转储文件，然后打开文件准备写，开始追加写操作。

第二个CONFIG命令用于关闭快照持久化。这一步是可选的，如果你想同时开启这两种持久化方法。

重要：记得编辑你的redis.conf文件来开启AOF，否则当你重启服务器时，你的配置修改将会丢失，服务器又会使用旧的配置。

10、主从复制

搭建参考

Redis 具有高可靠性：一是数据尽量少丢失，二是服务尽量少中断。AOF 和 RDB 保证了前者，而对于后者，Redis 的做法就是增加副本冗余量，将一份数据同时保存在多个实例上。

实际上，Redis 提供了主从库模式，以保证数据副本的一致，主从库之间采用的是读写分离的方式。

  • 读操作：主库、从库都可以接收；
  • 写操作：首先到主库执行，然后，主库将写操作同步给从库。

image-20220912195034424

如果在上图中，不管是主库还是从库，都能接收客户端的写操作，那么，一个直接的问题就是：如果客户端对同一个数据（例如 k1）前后修改了三次，每一次的修改请求都发送到不同的实例上，在不同的实例上执行，那么，这个数据在这三个实例上的副本就不一致了（分别是 v1、v2 和 v3）

如果我们非要保持这个数据在三个实例上一致，就要涉及到加锁、实例间协商是否完成修改等一系列操作，但这会带来巨额的开销

主从库间如何进行第一次同步？

当我们启动多个 Redis 实例的时候，它们相互之间就可以通过 replicaof（Redis 5.0 之前使用 slaveof）命令形成主库和从库的关系，之后会按照三个阶段完成数据的第一次同步。

例如，现在有实例 1（ip：172.16.19.3）和实例 2（ip：172.16.19.5），我们在实例 2 上执行以下这个命令后，实例 2 就变成了实例 1 的从库，并从实例 1 上复制数据：

1
replicaof 172.16.19.3 6379

image-20220912195509697

主从级联模式分担全量复制时的主库压力

这就是“主 - 从 - 从”模式,我们可以通过“主 - 从 - 从”模式将主库生成 RDB 和传输 RDB 的压力，以级联的方式分散到从库上

image-20220912200657427

我们了解了主从库间通过全量复制实现数据同步的过程，以及通过“主 -从 - 从”模式分担主库压力的方式。那么，一旦主从库完成了全量复制，它们之间就会一直维护一个网络连接，主库会通过这个连接将后续陆续收到的命令操作再同步给从库，这个过程也称为基于长连接的命令传播，可以避免频繁建立连接的开销。如果网络断连，主从库之间就无法进行命令传播了，从库的数据自然也就没办法和主库保持一致了，客户端就可能从从库读到旧数据。

主从库间网络断了怎么办？

在 Redis 2.8 之前，如果主从库在命令传播时出现了网络闪断，那么，从库就会和主库重新进行一次全量复制，开销非常大

从 Redis 2.8 开始，网络断了之后，主从库会采用增量复制的方式继续同步。听名字大概就可以猜到它和全量复制的不同：全量复制是同步所有数据，而增量复制只会把主从库网络断连期间主库收到的命令，同步给从库。

那么，增量复制时，主从库之间具体是怎么保持同步的呢？这里的奥妙就在于repl_backlog_buffer 这个缓冲区。我们先来看下它是如何用于增量命令的同步的。

当主从库断连后，主库会把断连期间收到的写操作命令，写入 replication buffer，同时也会把这些操作命令也写入 repl_backlog_buffer 这个缓冲区。

repl_backlog_buffer 是一个环形缓冲区，主库会记录自己写到的位置，从库则会记录自己已经读到的位置。

刚开始的时候，主库和从库的写读位置在一起，这算是它们的起始位置。随着主库不断接收新的写操作，它在缓冲区中的写位置会逐步偏离起始位置，我们通常用偏移量来衡量这个偏移距离的大小，对主库来说，对应的偏移量就是 master_repl_offset。主库接收的新写操作越多，这个值就会越大。

同样，从库在复制完写操作命令后，它在缓冲区中的读位置也开始逐步偏移刚才的起始位置，此时，从库已复制的偏移量 slave_repl_offset 也在不断增加。正常情况下，这两个偏移量基本相等。

image-20220912201550054

主从库的连接恢复之后，从库首先会给主库发送 psync 命令，并把自己当前的slave_repl_offset 发给主库，主库会判断自己的 master_repl_offset 和 slave_repl_offset之间的差距。

在网络断连阶段，主库可能会收到新的写操作命令，所以，一般来说，master_repl_offset会大于 slave_repl_offset。此时，主库只用把 master_repl_offset 和 slave_repl_offset之间的命令操作同步给从库就行。

image-20220912201646405

因为 repl_backlog_buffer 是一个环形缓冲区，所以在缓冲区写满后，主库会继续写入，此时，就会覆盖掉之前写入的操作。如果从库的读取速度比较慢，就有可能导致从库还未读取的操作被主库新写的操作覆盖了，这会导致主从库间的数据不一致。

一般而言，我们可以调整 repl_backlog_size 这个参数。这个参数和所需的缓冲空间大小有关。缓冲空间的计算公式是：缓冲空间大小 = 主库写入命令速度 * 操作大小 - 主从库间网络传输命令速度 * 操作大小。在实际应用中，考虑到可能存在一些突发的请求压力，我们通常需要把这个缓冲空间扩大一倍，即repl_backlog_size = 缓冲空间大小 * 2，这也就是 repl_backlog_size 的最终值。

11、哨兵

12、集群