redis再入

小灰灰 2022-10-25 12:51 85阅读 0赞

### 目录 ###

*  string
 *   *  索引
 *  hash
 *  list
 *  set
 *  zset
 *  事务
 *  乐观锁
 *  Lua 脚本
 *  其它命令
 *  巨人的肩膀
 *  VChat

--------------------

# string #

储存文字、数字或者二进制数据

## 索引 ##

字符串的索引（index）以 0 为开始，从字符串的开头向字符串的结尾依次递增，字符串第一个字符的索引为 0 ，字符串最后一个字符的索引 为 N-1 ，其中 N 为字符串的长度。

除了（正数）索引之外，字符串 还有负数索引：负数索引以 -1 为开始，从字符串的结尾向字符串的开头依次递减，字符串的最后一个字符的索引 为 -N ，其中 N 为字符串的长度。

![在这里插入图片描述][20210131180937860.png]

二进制位的索引

当字符串键储存的是二进制位时，二进制位的索引会从左到右依次递减。  
![在这里插入图片描述][20210131181526304.png]

<table> 
 <thead> 
  <tr> 
   <th>命令</th> 
   <th>含义</th> 
   <th>时间复杂度</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>SETBIT key index value</td> 
   <td>将给定索引上的二进制位的值设置为 value ，命令返回被设置的位原来储存的旧值</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>GETBIT key index</td> 
   <td>获取二进制位的值</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>BITCOUNT key [start] [end]</td> 
   <td>计算并返回特定索引范围的位上被设置为 1 的二进制位的数量</td> 
   <td>O(N)</td> 
  </tr> 
  <tr> 
   <td>BITOP operation destkey key [key …]</td> 
   <td>二进制位运算(AND 逻辑并、 OR逻辑或 、 NOT逻辑非 、 XOR逻辑异或)</td> 
   <td>O(N)</td> 
  </tr> 
 </tbody> 
</table>

> 应用场景
> 
>  *  计数器（counter）
>  *  id 生成器
>  *  在线人数统计
>  *  缓存热门图片

# hash #

<table> 
 <thead> 
  <tr> 
   <th>命令</th> 
   <th>含义</th> 
   <th>时间复杂度</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>HLEN key</td> 
   <td>返回字段的数量</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>HSCAN key cursor [MATCH pattern] [COUNT count]</td> 
   <td>迭代哈希表中的键值对</td> 
   <td>O(1) ~O(N)</td> 
  </tr> 
 </tbody> 
</table>

Redis中的哈希散列是一个string类型的field和value的映射表，它的增删操作的复杂度平均为O(1)。为什么平均是O(1)呢？因为哈希的内部结构包含zipmap和hash两种。hash适合存储对象，相对于对象序列化存储为string字符串类型，将对象存储在hash哈希类型中会占用更少的内存。zipmap本身并不是hashtable，由于zip压缩后可以节省hash本身所需的元数据的开销。因此zipmap的增删改查的操作复杂度为O(n)。但是域字段field的数量不多，所以说平均是O(1)。那么，为什么会占用更好的内存呢？因为对象刚开始使用的是zipmap存储的。

在新建一个哈希的时候，使用的是zipmap又称为small hash存储的。这个zipmap实际上不是我们的哈希表。但是这个zipmap相比正常的哈希实现，节省很多哈希自身所需要的元数据的存储开销。尽管zipmap的增删改查和字段的数目相关，字段太多速度会更慢。因此不建议设置过多的字段。在Redis内部，如果字段过多或者存储的值太大超过限制后，Redis会自动将zipmap替换为正常的hash来实现。

在域字段field的数量在限制范围内，并且字段值value的长度大小系统限定的字节数，此时哈希类型是用zipmap存储的，所以会比较节省内存空间。

# list #

每个值按照它们被推入到list的位置来排列。

每个列表项所处的位置决定了这个项的索引值（index），索引以 0 为开始，从列表的左端到右端依次 递增，位于列表最左端（表 头）的项的索引为 0 ，而位于列表最右端（表尾）的 项的索引为 N-1 ，其中 N 为列表的长度。

![在这里插入图片描述][20210131190734172.png]

> 应用场景
> 
>  *  实现用户时间线
>  *  定长先进先出队列
>  *  构建消息队列

# set #

