深入学习 Redis - 深挖经典数据类型之 string

Myth丶恋晨 2024-03-17 21:41 101阅读 0赞

**目录**

前言

一、string 类型

1.1、操作命令

set / get （设置 / 获取）

mset / mget（批量 => 设置 / 获取）

setnx / setex / psetex （设置时指定不同方式）

incr / incrby / decr / decrby/ incrbyfloat（自增自减）

append（字符串拼接）

getrange（获取指定区间的字符串）

setrange（替换指定区域字符串）

strlen（获取字符串长度）

1.2、string 类型内部编码方式

1.3、应用场景

缓存功能

计数功能

共享 session 会话

手机验证码

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

## 前言 ##

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

redis 中所有的 key 都是字符串，value 的类型是存在差异的，因此出现了操控不同 value 的命令，接下来，就一起来学习一下吧~

> Ps1：接下来，我给出的指令都是按照 Redis 官方文档的语法格式来解析的，**\[ \] 相当于一个独立的单元，表示可选项（可有可无），其中 | 表示 “或者” 的意思，多个只能出现一个，\[ \] 和 \[ \] 之间是可以同时存在的.**

> Ps2：一个快速失去年终奖的小技巧 —— 清除 redis 上所有的数据 =》 FLUSHALL，这个操作可以把 redis 上所有的键值对全部带走.

##  ##

## 一、string 类型 ##

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

Redis 中的 string 是直接按照二进制数据的方式进行存储的，也就是说不会进行任何编码转化，存的是啥，取出来还是啥（不同于 mysql ，插入中文就会失败）.

不仅可以存储文本数据、整数、普通文本字符串、JSON、xml，还可以存储二进制数据（图片、视频、音频...），但是 Redis 对于 string 类型限制了大小最大是 512M（不要记这个数字，因为可以配置），一般不会存放像音频视频这种比较大的数据，因为 Redis 是单线程模型，希望进行的操作都能比较迅速.

### 1.1、操作命令 ###

#### set / get （设置 / 获取） ####

set 如果 key 不存在，则创建新的键值对，如果存在，则覆盖旧的 value，并且可能会改变原来的数据类型，原来的 key 的 ttl （过期时间）也会失效.

SET key value [expiration EX seconds|PX milliseconds] [NX|XX]

NX：如果 key 不存在，才设置新的 value，如果存在，则不设置，返回 nil.

XX：如果 key 存在，才设置新的 value，如果不存在，则不设置，返回 nil.

EX：表示秒级别.

PX：表示毫秒级别.

get 只支持 字符串类型的 value，若是其他类型就会报错.

GET key

一些用法如下

![50598c04df36428185bba0313f82aa52.png][]

![e9e4edb6100549949e0267d94de99c9e.png][]

![8b614f6474144bd9926707c04399aaeb.png][]

![eb283ce104f7408f8cd655f2a56f04b6.png][]

####  ####

#### mset / mget（批量 => 设置 / 获取） ####

和 set 和 get 类似，区别就是 mset 和 mget 可以一次操作多组键值对，这样做的目的就是因为网络通讯也是也是需要开销的，分成多个指令就会有多次网络通信，就有可能导致阻塞.

MGET key [key ...]

MSET key value [key value ...]

时间复杂度都是：O(N)，N 是 key 的数量

Ps：由于这里设置的时候一般不会设置太多，因为如果一次设置 10w 哥键值对，就有可能把 redis 给阻塞了，因此这里的时间复杂度可以认为是 O(1).

![4d0a81c414f44425946d1379fc83f10d.png][]

#### setnx / setex / psetex （设置时指定不同方式） ####

SETNX key value
    
    SETEX key [xxx] value
    
    PSETEX key [xxx] value

这三个命令实际上前面已经讲到过了，只是针对 set 的一种缩写，之所以这样，是因为为了让操作更符合人的直觉（使用者的门槛越低，要背的东西就越少）~

