1、config 命令实现动态修改配置

config 命令用于查看当前redis配置、以及不重启redis服务实现动态更改redis配置等。

不是所有配置都可以动态修改，且此方式无法持久保存。

CONFIG SET parameter value
时间复杂度：O(1)
CONFIG SET 命令可以动态地调整 Redis 服务器的配置(configuration)而无须重启。

可以使用它修改配置参数，或者改变 Redis 的持久化(Persistence)方式。
CONFIG SET 可以修改的配置参数可以使用命令 CONFIG GET * 来列出，所有被 CONFIG SET 修改的配置参数都会立即生效。

CONFIG GET parameter
时间复杂度： O(N)，其中 N 为命令返回的配置选项数量。
CONFIG GET 命令用于取得运行中的 Redis 服务器的配置参数(configuration parameters)，在
Redis 2.4 版本中， 有部分参数没有办法用 CONFIG GET 访问，但是在最新的 Redis 2.6 版本中，所有配置参数都已经可以用 CONFIG GET 访问了。

CONFIG GET 接受单个参数 parameter 作为搜索关键字，查找所有匹配的配置参数，其中参数和值以“键-值对”(key-value pairs)的方式排列。
比如执行 CONFIG GET s* 命令，服务器就会返回所有以 s 开头的配置参数及参数的值

# 设置客户端连接密码
# 设置连接密码
127.0.0.1:6379> CONFIG set requirepass 123456
OK


# 查看连接密码
127.0.0.1:6379> CONFIG GET requirepass
1) "requirepass"
2) "123456"

# 获取当前配置
# 奇数行为键，偶数行为值

127.0.0.1:6379> CONFIG GET *
  1) "rdbchecksum"
  2) "yes"
  3) "daemonize"
  4) "no"
  5) "io-threads-do-reads"
  6) "no"
  7) "lua-replicate-commands"
  8) "yes"
  9) "always-show-logo"
 10) "no"
 11) "protected-mode"
 12) "yes"
 13) "rdbcompression"
 14) "yes"
 15) "rdb-del-sync-files"
 16) "no"
 17) "activerehashing"
 18) "yes"
 19) "stop-writes-on-bgsave-error"
 20) "yes"

#查看bind
127.0.0.1:6379> CONFIG GET bind
1) "bind"
2) "127.0.0.1 -::1"

# 设置Redis使用的最大内存量
127.0.0.1:6379> CONFIG GET maxmemory
1) "maxmemory"
2) "0"
127.0.0.1:6379> CONFIG SET maxmemory 2147483648
OK
127.0.0.1:6379> CONFIG GET maxmemory
1) "maxmemory"
2) "2147483648"

2、慢查询

vim /etc/redis.conf
slowlog-log-slower-than 1    #指定超过1us即为慢的指令，默认值为10000us
slowlog-max-len 1024         #指定只保存最近的1024条慢记录，默认值为128

127.0.0.1:6379> SLOWLOG LEN  #查看慢日志的记录条数
(integer) 14
127.0.0.1:6379> SLOWLOG GET [n] #查看慢日志的n条记录
1) 1) (integer) 14
2) (integer) 1544690617
3) (integer) 4                #第3)行表示每条指令的执行时长
4) 1) "slowlog"
127.0.0.1:6379> SLOWLOG GET 3
1) 1) (integer) 7
   2) (integer) 1602901545
   3) (integer) 26
   4) 1) "SLOWLOG"
      2) "get"
   5) "127.0.0.1:38258"
   6) ""
2) 1) (integer) 6
   2) (integer) 1602901540
   3) (integer) 22
   4) 1) "SLOWLOG"
      2) "get"
      3) "2"
   5) "127.0.0.1:38258"
   6) ""
3) 1) (integer) 5
   2) (integer) 1602901497
   3) (integer) 22
   4) 1) "SLOWLOG"
      2) "GET"
   5) "127.0.0.1:38258"
   6) ""
127.0.0.1:6379> SLOWLOG RESET #清空慢日志
OK

3、Redis 持久化

Redis 是基于内存型的NoSQL，和MySQL是不同的,使用内存进行数据保存

如果想实现数据的持久化，Redis也也可支持将内存数据保存到硬盘文件中

Redis支持两种数据持久化保存方法

RDB：Redis DataBase
AOF：AppendOnlyFile

3.1、RDB

RDB(Redis DataBase)：是基于某个时间点的快照，注意RDB只保留当前最新版本的一个快照

