史上Redis开发教程

简介

Redis 是完全开源的，遵守 BSD 协议，是一个高性能的 key-value 数据库。(NO-SQL)

💡 Tips：特点

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

💡 Tips：Redis优势

• 性能极高，因为数据保存在运行内存（Redis能读的速度是110000次/s,写的速度是81000次/s 。）
• 丰富的特性 – Redis还支持 publish/subscribe, 通知, key 过期等等特性。

安装

Liunx 安装

💡 Tips：redis官网： 下载选择稳定版本 链接
💡 Tips：自定义版本：链接

1. 安装redis之前要先安装8版本的gcc、gcc-c 、gdb工具链（toolchian）低版本的安装会报错

//安装scl源
yum install centos-release-scl scl-utils-build
//安装8版本的gcc、gcc-c  、gdb工具链（toolchian）
yum install -y devtoolset-8-toolchain
scl enable devtoolset-8 bash
//查看版本号
gcc --version

2. 下载安装redis

//下载指定的版本
wget https://download.redis.io/releases/redis-6.2.6.tar.gz
//解压安装包
tar -zxvf redis-6.2.6.tar.gz
//解压完成后进入目录：cd redis-6.2.6
//编译安装
make && make install
//如果编译安装报错—Jemalloc/jemalloc.h：没有那个文件
//清除上次编译残留文件
make distclean
make && make install

3. 安装目录： /usr/local/bin

• redis-benchmark:性能测试工具，可以在自己本子运行，看看自己本子性能如何
• redis-check-aof：修复有问题的AOF文件，rdb和aof后面讲
• redis-check-rdb：修复有问题的dump.rdb文件
• redis-sentinel：Redis集群使用
• redis-server：Redis服务器启动命令
• redis-cli：客户端，操作入口

4. 服务指令

//任意目录位置，启动服务端；可以指定使用配置文件
redis-server 配置文件目录
//任意目录位置，客户端 --raw 查看中文不会乱码
reids-cli --raw
//结束redis服务
pkill redis-server
//查看redis服务状态
ps -ef |grep redis
kill -9 进程号

• 前台启动（不推荐）前台启动，命令行窗口不能关闭，否则服务器停止

• ** 后台启动（推荐）**

💡 Tips：修改redis.conf文件将里面的daemonize no 改成yes，让服务在后台启动

Docker 安装

1. 创建docker挂载文件

//创建目录
mkdir -p /root/redis/conf
//创建文件夹
touch /root/redis/conf/redis.conf

💡 Tips：借助 mkdir -p 命令，您可以创建目录的子目录。它将首先创建父目录（如果它不存在）。但是，如果它已经存在，那么它将不会打印错误消息，并将进一步创建子目录

2. 安装，资源：链接

//拉取镜像
docker pull redis
//启动镜像
docker run --restart=always -p 6379:6379 --name redis \
-v /root/redis/data:/data \
-v /root/redis/conf/redis.conf:/etc/redis/redis.conf \
-d redis redis-server /etc/redis/redis.conf

💡 Tips：–restart=always，容器随着docker启动而启动；redis.conf 不可设置后台启动，会跟docker产生冲突

配置文件介绍

💡 Tips：获取配置值：redis-cli：config get 属性名称
💡 Tips：不是全部配置，日常开发要用的

启动方式和单位

• ./redis-server /path/to/redis.conf_ redis启动方式_
• units 配置大小单位,开头定义了一些基本的度量单位，只支持bytes，不支持bit大小写不敏感

INCLUDES 包含

include

• include 类似 nginx,导入其它配置文件

MODULES 模块（没有接触过）

• Redis可以通过loadmodule选项在启动时加载模块，若服务端无法加载模块，服务端会停止。可以通过多个loadmodule选项加载多个模块。

NETWORK 网络

bind

• 默认情况bind=127.0.0.1只能接受本机的访问请求不写的情况下，无限制接受任何ip地址的访问生产环境肯定要写你应用服务器的地址；服务器是需要远程访问的，所以需要将其注释掉

protected-mode

• 默认情况开启了protected-mode，那么在没有设定bind ip且没有设密码的情况下，Redis只允许接受本机的响应

port

• 端口号，默认 6379

tcp-backlog

• 设置tcp的backlog，backlog其实是一个连接队列，backlog队列总和=未完成三次握手队列 已经完成三次握手队列。在服务器可承受的范围内，配置越高越利于客户端连接速度的提升。
• 在高并发环境下你需要一个高backlog值来避免慢客户端连接问题。
• 注意Linux内核会将这个值减小到/proc/sys/net/core/somaxconn的值（128），所以需要确认增大/proc/sys/net/core/somaxconn和/proc/sys/net/ipv4/tcp_max_syn_backlog（128）两个值来达到想要的效果