setnx 等价 set key value nx，不存在才能设置，存在设置失败并返回 nil。

setex 等价 set key value ex \[xxx\] ，设置 key 的过期时间（单位是秒）.

psetex 等价 set key value px \[xxx\]，设置 key 的过期时间（单位是毫秒）.

![fb208cc764fa46cc9eff94b21849e329.png][]

![08653edf54e34c4c9ac14895c18704b4.png][]

#### incr / incrby / decr / decrby/ incrbyfloat（自增自减） ####

incr 针对 value + 1

incrby 针对 value + n

decr 针对 value - 1

decrby 针对 value - n

**以上命令操作的 value 必须是整数.**

incrbyfloat 针对 value + 或 - 小数，value 可以是整数也可以是小数（此处没有提供减法版本，是因为不常用，用的最多的是 redis 的计数操作，一般都是整数）.

INCR key
    
    INCRBY key decrement
    
    //后面的依次类推

这些操作的共同点如下：

1.  时间复杂度都是 O(1).
2.  这些操作的 key 如果不存在，就会把这些 key 的 value 先当作 0 来使用，然后再次基础上增减.

> Ps：由于 redis 处理命令是单线程模型，因此多个客户端对同一个 key 进行操作，不会引起 “线程安全” 问题.

![13fb418ba8684ab49002a5ec9e04dc1d.png][]

![b6735910d02e4277b780a4cda0c35c98.png][]

![6abfa2f3cbd24677b93c637b97e6532a.png][]

#### append（字符串拼接） ####

append 可以对 redis 中的字符串进行拼接操作，若 key 不存在，则对空字符串进行拼接，**返回值是字节.**

值得注意的是 redis 中的字符串不会对字符编码做任何处理（redis 不认识字符，只认识字节）.

APPEND KEY VALUE

![c36454b92b4b449990512f4d96fd2af7.png][]

> Ps：Xshell 终端默认的字符编码是 utf8. 在终端输入汉字后，也是按 utf8 编码的，一个汉字在 utf8 字符集中，通常是 3 个字节，因此，我们如果直接通过 get 获取汉字，获取到的只是字节信息，\\x表示后面的字符是十六进制数.
> 
> ![7639a76725134d0f809f02ab1f46d0eb.png][]
> 
> 我们可以在 redis 客户端启动的时候，加上 --raw 这样的选项，就可以使 redis 客户端能自动把二进制数据进行翻译.
> 
> 注意：操作 linux 的时候，不要乱按 ctrl + s ，他的作用是 “冻结当前画面”（用来观察有些显示过快的日志信息），ctrl + q 是解除冻结.

#### getrange（获取指定区间的字符串） ####

getrange 用来获取指定区间的字符串，值得注意的是 redis 中指定的区间都是闭区间，下标从 0 开始，也可以用负数表示，-1 标识倒数第 1 个元素（可以理解为下标为 len - 1 的元素）.

GETRANGE key start end

![6650788b7a6a40319ea0f045c6bec29b.png][]

> Ps：如果字符串中保存的是汉字，此时切分，很可能切出来的就不是完整的汉字了，因为这里切割的单位是字节，那么从汉字中切出的结果在 utf8 码表上就不知道能查出什么了（前提是启动时加上了 --raw 这个参数，没加这个参数，查出来的就是类似 \\x9c 这种信息）
> 
> ![1f37b42124c1415d8ad8cfd442f85c56.png][]

#### setrange（替换指定区域字符串） ####

setrange 是从指定的偏移量（offset）开始替换该区域字符串的，返回值是 替换后 新的字符串长度，单位是字节.

SETRANGE key offset value

![2a4518e77c1f47828270651fbd1b1bda.png][]

![40ddd33e113d4bc4ba8d77d53040eb3a.png][]

> Ps：如果 value 是一个中文字符串，进行 setrange 时候，也会弄出问题的
> 
> ![7dddeab227ff4f34ae3eb3630c0617d8.png][]

