Redis基本类型与指令

Posted 2020-12-07 羽风

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Redis基本类型与指令相关的知识，希望对你有一定的参考价值。

1.全局key操作

全局key操作命令:忽略与key关联的value的类型

删
flushdb 清空当前选择的数据库

del mykey mykey2 删除了两个 Keys

改
move mysetkey 1 将当前数据库中的 mysetkey 键移入到 ID 为 1 的数据库中

rename mykey mykey1 将 mykey 改名为 mykey1

renamenx oldkey newkey 如果 newkey 已经存在，则无效

expire mykey 100 将该键的超时设置为 100 秒

persist mykey 将该 Key 的超时去掉,变成持久化的键

查
keys my* 获取当前数据库中所有以my开头的key

exists mykey 若不存在,返回0;存在返回1

select 0 打开 ID 为 0 的数据库

ttl mykey 查看存货时间还剩下多少秒

type mykey 返回mykey对应的值的类型

randomkey 返回数据库中的任意键

2.String（字符串）

string是redis最基本的类型，一个key对应一个value。

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

string类型是Redis最基本的数据类型，一个键最大能存储512MB。

增
set mykey "test" 为键设置新值，并覆盖原有值
getset mycounter 0 设置值,取值同时进行
setex mykey 10 "hello" 设置指定 Key 的过期时间为10秒,在存活时间可以获取value
setnx mykey "hello" 若该键不存在，则为键设置新值
mset key3 "stephen" key4 "liu" 批量设置键
删
del mykey 删除已有键
改
append mykey "hello" 若该键并不存在,返回当前 Value 的长度
该键已经存在，返回追加后 Value的长度
incr mykey 值增加1,若该key不存在,创建key,初始值设为0,增加后结果为1
decrby mykey 5 值减少5
setrange mykey 20 dd 把第21和22个字节,替换为dd, 超过value长度,自动补0

查
exists mykey 判断该键是否存在，存在返回 1，否则返回0
get mykey 获取Key对应的value
strlen mykey 获取指定 Key 的字符长度
ttl mykey 查看一下指定 Key 的剩余存活时间(秒数)
getrange mykey 1 20 获取第2到第20个字节,若20超过value长度,则截取第2个和后面所有的的
mget key3 key4 批量获取键

3.Hashes类型:(map<string,string>)

我们可以将Redis中的Hashes类型看成具有String Key和String Value的map容器。

所以该类型非常适合于存储值对象的信息。如Username、Password和Age等。如果Hash中包含很少的字段，那么该类型的数据也将仅占用很少的磁盘空间。

每一个Hash可以存储4294967295个键值对。

案例解释:
Map类型:
hset myhash field1 "s"

redis.key=myhash redis.value=( map.key=field1 map.value=s )

增
hset myhash field1 "s" 若字段field1不存在,创建该键及与其关联的Hashes, Hashes中,key为field1 ,并设value为s ，若字段field1存在,则无效

hsetnx myhash field1 s 若字段field1不存在,创建该键及与其关联的Hashes, Hashes中,key为field1 ,并设value为s，若字段field1存在,则无效

hmset myhash field1 "hello" field2 "world 一次性设置多个字段

删
hdel myhash field1 删除 myhash 键中字段名为 field1 的字段
del myhash 删除键

改
hincrby myhash field 1 给field的值加1

查
hget myhash field1 获取键值为 myhash,字段为 field1 的值

hlen myhash 获取myhash键的字段数量

hexists myhash field1 判断 myhash 键中是否存在字段名为 field1 的字段

hmget myhash field1 field2 field3 一次性获取多个字段

hgetall myhash 返回 myhash 键的所有字段及其值

hkeys myhash 获取myhash 键中所有字段的名字

hvals myhash 获取 myhash 键中所有字段的值

4.List类型

List类型是按照插入顺序排序的字符串链表。和数据结构中的普通链表一样，我们可以在其头部(left)和尾部(right)添加新的元素。在插入时，如果该键并不存在，Redis将为该键创建一个新的链表。与此相反，如果链表中所有的元素均被移除，那么该键也将会被从数据库中删除。

List中可以包含的最大元素数量是4294967295。