timeout

• 一个空闲的客户端维持多少秒会关闭，0表示关闭该功能。即永不关闭。

tcp-keepalive

• 对访问客户端的一种心跳检测，每个n秒检测一次。
• 单位为秒，如果设置为0，则不会进行Keepalive检测，建议设置成60

TLS/SSL(后面详解)

GENERAL 通用

daemonize

• 是否为后台进程，设置为yes；守护进程，后台启动

supervised

• 可以通过upstart和systemd管理Redis守护进程，这个参数是和具体的操作系统相关的,它可以
  配置的值有：no、upstart、systemd或auto。
  supervised no

pidfile

• 如果你以守护进程的方式运行Redis，那么Redis将会创建一个pid文件/var/run/redis.pid（对应daemonize）

loglevel

• 指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为notice

1. debug：会打印出很多信息，适用于开发和测试阶段
2. verbose（冗长的）：包含很多不太有用的信息，但比debug要清爽一些
3. notice：适用于生产模式
4. warning : 警告信息

logfile

• 日志文件的位置，当指定为空字符串时，为标准输出，如果redis已守护进程模式运行，那么日志将会

输出到/dev/null，若指定了路径，日志将会输出到指定文件，默认值是""

databases

• 设定库的数量 默认16，默认数据库为0，可以使用SELECT 命令在连接上指定数据库id

SNAPSHOTTING 快照 （参考持久化）

REPLICATION 主从复制（参考集群设置）

SECURITY 安全

requirepass

• 访问密码的查看、设置和取消

CLIENTS 客户端

maxclients

• 默认情况下为10000个客户端。
• 如果达到了此限制，redis则会拒绝新的连接请求，并且向这些连接请求方发出“max number of clients reached”以作回应。

MEMORY MANAGEMENT 内存管理

maxmemory

• 建议必须设置，否则，将内存占满，造成服务器宕机
• 设置redis可以使用的内存量。一旦到达内存使用上限，redis将会试图移除内部数据，移除规则可以通过maxmemory-policy来指定。
• 如果redis无法根据移除规则来移除内存中的数据，或者设置了“不允许移除”，那么redis则会针对那些需要申请内存的指令返回错误信息，比如SET、LPUSH等。
• 但是对于无内存申请的指令，仍然会正常响应，比如GET等。如果你的redis是主redis（说明你的redis有从redis），那么在设置内存使用上限时，需要在系统中留出一些内存空间给同步队列缓存，只有在你设置的是“不移除”的情况下，才不用考虑这个因素。

maxmemory-policy

• volatile-lru：使用LRU算法移除key，只对设置了过期时间的键；（最近最少使用）
• allkeys-lru：在所有集合key中，使用LRU算法移除key
• volatile-random：在过期集合中移除随机的key，只对设置了过期时间的键
• allkeys-random：在所有集合key中，移除随机的key
• volatile-ttl：移除那些TTL值最小的key，即那些最近要过期的key
• noeviction：不进行移除。针对写操作，只是返回错误信息（默认）

maxmemory-samples

• 设置样本数量，LRU算法和最小TTL算法都并非是精确的算法，而是估算值，所以你可以设置样本的大小，redis默认会检查这么多个key并选择其中LRU的那个。
• 一般设置3到7的数字，数值越小样本越不准确，但性能消耗越小。 默认为 5

数据类型

💡 Tips：redis 9种数据结构由5种最基本的数据结构（String、List、Hash、Set、Sorted Set（zset）） 加 bitmap、geohash、hyperloglog、streams 组成。
💡 Tips：指令的复杂度，复杂度越高redis阻塞就越长；生产环境尽量避免使用，参考：链接
💡 Tips：算法复杂度名词参考：链接

通用指令

1. keys *查看当前库所有key (匹配：keys *1) 生产环境最好不要用 keys 模糊查询，数据量大比较耗时；因为是单线程会造成阻塞
2. exists key判断某个key是否存在
3. type key 查看你的key是什么类型
4. del key 删除指定的key数据
5. unlink key 根据value选择非阻塞删除（相当于，先返回删除结果，异步在删除）
6. expire key 10 10秒钟：为给定的key设置过期时间
7. ttl key 查看还有多少秒过期，-1表示永不过期，-2表示已过期
8. select命令切换数据库
9. dbsize查看当前数据库的key的数量
10. flushdb清空当前库
11. flushall通杀全部库
12. help 指令 查看指令的使用方法