> Ps：setrange 是可以对不存在的 key 操作的，并且会把 offset 之前的内容填充成 0x00（前提是启动时不能添加 --raw 参数）![95217e4ac2b24051a38c929092080b4b.png][]

#### strlen（获取字符串长度） ####

strlen 用来获取字符串的长度，单位是字节

STRLEN key

![6753c08254fa47b0b60142473ba1c105.png][]

![d81d2af6c295465790a7b21e7ffea355.png][]

> Ps：一个汉字通常是 3 个字节呀，Java 中为啥能用 2 字节的 char 表示汉字呢？
> 
> 在 Java 中，字符串的长度是以字符为单位
> 
> 刚刚说的汉字是 3 个字节，是因为使用 utf8 进行编码的.
> 
> 而 Java 中的 char 是使用 unicode 进行编码的，一个汉字就是两个字节了.
> 
> Java 中的 String 则是使用 utf8 ，一个汉字就是 3 个字节了.

###    1.2、string 类型内部编码方式 ###

string 内部有三种编码方式：

1.  int：用来表示 64 位/8字节 的整数，redis 通常用来实现 “计数”这样的功能，当 value 是一个整数的时候，此时 redis 可能直接使用 int 来保存.
2.  embstr：压缩字符串，针对短字符串进行的特殊优化，适合用来表示比较短的字符串.
3.  raw：普通字符串，底层类似一个 java 中 byte 类型的数组，适用于表示更长的字符串，只是单纯的字节数组，没有什么特别的优化.

![82dcd11507ef4987956e21b820cd0d9d.png][]

![57825093fdff4e4db3412a77dab9448a.png][]

![d8402d34669f4ea584d2d45d5876634a.png][]

> Ps1：redis 存储小数，本质上还是以字符串来存储的，这就意味着每次进行算数运算，都需要把字符串转化成小数，进行运算，最后再转回字符串保存.

> Ps2：不建议大家去记 39 这样的数字，例如当某个业务场景有很多很多 key ，类型都是 string ，但是长度都是 100 左右，为了整体的内存空间，我们使用 embstr 来存储也是可以考虑的~
> 
> 具体做法：1.先看 redis 是否提供了对应的配置项，可以修改 39 这个数字 ；2.如果没有配置项，就需要对 redis 源码进行修改.
> 
> 这就是为什么很多大厂往往都是自己自己造轮子，而不是使用业界成熟的开源组件，开源组件往往考虑的都是通用性，但是大厂往往会遇到一些极端的业务场景，就需要根据当时场景针对开源组件进行定制化.

### 1.3、应用场景 ###

#### 缓存功能 ####

使用 redis 作为缓存， MySQL 作为数据库组成的架构

![52e2afd55a714a61a233d1a89b1beb5e.png][]

**整体思路：**

应用服务器访问数据的时候，先查询 Redis，如果 Redis 上存在该数据，就从 Redis 中取数据直接交给应用服务器，不用继续访问数据库了；如果 Redis 上不存在该数据，就会去 MySQL 中把读到的数据返回给应用服务器，同时，把这个数据也写入到 Redis 中. 这里也需要注意一点，如果数据库中查询到这个数据为空，就有可能会导致缓存穿透问题，因此我们可以将查询为空的这个数据页缓存起来，缓存穿透问题.

由于 Redis 这样的缓存经常用来存储 “热点数据”，也就是高频使用的数据，那什么样的数据算高频呢？这里暗含了一层假设，某个数据一旦被用到了，那么可能在最近这段时间就可能被反复用到.

> 随着时间推移，越来越多的 key 在 redis 上访问不到，那 redis 的数据不是越来越多么？

1.  把数据写给 redis 的同时，会给这个 key 设置一个过期时间.
2.  Redis 也有内存不足的时候，因此提供了 淘汰策略（后面详细讲）.

#### 计数功能 ####