List类型:(链表:最后一个插入的元素,位置索引为o)
增
lpush mykey a b 若key不存在,创建该键及与其关联的List,依次插入a ,b，若List类型的key存在,则插入value中
lpushx mykey2 e 若key不存在,此命令无效，若key存在,则插入value中
linsert mykey before a a1 在 a 的前面插入新元素 a1
linsert mykey after e e2 在e 的后面插入新元素 e2

rpush mykey a b 在链表尾部先插入b,在插入a

rpushx mykey e 若key存在,在尾部插入e, 若key不存在,则无效

rpoplpush mykey mykey2 将mykey的尾部元素弹出,再插入到mykey2 的头部(原子性的操作)

删
del mykey 删除已有键

lrem mykey 2 a 从头部开始找,按先后顺序,值为a的元素,删除数量为2个,若存在第3个,则不删除

ltrim mykey 0 2 从头开始,索引为0,1,2的3个元素,其余全部删除

改
lset mykey 1 e 从头开始, 将索引为1的元素值,设置为新值 e,若索引越界,则返回错误信息

rpoplpush mykey mykey 将 mykey 中的尾部元素移到其头部

查
lrange mykey 0 -1 取链表中的全部元素，其中0表示第一个元素,-1表示最后一个元素。
lrange mykey 0 2 从头开始,取索引为0,1,2的元素
lrange mykey 0 0 从头开始,取第一个元素,从第0个开始,到第0个结束

lpop mykey 获取头部元素,并且弹出头部元素,出栈

lindex mykey 6 从头开始,获取索引为6的元素若下标越界,则返回nil

5.set类型

Set类型看作为没有排序的字符集合。Set可包含的最大元素数量是4294967295。
如果多次添加相同元素，Set中将仅保留该元素的一份拷贝。

增
sadd myset a b c 若key不存在,创建该键及与其关联的set,依次插入a ,b,若key存在,则插入value中,若a 在myset中已经存在,则插入了 d 和 e 两个新成员。
删
spop myset 尾部的b被移出,事实上b并不是之前插入的第一个或最后一个成员
srem myset a d f 若f不存在, 移出 a、d ,并返回2

改
smove myset myset2 a 将a从 myset 移到 myset2，

查
sismember myset a 判断 a 是否已经存在，返回值为 1 表示存在。

smembers myset 查看set中的内容

scard myset 获取Set 集合中元素的数量

srandmember myset 随机的返回某一成员

sdiff myset1 myset2 myset3 1和2得到一个结果,拿这个集合和3比较,获得每个独有的值
sdiffstore diffkey myset myset2 myset3 3个集和比较,获取独有的元素,并存入diffkey 关联的Set中

sinter myset myset2 myset3 获得3个集合中都有的元素
sinterstore interkey myset myset2 myset3 把交集存入interkey 关联的Set中

sunion myset myset2 myset3 获取3个集合中的成员的并集
sunionstore unionkey myset myset2 myset3 把并集存入unionkey 关联的Set中

6.Sorted-Sets类型

Sorted-Sets中的每一个成员都会有一个分数(score)与之关联，Redis正是通过分数来为集合中的成员进行从小到大的排序。成员是唯一的，但是分数(score)却是可以重复的。

分数:按分数高低排序
位置索引:分数最低的索引为0
增
zadd myzset 2 "two" 3 "three" 添加两个分数分别是 2 和 3 的两个成员

删
zrem myzset one two 删除多个成员变量,返回删除的数量

改
zincrby myzset 2 one 将成员 one 的分数增加 2，并返回该成员更新后的分数

查
zrange myzset 0 -1 WITHSCORES 返回所有成员和分数,不加WITHSCORES,只返回成员

zrank myzset one 获取成员one在Sorted-Set中的位置索引值。0表示第一个位置

zcard myzset 获取 myzset 键中成员的数量

zcount myzset 1 2 获取分数满足表达式 1 <= score <= 2 的成员的数量

zscore myzset three 获取成员 three 的分数