<table> 
 <thead> 
  <tr> 
   <th>命令</th> 
   <th>含义</th> 
   <th>时间复杂度</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>SISMEMBER key element</td> 
   <td>检查给定元素是否存在于集合</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>SCARD key</td> 
   <td>返回集合包含的元素数量（也即是集合的基数），当集合的基数比较大时，执行这个命令有可能会㐀成服 务器阻塞</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>SMEMBERS key</td> 
   <td>返回集合包含的所有元素</td> 
   <td>O(N)</td> 
  </tr> 
  <tr> 
   <td>SPOP key</td> 
   <td>从集合里面随机地弹出一个元素</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>SRANDMEMBER key [count]</td> 
   <td>从集合里面随机地返回元素。如果没有给定可选的 count 参数，那么命令随机地返回集合中的一个元素。如果给定了 count 参数，那么：①当 count 为正数，并且少于集合基数 时，命令返回一个包含 count 个元素的数组，数组中的每个元素各不相同。如果 count 大于或等于集合基数，那么命令返回整个集合。②当 count 为负数时，命令返回一个数组，数组中的元素可能会重复出现多次，而数组的长度为count 的绝对值。</td> 
   <td>O(N)</td> 
  </tr> 
  <tr> 
   <td>SDIFF key [key …]</td> 
   <td>差集运算：计算所有给定集合的差集，并返回结果。</td> 
   <td>O(N)</td> 
  </tr> 
  <tr> 
   <td>SDIFFSTORE destkey key [key …]</td> 
   <td>差集运算：计算所有给定集合的差集，并将结果储存到 destkey</td> 
   <td>O(N)</td> 
  </tr> 
  <tr> 
   <td>SINTER key [key …]</td> 
   <td>交集运算：计算所有给定集合的交集，并返回结果。</td> 
   <td>O(N * M)， N 为给定集合当中基数最小的集合， M 为给定集合的个数。</td> 
  </tr> 
  <tr> 
   <td>SINTERSTORE destkey key [key …]</td> 
   <td>交集运算：计算所有给定集合的交集，并将结果储存到 destkey</td> 
   <td>O(N * M)，N 为给定集合当中基数最小的集合， M 为给定集合的个数。</td> 
  </tr> 
  <tr> 
   <td>SUNION key [key …]</td> 
   <td>并集运算：计算所有给定集合的并集</td> 
   <td>O(N)</td> 
  </tr> 
  <tr> 
   <td>SUNIONSTORE destkey key [key …]</td> 
   <td>并集运算：计算所有给定集合的并集，并将结果储存到 destkey</td> 
   <td>O(N)</td> 
  </tr> 
 </tbody> 
</table>

> 应用场景
> 
>  *  赞、喜欢、Like、投票、签到……
>  *  标签功能
>  *  抽奖系统
>  *  使用集合实现共同关注功能
>  *  商品筛选功能

# zset #

<table> 
 <thead> 
  <tr> 
   <th>命令</th> 
   <th>含义</th> 
   <th>时间复杂度</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>ZRANK key element</td> 
   <td>返回元素的排名（rank），其中 排名按照元素的分值从小到大计算</td> 
   <td>O(log(N))</td> 
  </tr> 
  <tr> 
   <td>ZREVRANK key member</td> 
   <td>返回元素的逆序排名（reverse rank），其中 排名按照元素的分值从大到小计算</td> 
   <td>O(log(N))</td> 
  </tr> 
  <tr> 
   <td>ZUNIONSTORE destkey numkeys key [key …]</td> 
   <td>计算并集</td> 
   <td>O(N)+O(M log(M))， N 为参与并集计算的元素数量， M 为结果集的基数</td> 
  </tr> 
  <tr> 
   <td>ZINTERSTORE destkey numkeys key [key …]</td> 
   <td>计算交集</td> 
   <td>O(N<em>K)+O(M</em>log(M))， N 为给定有序集合中，基数最小的有序集合的基数， K 为给定有序集合的数量， M 为 结果集的基数。</td> 
  </tr> 
 </tbody> 
</table>

> 应用场景
> 
>  *  排行榜
>  *  分页功能
>  *  自动补完（auto complete），使用有序集合来储存提示列表
>  *  使用并集计算实现周榜、月榜、年榜

# 事务 #

Redis 的事务功能允许用户将多个命令包裹起来，然后一次性地、按 顺序地执行被包裹的所有命令， 并且确保事务中的命令要么就全部都 执行，要么就一个都不执行。

在事务执行的过程中，服务器不会中断事务而改去执行其他命令请求，只有在事务包裹的所有命令都被执行完毕之后，服务器才会去处理其他命令请求。