5种基本类型

1. String
2. List
3. Set
4. Hash
5. Zset(有序set)

String

简介

• String类型是二进制安全的。意味着Redis的string可以包含任何数据。比如jpg图片或者序列化的对象。
• String类型是Redis最基本的数据类型，一个Redis中字符串value最多可以是512M

常用指令

1. set 添加键值对

• NX：当数据库中key不存在时，可以将key-value添加数据库
• XX：当数据库中key存在时，可以将key-value添加数据库，与NX参数互斥
• EX：key的超时秒数
• PX：key的超时毫秒数，与EX互斥

2. get 查询对应键值
3. append 将给定的 追加到原值的末尾
4. strlen 获得值的长度
5. setnx 只有在 key 不存在时 设置key 的值
6. incr 将 key 中储存的数字值增1只能对数字值操作，如果为空，新增值为1
7. decr 将 key 中储存的数字值减1，只能对数字值操作，如果为空，新增值为-1
8. incrby / decrby <步长>将 key 中储存的数字值增减。自定义步长。

List

简介

• Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。
• 它的底层实际是个双向链表，对两端的操作性能很高，通过索引下标的操作中间的节点性能会较差。

常用指令

1. lpush/rpush … 从左边/右边插入一个或多个值。
2. lpop/rpop 从左边/右边吐出一个值。值在键在，值光键亡。
3. rpoplpush 从列表右边吐出一个值，插到列表左边。
4. lrange 按照索引下标获得元素(从左到右)
5. lrange mylist 0 -1 0左边第一个，-1右边第一个，（0-1表示获取所有）
6. lindex 按照索引下标获得元素(从左到右)
7. llen 获得列表长度
8. linsert before 在的后面插入插入值
9. lrem 从左边删除n个value(从左到右)
10. lset将列表key下标为index的值替换成value

Set

简介

• Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。
• Redis的Set是string类型的无序集合。它底层其实是一个value为null的hash表，所以添加，删除，查找的复杂度都是O(1)。
• 一个算法，随着数据的增加，执行时间的长短，如果是O(1)，数据增加，查找数据的时间不变

常用指令

1. sadd … 将一个或多个 member 元素加入到集合key 中，已经存在的member 元素将被忽略
2. smembers 取出该集合的所有值。
3. sismember 判断集合是否为含有该值，有1，没有0
4. scard返回该集合的元素个数。
5. srem … 删除集合中的某个元素。
6. spop 随机从该集合中吐出一个值。
7. srandmember 随机从该集合中取出n个值。不会从集合中删除。
8. smove value把集合中一个值从一个集合移动到另一个集合
9. sinter 返回两个集合的交集元素。
10. sunion 返回两个集合的并集元素。
11. sdiff 返回两个集合的差集元素(key1中的，不包含key2中的)

Hash

简介

• Redis hash 是一个键值对集合。
• Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。类似Java里面的Map<String,Object>

常用指令

1. hset 给集合中的 键赋值
2. **hget 从集合取出 value **
3. hmset … 批量设置hash的值
4. **hexists查看哈希表 key 中，给定域 field 是否存在。 **
5. hkeys 列出该hash集合的所有field
6. hvals 列出该hash集合的所有value
7. hincrby 为哈希表 key 中的域 field 的值加上增量 1 -1
8. **hsetnx 将哈希表 key 中的域 field 的值设置为 value ，当且仅当域 field 不存在 **

Zset

简介

• Redis有序集合zset与普通集合set非常相似，是一个没有重复元素的字符串集合。
• 不同之处是有序集合的每个成员都关联了一个评分（score）,这个评分（score）被用来按照从最低分到最高分的方式排序集合中的成员。集合的成员是唯一的，但是评分可以是重复了。
• 因为元素是有序的, 所以你也可以很快的根据评分（score）或者次序（position）来获取一个范围的元素。
• 访问有序集合的中间元素也是非常快的,因此你能够使用有序集合作为一个没有重复成员的智能列表。

常用命令

1. zadd …将一个或多个 member 元素及其score 值加入到有序集key 当中。
2. zrange [WITHSCORES] 返回有序集 key 中，下标在 之间的元素，带WITHSCORES，可以让分数一起和值返回到结果集。
3. zrangebyscore key minmax [withscores] [limit offset count]；返回有序集 key 中，所有score 值介于min 和max 之间(包括等于min 或max )的成员。有序集成员按score 值递增(从小到大)次序排列。
4. zrevrangebyscore key maxmin [withscores] [limit offset count]；同上，改为从大到小排列。
5. zincrby 为元素的score加上增量
6. zrem 删除该集合下，指定值的元素
7. zcount 统计该集合，分数区间内的元素个数
8. zrank 返回该值在集合中的排名，从0开始。

