语法： SET key value [EX seconds] [PX milliseconds] [NX|XX]
用来设置字符串的键
EX seconds：过期时间

127.0.0.1:6379> SET name tangseng EX 20
OK
# 设置name键，值为tangseng ， 20s后过期

2.2 get

语法：GET key
显示键的值

127.0.0.1:6379> GET name
"tangseng"

2.3 keys

可以取符合规则的键值列表，通常情况可以结合*、?等选项来使用。

127.0.0.1:6379> set k1 1 
127.0.0.1:6379> set k2 2 
127.0.0.1:6379> set k3 3
127.0.0.1:6379> set v1 4
127.0.0.1:6379> set v5 5
127.0.0.1:6379> set v22 5



127.0.0.1:6379> KEYS *        #查看当前数据库中所有键
 1) "v5"
 2) "myset:__rand_int__"
 3) "v1"
 4) "counter:__rand_int__"
 5) "v22"
 6) "teacher"
 7) "k2"
 8) "mylist"
 9) "k3"
10) "key:__rand_int__"
11) "k1"

127.0.0.1:6379> KEYS v*       #查看当前数据库中以v开头的数据
1) "v5"
2) "v1"
3) "v22"

127.0.0.1:6379> KEYS v?       #查看当前数据库中以v开头后面包含任意一位的数据
1) "v5"
2) "v1"

2.4 exists

可以判断键值是否存在。
127.0.0.1:6379> exists teacher    #判断teacher 键是否存在
(integer) 1                       # 1表示teacher 键是存在
127.0.0.1:6379> exists tea
(integer) 0                       #0表示tea键不存在

2.5 del

可以删除当前数据库的指定key。
127.0.0.1:6379> keys *
127.0.0.1:6379> del v5 
(integer) 1
127.0.0.1:6379> get v5
(nil)

2.6 type

可以获取key对应的 value 值类型。
127.0.0.1:6379> type k1
string

2.7 rename

是对已有key进行重命名。 (覆盖)
命令格式: rename 源key  目标key
127.0.0.1:6379> keys v*
1) "v1"
2) "v22"
127.0.0.1:6379> rename v22 v2
OK
127.0.0.1:6379> keys v*
1) "v1"
2) "v2"
127.0.0.1:6379> get v1
"4"
127.0.0.1:6379> get v2
"5"
127.0.0.1:6379> rename v1 v2
127.0.0.1:6379> get v1
(nil)
127.0.0.1:6379> get v2
"4"

2.8 renamenx

rename n 不进行修改 x进行修改
nx 组合： 先判断 命令的作用是对已有key进行重命名，并检测新名是否存在，如果目标key存在则不进行重命名。 (不覆盖)
命令格式: renamenx 源key  目标key

127.0.0.1 :6379> keys *
127.0.0.1:6379> get teacher
"zhangsan"
127.0.0.1:6379> get v2
"4"
127.0.0.1:6379> renamenx v2 teacher
(integer) 0
127.0.0.1:6379> keys *
127.0.0.1 :6379> get teacher
"zhangsan"
127.0.0.1:6379> get v2
"4"

2.9 dbsize

作用是查看当前数据库中key的数目。
127.0.0.1:6379> dbsize
(integer) 9

3、设置密码

127.0.0.1:6379> config set requirepass 123456  设置密码

127.0.0.1:6379> auth 123456
127.0.0.1:6379> config get requirepass   查看密码

127.0.0.1:6379> auth 123123
127.0.0.1:6379> config set requirepass ''   删除密码

4、多数据库间命令

4.1 切换

命令格式: select 序号
使用 redis-cli 连接Redis数据库后，默认使用的是序号为 0 的数据库。
127.0.0.1:6379> select 10        #切换至序号为10的数据库

127.0.0.1:6379[10]> select 15    #切换至序号为15的数据库

127.0.0.1:6379[15]> select 0     #切换至序号为0的数据库

4.2 移动数据

格式: move  键值  序号

127.0.0.1:6379> set k1 100
OK
127.0.0.1:6379> get k1
"100"
127.0.0.1:6379> select 1
OK
127.0.0.1:6379[1]> get k1
(nil)
127.0.0.1:6379[1]> select 0    #切换至目标数据库0
OK
127.0.0.1:6379> get k1         #查看目标数据是否存在
"100"
127.0.0.1:6379> move k1 1      #将数据库0中k1移动到数据库1中
(integer) 1
127.0.0.1:6379> select 1       #切换至目标数据库1
OK
127.0.0.1:6379[1]> get k1      #查看被移动数据
"100"
127.0.0.1:6379[1]> select 0 
OK
127.0.0.1:6379> get k1         #在数据库0中无法查看到k1的值
(nil)