<table> 
 <thead> 
  <tr> 
   <th>命令</th> 
   <th>作用</th> 
   <th>时间复杂度</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>MULTI</td> 
   <td>开始一个新的事务。在这个命令执行之后，客户端发送的所有针对数据库或者数据库键的命令都不会被立即执行，而是被放入到一个事务队列里面，并返回 QUEUED 表示命令已入队。</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>DISCARD</td> 
   <td>放弃事务。取消事务，放弃执行事务队列中的所有命令</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>EXEC</td> 
   <td>执行事务中的所有命令。按照命令被入队到事务队列中的顺序，执行事务队列中的所有命令。命令的返回值是一个列表，列表里包含了事 务队列中所有被执行命令的返回值。</td> 
   <td>队列中所有命令的复杂度之和</td> 
  </tr> 
 </tbody> 
</table>

> pipeline和事务的区别
> 
>  *  pipeline：确保多条命令会被一起 发送
>  *  事务：确保多条命令会被一起 执行

# 乐观锁 #

事务可以确保命令的安全性，但有时候只使用事务还是无法保证数据的正确性， 这时候就需要使用 Redis 提供的乐观锁功能（Optimistic Locking）

<table> 
 <thead> 
  <tr> 
   <th>命令</th> 
   <th>含义</th> 
   <th>时间复杂度</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>WATCH key [key …]</td> 
   <td>监视一个(或多个) key ，如果被监视的键在事务提交之前（也即是 EXEC 命令执行之前）， 已经被其他客户端抢先修改了， 那么服务器将拒绝执行客户端提交的事务， 并返回 nil 作为事务的回复</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>UNWATCH</td> 
   <td>取消对所有键的监视</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>DISCARD</td> 
   <td>放弃执行事务，如果正在使用 WATCH 命令监视某个(或某些) key，那么取消所有监视，等同于执行命令 UNWATCH</td> 
   <td>O(1)</td> 
  </tr> 
 </tbody> 
</table>

乐观锁会对被加锁的数据进行监视，多个客户端可以同时尝试对数据进行修改，其中最先尝试的客户端会成功，而之后尝试的客户端则会失败。

悲观锁只让一个客户端对数据进行修改，而其他客户端则需要等待正在进行修改的客户端执行完毕之后，才能尝试获得修改权。

对于频繁进行读写操作的 Redis 来说，使用乐观锁可以避免客户端被阻塞：当一个客户端修改数据失败之后，它只要重试就可以了，这个过程不需要进行任何的等待。

# Lua 脚本 #

1.  pipeline的缺陷  
    尽管使用流水线可以一次发送多个命令，但是对于一个由多个命令组成的复杂操作来说，为了执行该操作而不断地重复发送相同的命令，这并不是最高效的做法，会 对网络资源造成浪费。
2.  事务的缺陷  
    对于一个复杂的事务来说，通常需要仔细思考才能知道应该对哪些键进行加锁：锁了不应该锁的键会增加事务失败的机会，甚至可能会造成程序出 错；而忘了对应该锁的键进行加锁的话，程序又会产生 竞争条件。
3.  乐观锁的缺陷  
    有时候为了防止竞争条件发生，即使操作本身不需要用到事 务，但是为了让乐观锁生效，我们也会使用事务将命令包裹起来，这增加了实现的复杂度，并且带来了额外的性能损耗。

为了解决以上提到的问题， Redis 从 2.6 版本开始在服务器内部嵌入了一个 Lua 解释器，使得用户可以在服务器端执行 Lua 脚本。

这个功能有以下好处：

1.  使用脚本可以直接在服 务器端执行 Redis 命令，一般的数据处理操作可以直接使用Lua 语言或者Lua 解释器提供的函数库来完成，不必再返回给客户端进行处理。
2.  所有脚本都是以事务的形式来执行的，脚本在执行过程中不会被其他工作打断，也不会引起任何 竞争条件，完全可以使用 Lua 脚本来代替事务和乐观锁。
3.  所有脚本都是可重用的，也即是 说，重复执行相同的操作时，只要调用储存在服务器内部的脚本缓存就可以了，不用重新 发送整个脚本，从而尽可能地 节约网络资源。