zrangebyscore myzset (1 2 获取分数满足表达式 1 < score <= 2 的成员

#-inf 表示第一个成员，+inf最后一个成员
#limit限制关键字
#2 3 是索引号
zrangebyscore myzset -inf +inf limit 2 3 返回索引是2和3的成员

zremrangebyscore myzset 1 2 删除分数 1<= score <= 2 的成员，并返回实际删除的数量

zremrangebyrank myzset 0 1 删除位置索引满足表达式 0 <= rank <= 1 的成员

zrevrange myzset 0 -1 WITHSCORES 按位置索引从高到低,获取所有成员和分数

#原始成员:位置索引从小到大
one 0
two 1
#执行顺序:把索引反转
位置索引:从大到小
one 1
two 0
#输出结果: two
one
zrevrange myzset 1 3 获取位置索引,为1,2,3的成员

#相反的顺序:从高到低的顺序
zrevrangebyscore myzset 3 0 获取分数 3>=score>=0的成员并以相反的顺序输出

zrevrangebyscore myzset 4 0 limit 1 2 获取索引是1和2的成员,并反转位置索引

//-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Redis持久化

RDB和AOF

Redis是一种高级key-value数据库。它跟memcached类似，不过数据可以持久化，而且支持的数据类型很丰富。有字符串，链表，集合和有序集合。支持在服务器端计算集合的并，交和补集(difference)等，还支持多种排序功能。所以Redis也可以被看成是一个数据结构服务器。
Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”)；也可以把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)。

由于Redis的数据都存放在内存中，如果没有配置持久化，redis重启后数据就全丢失了，于是需要开启redis的持久化功能，将数据保存到磁盘上，当redis重启后，可以从磁盘中恢复数据。redis提供两种方式进行持久化，一种是RDB持久化（原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化），另外一种是AOF（append only file）持久化（原理是将Reids的操作日志以追加的方式写入文件）。那么这两种持久化方式有什么区别呢，改如何选择呢？网上看了大多数都是介绍这两种方式怎么配置，怎么使用，就是没有介绍二者的区别，在什么应用场景下使用。

2、二者的区别

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。

AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

3、二者优缺点

RDB存在哪些优势呢？

1). 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。

2). 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。

3). 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。

4). 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

RDB又存在哪些劣势呢？

1). 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

2). 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

AOF的优势有哪些呢？

1). 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。

2). 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。

3). 如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。

4). AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

AOF的劣势有哪些呢？

1). 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

2). 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。rdb这个就更有些 eventually consistent的意思了。

4、常用配置

RDB持久化配置

Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息：

save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。

save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。

save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。

而RDB持久化也分两种：SAVE和BGSAVE

SAVE是阻塞式的RDB持久化，当执行这个命令时redis的主进程把内存里的数据库状态写入到RDB文件（即上面的dump.rdb）中，直到该文件创建完毕的这段时间内redis将不能处理任何命令请求。

BGSAVE属于非阻塞式的持久化，它会创建一个子进程专门去把内存中的数据库状态写入RDB文件里，同时主进程还可以处理来自客户端的命令请求。但子进程基本是复制的父进程，这等于两个相同大小的redis进程在系统上运行，会造成内存使用率的大幅增加。

AOF持久化配置

在Redis的配置文件中存在三种同步方式，它们分别是：

appendfsync always #每次有数据修改发生时都会写入AOF文件。

appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。

appendfsync no #从不同步。高效但是数据不会被持久化。

Redis事务

1. Redis事务的概念

可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序串行化的执行而不会被其他命令插入

一个队列中，一次性、顺序性、排他性的执行一系列命令

3. watch 监控

悲观锁：顾名思义很悲观，每次去拿数据的时候都认为别人修改，所以每次在拿数据的时候都会上锁，这样如果中间有人想拿数据就会一直阻塞除非锁被释放获取到锁。传统的关系型数据库里，用到了很多种这种锁机制，比如行锁，表锁，写锁等

乐观锁：顾名思义很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量

watch监听一个key，当key有改动时，事务不提交，unwatch之后重新再watch此key，类似乐观锁，自旋锁，CAS（compare and swap）比较和替换

一旦EXEC命令执行，之前加的监控锁就会取消

小结一: 事务3阶段

开启：以MULTI 开启一个事务
入队：将多个命令入队到事务中，接到这些命令不会立即执行，而是放到等待执行的事务队列里面
执行：由EXEC命令触发事务

小结二：事务3特性

单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题
不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