RDB 持久化功能所生成的 RDB 文件是一个经过压缩的二进制文件，通过该文件可以还原生成该 RDB 文件时数据库的状态。因为 RDB 文件是保存在磁盘中的，所以即便 Redis 服务进程甚至服务器宕机，只要磁盘中 RDB 文件存在，就能将数据恢复。

RDB bgsave 实现快照的具体过程：

首先从redis 主进程先fork生成一个新的子进程,此子进程负责将Redis内存数据保存为一个临时文件tmp- <子进程pid>.rdb，当数据保存完成后,再将此临时文件改名为RDB文件,如果有前一次保存的RDB文件则会被替换，最后关闭此子进程。

由于Redis只保留最后一个版本的RDB文件，如果想实现保存多个版本的数据,需要人为实现。

# RDB 相关配置
# 在配置文件中的 save 选项设置多个保存条件，只有任何一个条件满足，服务器都会自动执行 BGSAVE 命令
save 900 1         # 900s内修改了1个key即触发保存RDB
save 300 10        # 300s内修改了10个key即触发保存RDB
save 60 10000      # 60s内修改了10000个key即触发保存RDB
dbfilename dump.rdb
dir ./
# 编泽编译安装时默认RDB文件存放在Redis的工作目录,此配置可指定保存的数据目录

stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes

实现 RDB 方法

save：同步,不推荐使用，使用主进程完成快照，因此会阻赛其它命令执行
bgsave：异步后台执行,不影响其它命令的执行，会开启独立的子进程，因此不会阻赛其它命令执行
配置文件实现自动保存：在配置文件中制定规则，自动执行bgsave

RDB 模式优点

RDB快照只保存某个时间点的数据，恢复的时候直接加载到内存即可，不用做其他处理，这种文件适合用于做灾备处理。可以通过自定义时间点执行redis指令bgsave或者save保存快照，实现多个版本的备份。比如：可以在最近的24小时内，每小时备份一次RDB文件，并且在每个月的每一天，也备份一个RDB文件。这样的话，即使遇上问题，也可以随时将数据集还原到指定的不同的版本。
RDB在大数据集时恢复的速度比AOF方式要快

RDB 模式缺点

不能实时保存数据，可能会丢失自上一次执行RDB备份到当前的内存数据。如果需要尽量避免在服务器故障时丢失数据，那么RDB并不适合。虽然Redis允许设置不同的保存点（save point）来控制保存RDB文件的频率，但是，因为RDB文件需要保存整个数据集的状态，所以它可能并不是一个非常快速的操作。因此一般会超过5分钟以上才保存一次RDB文件。在这种情况下，一旦发生故障停机，就可能会丢失较长时间的数据。
在数据集比较庞大时，fork()子进程可能会非常耗时，造成服务器在一定时间内停止处理客户端请求,如果数据集非常巨大，并且CPU时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒或更久。另外子进程完成生成RDB文件的时间也会花更长时间。

# 手动备份RDB文件的脚本
[root@redis01 ~]# vim /apps/redis/etc/redis.conf
save ""
dbfilename dump_6379.rdb
dir "/data/redis"
appendonly no


[root@redis01 ~]# vim redis_backup_rdb.sh

#!/bin/bash

BACKUP=/backup/redis-rdb
DIR=/apps/redis/data
FILE=dump.rdb
PASS=123456

color () {
    RES_COL=60
    MOVE_TO_COL="echo -en \\033[${RES_COL}G"
    SETCOLOR_SUCCESS="echo -en \\033[1;32m"
    SETCOLOR_FAILURE="echo -en \\033[1;31m"
    SETCOLOR_WARNING="echo -en \\033[1;33m"
    SETCOLOR_NORMAL="echo -en \E[0m"
    echo -n "$1" && $MOVE_TO_COL
    echo -n "["
    if [ $2 = "success" -o $2 = "0" ] ;then
        ${SETCOLOR_SUCCESS}
        echo -n $"  OK  "
    elif [ $2 = "failure" -o $2 = "1"  ] ;then
        ${SETCOLOR_FAILURE}
        echo -n $"FAILED"
    else
        ${SETCOLOR_WARNING}
        echo -n $"WARNING"
    fi
    ${SETCOLOR_NORMAL}
    echo -n "]"
    echo
}