>     EVAL script numkeys key [key …] arg [arg …]
> 
> 在 Lua 脚本中，可以使用两个不同函数来执行 Redis 命令，它们分别是：
> 
>  *  redis.call()：当被执行的脚本出错时，会返回出错脚本的名字以及 EVAL 命令的错误信息
>  *  redis.pcall()：当被执行的脚本出错时，只返回 EVAL 命令的错 误信息
> 
>   
>   
>   
>   
> 
> 
>     EVALSHA sha1 numkeys key [key …] arg [arg …]
> 
> EVAL 命令要求你在每次执行脚本的时候都发送一次脚本主体(script body)。Redis 有一个内部的缓存机制，因此它不会每次都重新编译脚本，不过在很多场合，付出无谓的带宽来传送脚本主体并不是最佳选择。
> 
> 为了减少带宽的消耗， Redis 实现了 EVALSHA 命令，它的作用和 EVAL 一样，都用于对脚本求值，但它接受的第一个参数不是脚本，而是脚本的 SHA1 校验和(sum)。
> 
>   
>   
>   
>   
> 
> 
>     SCRIPT LOAD script		# 时间复杂度： O(N)
> 
> 将脚本储存到脚本缓存里面，等待将来 EVALSHA 使用。
> 
>   
>   
>   
>   
> 
> 
>     SCRIPT EXISTS sha1 [sha1 …]		# 时间复杂度： O(N)
> 
> 检查 sha1 值所代表的脚本是否已经被加入到脚本缓存里面，是的话返回 1 ，不是的话返回 0
> 
>   
>   
>   
>   
> 
> 
>     SCRIPT FLUSH		# 时间复杂度： O(N)
> 
> 清除脚本缓存储存的所有脚本
> 
>   
>   
>   
>   
> 
> 
>     SCRIPT KILL		# 时间复杂度： O(1)
> 
> 杀死运行超时的脚本。如果脚本已经执行过写入操作，那么还需要使用 SHUTDOWN NOSAVE 命令来强制服务器不保存数据，以免错误的数据被保存到数据库里面。

# 其它命令 #

<table> 
 <thead> 
  <tr> 
   <th>命令</th> 
   <th>含义</th> 
   <th>时间复杂度</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>RENAME key newkey</td> 
   <td>用于修改 key 的名字为 newkey 。如果 newkey 存在则会被覆盖，此种情况隐式执行了 DEL 操作，所以如果要删除的key的值很大会有一定的延时，即使RENAME 本身是常量时间复杂度的操作。</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>RENAMENX key newkey</td> 
   <td>如果键 newkey 不存在，那么将键key 改名为 newkey ；如果键 newkey 已经存在，那么不做动作。</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>SORT key [BY pattern] [LIMIT offset count] [GET pattern [GET pattern …]] [ASC/DESC] [ALPHA] [STORE destination]</td> 
   <td>可以对 list, set 或sorted set 进行排序</td> 
   <td>O(N+M*log(M))， N 为被排序键包含的值数量，M 为要返回的值数量</td> 
  </tr> 
  <tr> 
   <td>RANDOMKEY</td> 
   <td>从当前数据库中随机返回一个 key</td> 
   <td>O(1)</td> 
  </tr> 
  <tr> 
   <td>KEYS pattern</td> 
   <td>用于查找所有符合给定模式 pattern 的 key。可能会阻塞服务器。不会出现重复值</td> 
   <td>O(N)</td> 
  </tr> 
  <tr> 
   <td>SCAN cursor [MATCH pattern] [COUNT count] [TYPE type]</td> 
   <td>用于增量遍历集合中的元素。不会阻塞服务器。可能会出现重复值</td> 
   <td>O(1)，遍历整个数据库的总复杂度为 O(N)</td> 
  </tr> 
  <tr> 
   <td>FLUSHDB</td> 
   <td>清空当前数据库</td> 
   <td>O(N)</td> 
  </tr> 
  <tr> 
   <td>MOVE key db</td> 
   <td>将当前数据库的 key 移动到选定的数据库 db 当中</td> 
   <td>O(1)</td> 
  </tr> 
 </tbody> 
</table>

# 巨人的肩膀 #

> 从他人的工作中汲取经验来避免自己的错误重复，正如我们是站在巨人的肩膀上才能做出更好的成绩。

[http://redisdoc.com/][http_redisdoc.com]  
[https://www.redis.com.cn/commands.html][https_www.redis.com.cn_commands.html]

# VChat #

一个没有哆啦A梦和静香的IT码农，不专业Gopher  
![在这里插入图片描述][20201206221123294.png]

[20210131180937860.png]: /images/20221024/15015224969c4c0da619d675885dcb89.png
[20210131181526304.png]: /images/20221024/1290500f7f9040e7a7d7c964ace9a76b.png
[20210131190734172.png]: /images/20221024/b9c9973598114eb98fca2cf76a06a852.png
[http_redisdoc.com]: http://redisdoc.com/
[https_www.redis.com.cn_commands.html]: https://www.redis.com.cn/commands.html
[20201206221123294.png]: /images/20221024/1d1069a242b44b95b2c61077f9c68643.png