4.3 清除数据库内数据(rm -rf )

FLUSHDB  :清空当前数据库数据
FLUSHALL :清空所有数据库的数据，慎用!

5、 redis 远程数据备份（全量、增量）

是以Shell 脚本的形式
redis_backup.sh
#!/bin/bash 
TIME=$
BCDIR=
redis_server=
post
psword

二、Redis的持久化

1、RDB持久化

1.1 手动触发

save：该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。显然该命令对于内存比较大的实例会造成长时间阻塞，这是致命的缺陷，为了解决此问题，Redis提供了第二种方式。

bgsave：执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。

1.2 自动触发

在自动触发RDB持久化时，Redis也会选择bgsave而不是save来进行持久化。
save mn
自动触发最常见的情况是在配置文件中通过savemn，指定当m秒内发生n次变化时，会触发bgsave。

vim /etc/redis/6379.conf
219行--以下三个save条件满足任意一个时，都会引起bgsave的调用
save 9001:当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsave
save 30010:当时间到300秒时，如果redis数据发生了至少10次变化，则执行bgsave
save6010000:当时间到60秒时，如果redis数据发生了至少10000次变化，则执行bgsave
-242行--是否开启RDB文件压缩
rdbcompression yes
--254行--指定RDB文件名
dbfilename dump.rdb
--264行--指定RDB文件和AOF文件所在目录
dir /var/lib/redis/6379

1.3 其他自动触发机制

在主从复制场景下，，并将rdb文件发送给从节点。
执行shutdown命令时，自动执行rdb持久化。

1.4 启动时加载

仅当AOF功能关闭时，使用RDB进行恢复，同时前两者恢复手段中，一旦存在文件损坏的情况，redis将会打印错误并返回启动失败。

2、AOF持久化

2.1 开启AOF

Redis服务器默认开启RDB，关闭AOF:要开启AOF，需要在配置文件中配置:

vim /etc/redis/6379.conf
700行--修改， 开启AOF
appendonly yes
--704行--指定A0F文件名称
appendfilename "appendonly.aof"
--796行--是否忽略最后一条可能存在问题的指令
aof-load-truncated yes

2.2 执行流程

命令追加：Redis先将写命令追加到缓冲区，而不是直接写入文件，主要是为了避免每次有写命令都直接写入硬盘，导致硬盘IO成为Redis负载的瓶颈。

文件写入(write)和文件同步(sync)：Redis提供了多种AOF缓存区的同步文件策略，策略涉及到操作系统的write函数和fsync函数，说明如下：
为了提高文件写入效率，在现代操作系统中，当用户调用write函数将数据写入文件时，操作系统通常会将数据暂存到一个内存缓冲区里，当缓冲区被填满或超过了指定时限后，才真正将缓冲区的数据写入到硬盘里。这样的操作虽然提高了效率，但也带来了安全问题：如果计算机停机，内存缓冲区中的数据会丢失；因此系统同时提供了fsync、fdatasync等同步函数，可以强制操作系统立刻将缓冲区中的数据写入到硬盘里，从而确保数据的安全性。

同步文件策略：always：命令写入aof_buf后立即调用系统fsync操作同步到AOF文件，fsync完成后线程返回。这种情况下，每次有写命令都要同步到AOF文件，硬盘IO成为性能瓶颈，Redis只能支持大约几百TPS写入，严重降低了Redis的性能；即便是使用固态硬盘（SSD），每秒大约也只能处理几万个命令，而且会大大降低SSD的寿命。
no：命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步；同步由操作系统负责，通常同步周期为30秒。这种情况下，文件同步的时间不可控，且缓冲区中堆积的数据会很多，数据安全性无法保证。
everysec：命令写入aof_buf后调用系统write操作，write完成后线程返回；fsync同步文件操作由专门的线程每秒调用一次。everysec是前述两种策略的折中，是性能和数据安全性的平衡，因此是Redis的默认配置，也是我们推荐的配置。

文件重写：指定期重写AOF文件，减小AOF文件的体积。需要注意的是，AOF重写是把Redis进程内的数据转化为写命令，同步到新的AOF文件；不会对旧的AOF文件进行任何读取、写入操作。

2.3 文件重写的触发

手动触发：直接调用bgrewriteaof命令，该命令的执行与bgsave有些类似：都是fork子进程进行具体的工作，且都只有在fork时阻塞。

自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数，以及aof_current_size和aof_base_size状态确定触发时机。

3、不同的持久化机制都有什么优缺点

3.1 RDB持久化

优点：RDB文件紧凑，体积小，网络传输快，适合全量复制;恢复速度比AOF快很多。当然，与AOF相比，RDB最重要的优点之一是对性能的影响相对较小。