4种特殊类型

1. Bitmap
2. Geohash
3. Hyperloglog
4. Streams

Bitmap

简介

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

1. Bitmaps本身不是一种数据类型，实际上它就是字符串（key-value），但是它可以对字符串的位进行操作。
2. Bitmaps单独提供了一套命令，所以在Redis中使用Bitmaps和使用字符串的方法不太相同。可以把Bitmaps想象成一个以位为单位的数组，数组的每个单元只能存储0和1，数组的下标在Bitmaps中叫做偏移量。

常用指令

1. setbit设置Bitmaps中某个偏移量的值（0或1）

💡 Tips：offset:偏移量从0开始

重点实例:

💡 Tips：以（最大的偏移量 1）作为位图的最大长度

每个独立用户是否访问过网站存放在Bitmaps中，将访问的用户记做1，没有访问的用户记做0，用偏移量作为用户的id。
设置键的第offset个位的值（从0算起），假设现在有20个用户，userid=1， 6， 11， 15， 19的用户对网站进行了访问，那么当前Bitmaps初始化结果如图

unique:users:20201106代表2020-11-06这天的独立访问用户的Bitmaps

注：
很多应用的用户id以一个指定数字（例如10000）开头，直接将用户id和Bitmaps的偏移量对应势必会造成一定的浪费，通常的做法是每次做setbit操作时将用户id减去这个指定数字。
在第一次初始化Bitmaps时，假如偏移量非常大，那么整个初始化过程执行会比较慢，可能会造成Redis的阻塞。

2. getbit获取Bitmaps中某个偏移量的值；如果偏移量不存在，返回0
3. bitcount[start end] 统计字符串从start字节到end字节比特值为1的数量

• 值为bit,下标为byte,1byte = 8bit；字节从0开始，参考：链接

4. bitop and(or/not/xor) [key…]

💡 Tips：bitop是一个复合操作，它可以做多个Bitmaps的and（交集）、 or（并集）、 not（非）、 xor（异或）操作并将结果保存在destkey（结果集）中。

Bitmaps与set对比

假设网站有1亿用户，每天独立访问的用户有5千万，如果每天用集合类型和Bitmaps分别存储活跃用户可以得到表

很明显，这种情况下使用Bitmaps能节省很多的内存空间，尤其是随着时间推移节省的内存还是非常可观的

但Bitmaps并不是万金油，假如该网站每天的独立访问用户很少，例如只有10万（大量的僵尸用户），那么两者的对比如下表所示，很显然，这时候使用Bitmaps就不太合适了，因为基本上大部分位都是0。

💡 Tips：具体，需要自己模拟场景，使用RedisDesktopManager查看key内存，然后计算比较；上图集合的占用空间不知道怎么计算（在64位计算机中，一个字节（byte） = 8位(bit)）1亿，9位字符，UTF-8编码：一个英文字符等于一个字节

Geohash

简介

• Redis 3.2 中增加了对GEO类型的支持。GEO，Geographic，地理信息的缩写。该类型，就是元素的2维坐标，在地图上就是经纬度。redis基于该类型，提供了经纬度设置，查询，范围查询，距离查询，经纬度Hash等常见操作。

常用指令

1. geoadd< longitude> [longitude latitude member…] 添加地理位置（经度，纬度，名称）

2. geopos [member…] 获得指定地区的坐标值

3. geodist [m|km|ft|mi ] 获取两个位置之间的直线距离，默认为m

4. georadius< longitude>radius m|km|ft|mi 以给定的经纬度为中心，找出某一半径内的元素;荔湾区10公里的城市

HyperLogLog

简介

• Redis HyperLogLog 是用来做基数统计的算法，HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的。
• 在 Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。通过牺牲准确率来减少内存空间的消耗，虽然不精确但是也不是非常不精确，标准误差是0.81%。
• 但是，因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。
• 什么是基数?比如数据集 {1, 3, 5, 7, 5, 7, 8}，那么这个数据集的基数集为 {1, 3, 5 ,7, 8}, 基数(不重复元素)为5。基数估计就是在误差可接受的范围内，快速计算基数。
• 适用场景：UV（UniqueVisitor，独立访客）、独立IP数、搜索记录数

常用命令