redis-cli -h 127.0.0.1 -a $PASS --no-auth-warning  bgsave
result=`redis-cli -a $PASS --no-auth-warning info Persistence |grep rdb_bgsave_in_progress| sed -rn 's/.*:([0-9]+).*/\1/p'`
until  [ $result -eq 0 ] ;do
    sleep 1
    result=`redis-cli -a $PASS --no-auth-warning info Persistence |grep rdb_bgsave_in_progress| sed -rn 's/.*:([0-9]+).*/\1/p'`
done
DATE=`date +%F_%H-%M-%S`

[ -e $BACKUP ] || { mkdir -p $BACKUP ; chown -R redis.redis $BACKUP; }
cp $DIR/$FILE $BACKUP/dump-${DATE}.rdb

color "Backup redis RDB" 0



[root@redis01 ~]# bash redis_backup_rdb.sh;ll /apps/redis/data/;ll /backup/redis-rdb/
Background saving started
Backup redis RDB                                           [  OK  ]
total 4
-rw-r--r-- 1 redis redis 1582 Nov 26 06:42 dump.rdb
total 8
-rw-r--r-- 1 root root 1582 Nov 26 06:42 dump-2022-11-26_06-42-16.rdb
-rw-r--r-- 1 root root 1582 Nov 26 06:42 dump-2022-11-26_06-42-32.rdb

# 阻塞
# 生成临时文件
(redis-cli -a 123456 save &) ; echo save is finished; redis-cli -a 123456 get class

vim /apps/redis/etc/redis.conf
save 60 3

#测试60s内修改3个key,验证是否生成RDB文件

3.2、AOF

AOF 即 AppendOnlyFile，AOF 和 RDB 都采有COW机制，AOF可以指定不同的保存策略,默认为每秒钟执行一次 fsync，按照操作的顺序地将变更命令追加至指定的AOF日志文件尾部。
在第一次启用AOF功能时，会做一次完全备份，后续将执行增量性备份，相当于完全数据备份+增量变化。
如果同时启用RDB和AOF，进行恢复时，默认AOF文件优先级高于RDB文件，即会使用AOF文件进行恢复。
在第一次开启AOF功能时，会自动备份所有数据到AOF文件中，后续只会记录数据的更新指令。

AOF 模式默认是关闭的，第一次开启AOF后，并重启服务生效后，会因为AOF的优先级高于RDB，而AOF默认没有数据文件存在，从而导致所有数据丢失。

# 错误开启AOF功能,会导致数据丢失
127.0.0.1:6379> DBSIZE
(integer) 100

[root@redis01 ~]# vim /apps/redis/etc/redis.conf
appendonly yes

[root@redis01 ~]# systemctl restart redis.service

127.0.0.1:6379> DBSIZE
(integer) 0

# 正确启用AOF功能，访止数据丢失
[root@redis01 ~]# ll /apps/redis/data/
total 4
-rw-r--r-- 1 redis redis 1582 Nov 26 07:02 dump.rdb

127.0.0.1:6379> DBSIZE
(integer) 100

# 自动触发AOF重写,会自动备份所有数据到AOF文件
127.0.0.1:6379>  config get appendonly
1) "appendonly"
2) "no"
127.0.0.1:6379> config set appendonly  yes
OK

[root@redis01 ~]# ll /apps/redis/data/
total 8
-rw-r--r-- 1 redis redis 1582 Nov 26 07:03 appendonly.aof
-rw-r--r-- 1 redis redis 1582 Nov 26 07:02 dump.rdb

[root@redis01 ~]# vim /apps/redis/etc/redis.conf
appendonly yes

[root@redis01 ~]# systemctl restart redis.service
127.0.0.1:6379> DBSIZE
(integer) 100

# AOF 相关配置
appendonly no
# 是否开启AOF日志记录，默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了，但是redis如果中途宕机，会导致可能有几分钟的数据丢失(取决于dump数据的间隔时间)，根据save来策略进行持久化，Append Only File是另一种持久化方式，可以提供更好的持久化特性，Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件，每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件。默认不启用此功能

appendfilename "appendonly.aof"
# 文本文件AOF的文件名，存放在dir指令指定的目录中

appendfsync everysec
# aof持久化策略的配置
# no表示由操作系统保证数据同步到磁盘,Linux的默认fsync策略是30秒，最多会丢失30s的数据
# always表示每次写入都执行fsync，以保证数据同步到磁盘,安全性高,性能较差
# everysec表示每秒执行一次fsync，可能会导致丢失这1s数据,此为默认值,也生产建议值
dir /path

# rewrite相关
no-appendfsync-on-rewrite yes
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes

# 动态修改配置自动生成appendonly.aof文件
127.0.0.1:6379> CONFIG set appendonly yes