redis事务并不是强一致性的，如果出现的是类似编译时异常，则事务回滚，如果出现的是运行时异常，则事务中只是单条命令不执行，其他的依然执行

Redis主从复制

读写分离与容灾恢复

配从不配主

info replication可以查看与复制相关的状态，了解主从节点的当前状态

命令 slaveOf 主机端口号（slaveof 127.0.0.1 6379）

主机挂掉-反客为主-命令 slaveof no one

复制原理

1、Slave启动成功连接到master后会发送一个sync命令；

2、Master接到命令启动后的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master

将传送整个数据文件到slave，以完成一次完全同步；

3、全量复制：而slave服务在数据库文件数据后，将其存盘并加载到内存中；

4、增量复制：Master继续将新的所有收集到的修改命令依次传给slave，完成同步；

5、但是只要是重新连接master，一次完全同步（全量复制）将被自动执行。

哨兵模式（sentinel）

反客为主的自动版，能够后台监控Master库是否故障，如果故障了根据投票数自动将slave库转换为主库。一组sentinel能

同时监控多个Master。

使用步骤：

1、在Master对应redis.conf同目录下新建sentinel.conf文件，名字绝对不能错；

2、配置哨兵，在sentinel.conf文件中填入内容：

sentinel monitor 被监控数据库名字（自己起名字） ip port 1

说明：上面最后一个数字1，表示主机挂掉后slave投票看让谁接替成为主机，得票数多少后成为主机。

3、启动哨兵模式：

命令键入：redis-sentinel /myredis/sentinel.conf

复制的缺点

延时，由于所有的写操作都是在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定

的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使得这个问题更加严重。

Redis缓存淘汰策略

常用的淘汰算法：

FIFO：First In First Out，先进先出。判断被存储的时间，离目前最远的数据优先被淘汰。
LRU：Least Recently Used，最近最少使用。判断最近被使用的时间，目前最远的数据优先被淘汰。
LFU：Least Frequently Used，最不经常使用。在一段时间内，数据被使用次数最少的，优先被淘汰。

6种数据淘汰策略：

volatile-lru：从已设置过期时间的数据中挑选最近最少使用的数据淘汰；
volatile-ttl：从已设置过期时间的数据中挑选将要过期的数据淘汰；
volatile-random：从已设置过期时间的数据中任意选择数据淘汰；
allkeys-lru：从数据集中挑选最近最少使用的数据淘汰；
allkeys-random：从数据集中任意选择数据淘汰；
no-enviction（驱逐）：禁止驱逐数据

注意这里的6种机制，volatile和allkeys规定了是对已设置过期时间的数据集淘汰数据还是从全部数据集淘汰数据，后面的lru、ttl以及random是三种不同的淘汰策略，再加上一种no-enviction永不回收的策略。

建议使用策略规则：
　* 1、如果数据呈现幂律分布，也就是一部分数据访问频率高，一部分数据访问频率低，则使用allkeys-lru
　* 2、如果数据呈现平等分布，也就是所有的数据访问频率都相同，则使用allkeys-random

三种数据淘汰策略:

ttl
random
lru

redis雪崩，击穿与穿透

缓存穿透
缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。

解决方案
有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法，如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

缓存雪崩
缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。

解决方案
缓存失效时的雪崩效应对底层系统的冲击非常可怕。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。这里分享一个简单方案就是将缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

缓存击穿
对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据，这个时候，需要考虑一个问题：缓存被“击穿”的问题，这个和缓存雪崩的区别在于这里针对某一key缓存，前者则是很多key。缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

解决方案
使用互斥锁(mutex key)

业界比较常用的做法，是使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。

public String get(key) {
String value = redis.get(key);
if (value == null) { //代表缓存值过期
//设置3min的超时，防止del操作失败的时候，下次缓存过期一直不能load db
String keynx = key.concat(":nx");
if (redis.setnx(keynx, 1, 3 * 60) == 1) { //代表设置成功
value = db.get(key);
redis.set(key, value, expire_secs);
redis.del(keynx);
} else {
//这个时候代表同时候的其他线程已经load db并回设到缓存了，这时候重试获取缓存值即可
sleep(50);
get(key); //重试
}
} else {
return value;
}
}