许多应⽤都会使⽤ Redis 作为计数的基础⼯具，它可以实现快速计数、查询缓存的功能，例如网站视频的播放量，点赞数量......

> Ps：这些都是相比较 MySQL 数据库而言的，Redis 可以通过简单的键值对操作完成计数任务并且实在内存中完成的，而 MySQL 就需要先查询数据库，然后 +1，然后再存入数据库，是在需要进行硬盘存储的

![99b1de959d034a3f9f3d1d2ebe6b69fb.png][]

**整体思路：**

假设，用户点击某个视频，此时需要进行播放量 + 1 的操作，这时候应用服务器就会直接去操作 Redis ，执行 incr 命令，然后将返回的数据反馈给用户，最后 Redis 会以异步的方式将播放量同步到 MySQL 数据库中（异步就表示：这里并不是每一个播放请求，都需要立即写入数据~ 至于什么时候写入，需要根据实际的业务需求场景而定），将数据持久化.

> Ps：实际中要开发⼀个成熟、稳定的真实计数系统，要⾯临的挑战远不⽌如此简单：防作弊、按 照不同维度计数、避免单点问题、数据持久化到底层数据源等。

#### 共享 session 会话 ####

传统的 session 会话是分布在各自的应用服务器上的，彼此之间不共享，如果用户访问同时访问不同的服务器，就有可能出问题了~

通过 Redis ，我们就可以将 session 会话信息统一管理了~

![ae8e0a90476b42a6b56e801096c65ea7.png][]

**举个例子（这里实际有很多例子，医院看病，换眼镜片...）：**

这就像是前段时间我去医院看病，唱歌长过度，声带出了点问题~

我就出去医院挂了个专家号，然后这医生就给用一些医疗手段给我看了一下，然后先给我开了一周的药，先吃着看，一周之后再来复查.

很快，这一周过去了，我再去复查，发现第一天给我看病那医生不在了！虽然今天也有个医生，但是他没给我看过，不了解我这边的情况（这就相当于是传统的，每个服务器都有管理自己的 session ，彼此之间互不干扰）.

没办法就硬着头皮去了~ 这个新医生就拿着我的就诊卡，在那机子上一刷，我之气的病例就在他电脑上了（这就相当于 Redis 将 session 信息共享了）.

**抽象一下：**

我是病人，就相当于是客户端~

医生给我诊病，相当于是服务器，并且有多个.

而这里的服务器是以负载均衡（根据每个医生上班任务合理分配时间）的方式来提供服务的，因此就有可能出现两次访问同一网站使用的确实不同的服务器.

医院正确的做法，就是搞一个系统，向 Redis 这样共享会话，让多个医生共享.

#### 手机验证码 ####

手机验证码一般会限制以下类型：

1.  1分钟内，最多能获取 5 次验证码.
2.  每次获取验证码必须间隔 1 分钟.

使用 redis 的原因主要还是怕用户频繁获取验证码，对服务器压力过大，再者验证码信息需要有过期时间，基于数据库实现，成本太高~

发送验证码伪代码如下：

String 发送验证码(phoneNumber) {
     key = "shortMsg:limit:" + phoneNumber;
     // 设置过期时间为 1 分钟（60 秒） 
     // 使⽤ NX，只在不存在 key 时才能设置成功 
     bool r = Redis 执⾏命令：set key 1 ex 60 nx
     if (r == false) {
     // 说明之前设置过该⼿机的验证码了 
     long c = Redis 执⾏命令：incr key
     if (c > 5) {
     // 说明超过了⼀分钟 5 次的限制了 
     // 限制发送 
     return null;
     }
     }
     
     // 说明要么之前没有设置过⼿机的验证码；要么次数没有超过 5 次 
     String validationCode = ⽣成随机的 6 位数的验证码();
     
     validationKey = "validation:" + phoneNumber;
     // 验证码 5 分钟（300 秒）内有效 
     Redis 执⾏命令：set validationKey validationCode ex 300;
     
     // 返回验证码，随后通过⼿机短信发送给⽤⼾ 
     return validationCode ;
    }