AOF rewrite 重写

将一些重复的,可以合并的，过期的数据重新写入一个新的AOF文件，从而节约AOF备份占用的硬盘空间,也
能加速恢复过程。
可以手动执行bgrewriteaof 触发AOF，第一次开启AOF功能，或定义自动rewrite 策略。

#  AOF rewrite 重写相关配置
# 同时在执行bgrewriteaof操作和主进程写aof文件的操作，两者都会操作磁盘，而bgrewriteaof往往会涉及大量磁盘操作，这样就会造成主进程在写aof文件的时候出现阻塞的情形,以下参数实现控制

no-appendfsync-on-rewrite no
# 在aof rewrite期间,是否对aof新记录的append暂缓使用文件同步策略,主要考虑磁盘IO开支和请求阻塞时间。
# 默认为no,表示"不暂缓",新的aof记录仍然会被立即同步到磁盘，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题
# 为yes,相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候redis挂掉，就会丢失数据。丢失多少数据呢？Linux的默认fsync策略是30秒，最多会丢失30s的数据,但由于yes性能较好而且会避免出现阻塞因此比较推荐

#rewrite 即对aof文件进行整理,将空闲空间回收,从而可以减少恢复数据时间
auto-aof-rewrite-percentage 100
#当Aof log增长超过指定百分比例时，重写AOF文件，设置为0表示不自动重写Aof日志，重写是为了使aof体积保持最小，但是还可以确保保存最完整的数据

auto-aof-rewrite-min-size 64mb
# 触发aof rewrite的最小文件大小

aof-load-truncated yes
# 是否加载由于某些原因导致的末尾异常的AOF文件(主进程被kill/断电等)，建议yes

# 手动执行AOF重写 BGREWRITEAOF 命令
BGREWRITEAOF
时间复杂度： O(N)， N 为要追加到 AOF 文件中的数据数量。
执行一个 AOF文件 重写操作。重写会创建一个当前 AOF 文件的体积优化版本。

即使 BGREWRITEAOF 执行失败，也不会有任何数据丢失，因为旧的 AOF 文件在 BGREWRITEAOF 成功之前不会被修改。

重写操作只会在没有其他持久化工作在后台执行时被触发，也就是说：
如果 Redis 的子进程正在执行快照的保存工作，那么 AOF 重写的操作会被预定(scheduled)，等到保存工作完成之后再执行 AOF 重写。在这种情况下， BGREWRITEAOF 的返回值仍然是 OK ，但还会加上一条额外的信息，说明 BGREWRITEAOF 要等到保存操作完成之后才能执行。在 Redis 2.6 或以上的版本，可以使用 INFO [section] 命令查看 BGREWRITEAOF 是否被预定。

如果已经有别的 AOF 文件重写在执行，那么 BGREWRITEAOF 返回一个错误，并且这个新的
BGREWRITEAOF 请求也不会被预定到下次执行。

从 Redis 2.4 开始， AOF 重写由 Redis 自行触发， BGREWRITEAOF 仅仅用于手动触发重写操作。

# 手动 bgrewriteaof
127.0.0.1:6379> BGREWRITEAOF

AOF 模式优点

数据安全性相对较高，根据所使用的fsync策略(fsync是同步内存中redis所有已经修改的文件到存储设备)，默认是appendfsync everysec，即每秒执行一次 fsync,在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据( fsync会在后台线程执行，所以主线程可以继续努力地处理命令请求)
由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中不需要seek, 即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，可以通过 redis-check-aof 工具来解决数据一致性的问题
Redis可以在 AOF文件体积变得过大时，自动地在后台对AOF进行重写,重写后的新AOF文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的，因为Redis在创建新 AOF文件的过程中，append模式不断的将修改数据追加到现有的 AOF文件里面，即使重写过程中发生停机，现有的 AOF文件也不会丢失。而一旦新AOF文件创建完毕，Redis就会从旧AOF文件切换到新AOF文件，并开始对新AOF文件进行追加操作。
AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，也可以通过该文
件完成数据的重建AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以Redis协议的格式保存，因此 AOF文件的内容非常容易被人读懂，对文件进行分析(parse)也很轻松。导出（export)AOF文件也非常简单:举个例子，如果不小心执行了FLUSHALL.命令，但只要AOF文件未被重写，那么只要停止服务器，移除 AOF文件末尾的FLUSHAL命令，并重启Redis ,就可以将数据集恢复到FLUSHALL执行之前的状态。

AOF 模式缺点