1. pfadd < element> [element …] 添加指定元素到 HyperLogLog 中；将所有元素添加到指定HyperLogLog数据结构中。如果执行命令后HLL估计的近似基数发生变化，则返回1，否则返回0。
2. pfcount [key …] 计算HLL的近似基数，可以计算多个HLL，比如用HLL存储每天的UV，计算一周的UV可以使用7天的UV合并计算即可
3. pfmerge [sourcekey …] 将一个或多个HLL合并后的结果存储在另一个HLL中，比如每月活跃用户可以使用每天的活跃用户来合并计算可得

Streams

简介

• Stream 是 Redis 5.0 引入的一种新数据类型，可以实现一个功能非常完善的消息队列

很少使用，具体参考 链接

发布订阅

简介

• Redis 发布订阅 (pub/sub) 是一种消息通信模式：发送者 (pub) 发送消息，订阅者 (sub) 接收消息。
• Redis 客户端可以订阅任意数量的频道。

常用指令

客户端可以订阅频道如下图

当给这个频道发布消息后，消息就会发送给订阅的客户端

1. SUBSCRIBE 订阅频道

2. PUBLISH < message> 向频道发布信息

返回的1是订阅者数量
打开第一个客户端可以看到发送的消息

💡 Tips：发布的消息没有持久化，只能收到订阅后发布的消息

事务

简介

• Redis事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
• Redis事务的主要作用就是串联多个命令防止别的命令插队。
• 如果执行阶段某个命令报出了错误，则只有报错的命令不会被执行，而其他的命令都会执行，不会回滚。

常用指令

1. Multi、Exec、Discard

Multi：开启事务
Exec： 执行事务
Discard：放弃事务

2. WATCH key [key …]

在执行multi之前，先执行watch key1 [key2],可以监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断，所有正确的指令都失效。

3. unwatch

取消WATCH命令对所有key 的监视。
如果在执行WATCH命令之后，EXEC命令或DISCARD命令先被执行了的话，那么就不需要再执行UNWATCH了。

LUA脚本

简介

将复杂的或者多步的redis操作，写为一个脚本，一次提交给redis执行，减少反复连接redis的次数。提升性能。
LUA脚本是类似redis事务，不会被其他命令插队，可以完成一些redis事务性的操作。
但是注意redis的lua脚本功能，只有在Redis 2.6以上的版本才可以使用。
redis 2.6版本以后，通过lua脚本解决争抢问题，实际上是redis 利用其单线程的特性，用任务队列的方式解决多任务并发问题。
具体命令可参考：链接

秒杀案例：

-- 参数1 用户id
local userid=KEYS[1]; 
-- 参数2 用户下单商品id
-- local prodid=KEYS[2];
-- 库存key变量
local qtkey="inventory";
-- 下单key变量
local usersKey="orderRecord";
-- 查询set是否包含值
local userExists=redis.call("sismember",usersKey,userid);
-- 判断用户是否下单
if tonumber(userExists)==1 then 
  return 2;
end
-- 获取库存值，String查询
local num= redis.call("get" ,qtkey);
if tonumber(num)<=0 then 
  return 0; 
else 
  -- 库存 -1
  redis.call("decr",qtkey);
  -- 添加下单记录
  redis.call("sadd",usersKey,userid);
end
return 1;

持久化

Redis 提供了2个不同形式的持久化方式。

• RDB（Redis DataBase）
• AOF（Append Of File）

RDB

简介

• 在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里
• Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

执行时机

• 执行save命令
• 执行bgsave命令
• Redis停机时
• 触发RDB条件时

1. save 命令；save命令会导致主进程执行RDB，这个过程中其它所有命令都会被阻塞。只有在数据迁移时可能用到。

默认是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次。

2. bgsave 命令；这个命令执行后会开启独立进程完成RDB，主进程可以持续处理用户请求，不受影响。
3. Redis停机时会执行一次save命令，实现RDB持久化。
4. Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：

• 如果是save “” 则表示禁用RDB

• rdb文件 的名称

• rdb文件的位置

• rdb文件是否开启压缩,建议不开启，压缩也会消耗cpu，磁盘的话不值钱

rdb的备份

1. 先通过config get dir 查询rdb文件的目录，将.rdb的文件拷贝到别的地方*
2. rdb的恢复

• 关闭Redis
• 先把备份的文件拷贝到工作目录下 cp dump2.rdb dump.rdb
• 启动Redis, 备份数据会直接加载

原理

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。
fork采用的是copy-on-write技术：

• 当主进程执行读操作时，访问共享内存；
• 当主进程执行写操作时，则会拷贝一份数据，执行写操作

优势

• 适合大规模的数据恢复
• 对数据完整性和一致性要求不高更适合使用
• 节省磁盘空间
• 恢复速度快