缺点：RDB文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化，而在数据越来越重要的今天，数据的大量丢失很多时候是无法接受的，因此AOF持久化成为主流。RDB文件需要满足特定格式，兼容性差(如老版本的Redis不兼容新版本的RDB文件)。对于RDB持久化，一方面是bgsave在进行fork操作时Redis主进程会阻塞，另一方面，子进程向硬盘写数据也会带来Io压力。

3.2 AOF持久化

优点：在于支持秒级持久化、兼容性好，缺点是文件大、恢复速度慢、对性能影响大。

缺点：向硬盘写数据的频率大大提高(everysec策略下为秒级)，Io压力更大，甚至可能造成AOF追加阻塞问题。AOF文件的重写与RDB的bgsave类似，会有fork时的阻塞和子进程的I0压力问题。相对来说，由于AOF向硬盘中写数据的频率更高，因此对Redis主进程
性能的影响会更大。

4、持久化功能

Redis为了内部数据的安全考虑，会把本身的数据以文件的形式保存在硬盘中一份，在重启之后会自动把硬盘的数据恢复到内存（redis）里面。

5、RDB持久化和AOF持久化区别

5.1 实现方式

RDB持久化是通过将某个时间点Redis服务器存储的数据保存到RDB文件中来实现持久化的。
AOF持久化是通过将Redis服务器执行的所有写命令保存到AOF文件中来实现持久化的。

5.2 文件体积

由以上实现方式可知，RDB持久化记录的是结果，AOF持久化记录的是过程，所以AOF持久化生成的AOF文件会有体积越来越大的问题，Redis提供了AOF重写功能来减小AOF文件体积。

5.3 安全性

AOF持久化的安全性要比RDB持久化的安全性高，即如果发生机器故障，AOF持久化要比RDB持久化丢失的数据要少。
因为RDB持久化会丢失上次RDB持久化后写入的数据，而AOF持久化最多丢失1s之内写入的数据(使用默认everysec配置的话)。

5.4 优先级

由于以上的安全性问题，如果Redis服务器开启了AOF持久化功能， Redis服务器在启动时会使用AOF文件来还原数据，如果Redis服务器没有开启AOF持久化功能，Redis服务器在启动时会使用RDB文件来还原数据，所以AOF文件的优先级比RDB文件的优先级高。

三、redis性能管理

1、查看Redis内存使用

192.168.73.30:6379> info memory

2、内存碎片率

操作系统分配的内存值used memory-rss除以Redis使用的内存值used memoryi计算得出内存碎片是由操作系统低效的分配/回收物理内存导致的(不连续的物理内存分配)

#跟踪内存碎片率对理解Redis实例的资源性能是非常重要的;

内存碎片率稍大于1是合理的,这个值表示内存碎片率比较低

内存碎片率超过1.5,说明Redis消耗了实际需要物理内存的150号,其中50%是内存碎片率。需要在redis-cli工具上输入shutdown save命令,并重启Redis服务器。

内存碎片率低于1的,说明Redis内存分配超出了物理内存,操作系统正在进行内存交换。需要增加可用物理内存或减少Redis内存占用。

3、内存使用率

redis实例的内存使用率超过可用最大内存,操作系统将开始进行内存与swap空间交换。

#避免内存交换发生的方法:

针对缓存数据大小选择安装Redis实例

尽可能的使用Hash数据结构存储

设置key的过期时间

4、内回收key

内存清理策略,保证合理分配redis有限的内存资源

当达到设置的最大阀值时,需选择一种key的回收策略,默认情况下回收策略是禁止删除。

配置文件中修改maxmemory-policy属性值

vim /etc/redis/6379.conf
 
--598--
 
maxmemory-policy noenviction
 
volatile-lru:使用LRU算法从已设置过期时间的数据集合中淘汰数据(移除最近最少使用的key,针对设置了TTL的key)
 
volatile-ttl:从已设置过期时间的数据集合中挑选即将过期的数据淘汰(移除最近过期的key)
 
volatile-random:从已设置过期时间的数据集合中随机挑选数据淘汰(在设置了TTL的key里随机移除)
 
allkeys-lru:使用LRU算法从所有数据集合中淘汰数据(移除最少使用的key,针对所有的key)
 
allkeys-random:从数据集合中任意选择数据淘汰(随机移除key)
 
noenviction:禁止淘汰数据(不删除直到写满时报错)

总结

RDB持久化和AOF持久化的优缺点和区别

redis性能管理和常用命令

原文链接：https://blog.csdn.net/HB199753/article/details/121228380

前言

一、Redis的数据结构

1、数据结构分类

2、各种数据结构常用的命令操作

2.1 set