检查验证码伪代码如下：

bool 验证验证码(phoneNumber, validationCode) {
     validationKey = "validation:" + phoneNumber;
     
     String value = Redis 执⾏命令：get validationKey;
     if (value == null) {
     // 说明没有这个⼿机的验证码记录，验证失败 
     return false;
     }
     
     if (value == validationCode) {
     return true;
     } else {
     return false;
     }
    
    }

##  ##

![72f3087bad234966958fe3a98903f9b5.gif][]

[50598c04df36428185bba0313f82aa52.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/fad3104b3cf344d1b043dd524de4a943.png
[e9e4edb6100549949e0267d94de99c9e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/41ed5edf8bac4cde9f3affe24b79115b.png
[8b614f6474144bd9926707c04399aaeb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/c4497f3e26ab458387a3a88782b60a0b.png
[eb283ce104f7408f8cd655f2a56f04b6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/ddf6cba8d34943bfac766b260959a5b9.png
[4d0a81c414f44425946d1379fc83f10d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/7b7c184985044e3b8a352f16c6e81593.png
[fb208cc764fa46cc9eff94b21849e329.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/216077c90d484fff8fd4819cfdac7bf2.png
[08653edf54e34c4c9ac14895c18704b4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/f196746cd1204b31afe84ab7ca013c26.png
[13fb418ba8684ab49002a5ec9e04dc1d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/46a94142121e4d228a1e296fa7d8c34a.png
[b6735910d02e4277b780a4cda0c35c98.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/63c3c716c467402593488cd7520ee5ba.png
[6abfa2f3cbd24677b93c637b97e6532a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/bff3024b85ac4f6e9cdce0c62c190881.png
[c36454b92b4b449990512f4d96fd2af7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/4e584374699944e4951406f917c4f01b.png
[7639a76725134d0f809f02ab1f46d0eb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/f1f10e81249140c09bd27ad5a8e7e0b8.png
[6650788b7a6a40319ea0f045c6bec29b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/425789de9084431aa1b2bf1ea3993837.png
[1f37b42124c1415d8ad8cfd442f85c56.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/0607398c515b4ea086d0c0cdc5915556.png
[2a4518e77c1f47828270651fbd1b1bda.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/56265cabdafd4e029124660fef4533d0.png
[40ddd33e113d4bc4ba8d77d53040eb3a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/3e2c9a725bc44614ac011b61189cfab5.png
[7dddeab227ff4f34ae3eb3630c0617d8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/0f443f5fc6e7499eb8c8a1a559adbd5e.png
[95217e4ac2b24051a38c929092080b4b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/9a5e788970214a1892a88db6bcdbc0c4.png
[6753c08254fa47b0b60142473ba1c105.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/03e78eeae68747539500b3d94d418e02.png
[d81d2af6c295465790a7b21e7ffea355.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/650b60dee09c4b7f9850270ffdefdd61.png
[82dcd11507ef4987956e21b820cd0d9d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/bb49e84ebad54d1eb32d5c0aa92ceaae.png
[57825093fdff4e4db3412a77dab9448a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/5333057b4fed43ff8c416076f45263c9.png
[d8402d34669f4ea584d2d45d5876634a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/37f0203b2f0c46b59413e4ce0945d880.png
[52e2afd55a714a61a233d1a89b1beb5e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/99409a5538ca4155833dc7166b837271.png
[99b1de959d034a3f9f3d1d2ebe6b69fb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/8e3fc939fc224ad599798ca21956f122.png
[ae8e0a90476b42a6b56e801096c65ea7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/0b5a2a235e1b4156a6a99c42c06380fe.png
[72f3087bad234966958fe3a98903f9b5.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/ae80110d7e5e47deb2c52d936998a675.png