劣势

• Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
• 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
• 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

AOF

简介

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

执行时机

1. AOF默认不开启

appendonly 是否开启AOF功能
appendfilename AOF文件的名称
AOF文件的保存路径，同RDB的路径一致。

2. AOF 同步频率

appendfsync always
始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好
appendfsync everysec
每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。 默认方案
appendfsync no
redis不主动进行同步，把同步时机交给操作系统。

AOF备份与异常恢复

1. AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。
2. 异常恢复

• 修改默认的appendonly no，改为yes
• 如遇到AOF文件损坏，通过/usr/local/bin/redis-check-aof–fix appendonly.aof进行恢复
• 备份被写坏的AOF文件
• 恢复：重启redis，然后重新加载

AOF文件重写

因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。

如图，AOF原本有三个命令，但是set num 123 和 set num 666都是对num的操作，第二次会覆盖第一次的值，因此第一个命令记录下来没有意义。
所以重写命令后，AOF文件内容就是：mset name jack num 666
Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置

# AOF文件比上次文件 增长超过多少百分比则触发重写;设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的2倍时触发）
#例如：文件达到70MB开始重写，降到50MB，下次什么时候开始重写？100MB
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写 
auto-aof-rewrite-min-size 64mb 

优势

• 备份机制更稳健，丢失数据概率更低。
• 可读的日志文本，通过操作AOF稳健，可以处理误操作。

劣势

• 比起RDB占用更多的磁盘空间。
• 恢复备份速度要慢。
• 每次读写都同步的话，有一定的性能压力。
• 存在个别Bug，造成恢复不能。

RDB与AOF对比

RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。

具体用哪个

• 如果对数据不敏感，可以选单独用RDB。
• 不建议单独用 AOF，因为可能会出现Bug。
• 如果只是做纯内存缓存，可以都不用。

同时开启两种持久化方式

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

性能建议

因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。
如果使用AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。
代价,一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。
默认超过原大小100%大小时重写可以改到适当的数值。

缓存问题

1. 缓存更新高一致性

    先操作sql数据库数据，在删除缓存<br />        每次查询数据未命中，查询数据库写入缓存，并设置超时时间（防止数据改变时，没有走代码逻辑）<br />       
   

2. 缓存更新低一致性

    不主动删除缓存，通过内存过大，到期时间自动移除<br />        
   

3. 缓存穿透

指数据库和缓存都没有对应的数据，导致直接访问到了 数据库

解决方案：
1.）在数据库也找不到值时，创建一个空的 缓存，设置过期时间（很重要），但是会出现短期的数据不同（比如有缓存的时候，插入了对应的信息，但是缓存没有更新）；也会出现恶意的内存消耗（几乎不会）
2.）布隆过滤器：内存占用少，没有多余的key,但是存在误判

4. 缓存雪崩

指同一时间大量的key过期或redis直接宕机，导致大量的请求到达了数据库

解决方案：
1.）添加key的过期时间时，让其不一致
2.）做集群高可用
3.）做服务保护，降级限流
4.）建立多级缓存

5. 缓存击穿

热点key高并发，并且保存缓存的逻辑比较复杂，耗时导致保存缓存时，大量的请求到数据库

解决方案：
1.）在查询数据库时 添加互斥锁；但是会出现大量请求积压；高一致性（会移除旧数据，获取不到锁一直递归；可以用lock锁，设置获取锁的时间）

2.）逻辑过期策略，保存redis缓存不设置过期时间，逻辑上添加过期标识；这样不管如何都可以获取到缓存，然后判断缓存逻辑标识是否过期，如果过期则返回旧的数据，同时获取锁（redis创建个setnx,如果这个key存在其他人就不可以更新,标识存活时间），开启个线程更新缓存

集群

主从复制

简介

• 主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主
• 读写分离，性能扩展
• 容灾快速恢复

环境准备

创建三台redis服务端

docker run --restart=always -p 6377:6377 -p 20071:20071 --name redis \
-v /root/redis/data:/data \
-v /root/redis/redis.conf:/etc/redis/redis.conf:rw \
-d redis redis-server /etc/redis/redis.conf

docker run --restart=always -p 6378:6378 -p 20072:20072 --name redis2 \
-v /root/redis/data2:/data \
-v /root/redis/redis2.conf:/etc/redis/redis.conf:rw \
-d redis redis-server /etc/redis/redis.conf

docker run --restart=always -p 6379:6379 -p 20073:20073 --name redis3 \
-v /root/redis/data3:/data \
-v /root/redis/redis3.conf:/etc/redis/redis.conf:rw \
-d redis redis-server /etc/redis/redis.conf

开启主从关系

现在三个实例还没有任何关系，要配置主从可以使用replicaof 或者slaveof（5.0以前）命令。
有临时和永久两种模式：

• 修改配置文件（永久生效）
  • 在redis.conf中添加一行配置：slaveof <masterip> <masterport>
• 使用redis-cli客户端连接到redis服务，执行slaveof命令（重启后失效）：

slaveof <masterip> <masterport>

注意：在5.0以后新增命令replicaof，与salveof效果一致。
注意：主机设置了连接密码，从机需要配置 masterauth，不然连接不上

查看集群状态 info replication
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yuDdF1ik-1660532704589)(https://cdn.nlark.com/yuque/0/2022/png/29507747/1657676738861-689cfef7-b048-4c31-ba15-036dd015c23c.png#clientId=ua31e97cc-032e-4&crop=0&crop=0&crop=1&crop=1&from=paste&height=123&id=u4d28e392&margin=[object Object]&name=image.png&originHeight=123&originWidth=447&originalType=binary&ratio=1&rotation=0&showTitle=false&size=71386&status=done&style=none&taskId=ub3fd3d27-a3c0-4a33-80ca-bddb3946cca&title=&width=447)]
从机不可以执行插入操作，会报错

薪火相传

上一个Slave可以是下一个slave的Master，Slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。
用 slaveof
中途变更转向:会清除之前的数据，重新建立拷贝最新的
风险是一旦某个slave宕机，后面的slave都没法备份
主机挂了，从机还是从机，无法写数据了

反客为主

当一个master宕机后，后面的slave可以立刻升为master，其后面的slave不用做任何修改。（建立在薪火相传的基础上）
slaveof no one 指令将从机变为主机。

复制原理

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

哨兵模式

简介

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

实现

1. 创建 sentinel.conf文件，名字绝不能错

port 20071
sentinel monitor mymaster 180.76.164.243 6377 1
sentinel auth-pass mymaster Ivan

2. 开启哨兵 redis-sentinel ./sentinel.conf
3. 自定义，成为主机的优先级；修改 redis.conf 中replic-priority 或者slave-priority（5.0以前）命令优先级在redis.conf中默认：replic-priority 100，值越小优先级越高

优先级：replic-priority最小 --> 偏移量最大 --> runid最小的服务

• 优先级在redis.conf中默认：slave-priority 100，值越小优先级越高
• 偏移量是指获得原主机数据最全的
• 每个redis实例启动后都会随机生成一个40位的runid

问题点

1. 主从机有密码 必须都在 redis.conf 中给 masterauth；其次哨兵也要加 sentinel auth-pass
2. redis服务端 和 哨兵服务 必须在一个服务器
3. 在docker 开启哨兵服务，不要挂载配置文件，不然会导致文件无法重写的问题
4. 在 docker开启哨兵服务，一定要开放哨兵服务的端口
5. 尽量一个redis服务端一个哨兵服务；不然会导致选举信息不同步

分片集群

简介

主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决：

• 海量数据存储问题
• 高并发写的问题

分片集群特征：

• 集群中有多个master，每个master保存不同数据
• 每个master都可以有多个slave节点
• master之间通过ping监测彼此健康状态
• 客户端请求可以访问集群任意节点，最终都会被转发到正确节点

环境准备

#创建cluster目录
mkdir cluster
# 进入/cluster目录
cd /cluster
# 创建目录
mkdir 7001 7002 7003 8001 8002 8003

port 6379
# 开启集群功能
cluster-enabled yes
# 集群的配置文件名称，不需要我们创建，由redis自己维护
cluster-config-file ./nodes.conf
# 节点心跳失败的超时时间
cluster-node-timeout 5000
# 持久化文件存放目录
dir ./6379
# 绑定地址
bind 0.0.0.0
# 让redis后台运行
daemonize yes
# 注册的实例ip
replica-announce-ip 180.76.164.243
# 保护模式
protected-mode no
#masterauth Ivan
# 数据库数量
databases 1
# 日志
logfile ./run.log

# 进入/cluster目录
cd /cluster
# 执行拷贝
echo 7001 7002 7003 8001 8002 8003 | xargs -t -n 1 cp redis.conf

# 进入/cluster目录
cd /cluster
# 修改配置文件
printf '%s\n' 7001 7002 7003 8001 8002 8003 | xargs -I{} -t sed -i 's/6379/{}/g' {}/redis.conf

启动

# 进入/cluster目录
cd /cluster
# 一键启动所有服务
printf '%s\n' 7001 7002 7003 8001 8002 8003 | xargs -I{} -t redis-server {}/redis.conf
# 关闭所有服务
printf '%s\n' 7001 7002 7003 8001 8002 8003 | xargs -I{} -t redis-cli -p {} shutdown

💡 Tips：如果服务配置了密码，需要加 -a 密码

创建集群

虽然服务启动了，但是目前每个服务之间都是独立的，没有任何关联。
我们需要执行命令来创建集群，在Redis5.0之前创建集群比较麻烦，5.0之后集群管理命令都集成到了redis-cli中。

1. Redis5.0之前

Redis5.0之前集群命令都是用redis安装包下的src/redis-trib.rb来实现的。因为redis-trib.rb是有ruby语言编写的所以需要安装ruby环境。

# 安装依赖
yum -y install zlib ruby rubygems
gem install redis

然后通过命令来管理集群：

# 进入redis的src目录
cd /tmp/redis-6.2.4/src
# 创建集群
./redis-trib.rb create --replicas 1 180.76.164.243:7001 180.76.164.243:7002 180.76.164.243:7003 180.76.164.243:8001 180.76.164.243:8002 180.76.164.243:8003

2. redis5.0以后

redis-cli --cluster create --cluster-replicas 1 180.76.164.243:7001 180.76.164.243:7002 180.76.164.243:7003 180.76.164.243:8001 180.76.164.243:8002 180.76.164.243:8003

命令说明：

• redis-cli --cluster或者./redis-trib.rb：代表集群操作命令
• create：代表是创建集群
• --replicas 1或者--cluster-replicas 1 ：指定集群中每个master的副本个数为1，此时节点总数 ÷ (replicas 1) 得到的就是master的数量。因此节点列表中的前n个就是master，其它节点都是slave节点，随机分配到不同master

输出命令后

通过命令可以查看集群状态：

redis-cli --cluster check 真实ip地址:6381

集群拓展和缩减,没有具体

#redis-cluster扩容
##新增主节点，第一个参数是新节点地址，第二参数是原集群中任意一个地址 
redis-cli --cluster add-node 127.0.0.1:6385  127.0.0.1:6379      
##新增子节点，该节点作为一个从节点角色加入原集群中，因为这里没有指定具体的主节点node_id，所以它将随机加入一个拥有较少的主节点中。。。
redis-cli --cluster add-node 127.0.0.1:6386  --cluster-slave    
##指定具体的mater,这里就执行了master的node_id，说明要加入这个节点中作为从节点。。
redis-cli --cluster add-node 127.0.0.1:7006 127.0.0.1:7000 --cluster-slave  --cluster-master-id 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e    。　　
##重新分配槽位，新增的redis没有槽位
redis-cli --cluster reshard 127.0.0.1:6379  　　
##重新均衡一下槽的顺序性
redis-cli --cluster rebalance  127.0.0.1:6379
#redis-cluster缩容
##redis缩容，首先要把要下线的节点的槽位数据移动到别的节点上，把第一个master-id卡槽移给第二个
redis-cli --cluster  reshard  192.168.1.100:7000  --cluster-from   d012cad6e1a23e4f24f9d31cf24afd4a25a3d69c  --cluster-to 2ab1403b76ba88a10cf375a7c818cee4886677b8  --cluster-slots 4096
##重新均衡一下槽的顺序性
redis-cli --cluster rebalance  127.0.0.1:6379
##remove 节点(这里一定要先走该节点的槽位上数据)
redis-cli --cluster del-node 127.0.0.1:7000 `<node-id>`

集群操作

redis-cli -c -p 7001

故障恢复

当某个主从关系，主节点断掉，子节点会升级为主节点

当之前挂掉的父节点再次恢复，会变成开始子节点（现在已经为主节点）的子节点

要想让子节点变成主节点；执行cluster failover命令

如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为yes ，那么，整个集群都挂掉
如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为no ，那么，该插槽数据全都不能使用，也无法存储。
redis.conf中的参数 cluster-require-full-coverage

优点

• 实现扩容
• 分摊压力
• 无中心配置相对简单

缺点

• 多键操作是不被支持的
• 多键的Redis事务是不被支持的。lua脚本不被支持 （没办法将多条指令封装执行）

• 由于集群方案出现较晚，很多公司已经采用了其他的集群方案，而代理或者客户端分片的方案想要迁移至redis cluster，需要整体迁移而不是逐步过渡，复杂度较大。

springBoot整合redis

https://gitee.com/Ivan-lsy/crm/tree/dev/redis

这篇好文章是转载于：学新通技术网