Redis的常见数据类型
Redis 提供了 5 种数据结构，理解每种数据结构的特点对于 Redis 开发运维⾮常重要，同时掌握每
种数据结构的常⻅命令，会在使⽤ Redis 的时候做到游刃有余。
预备
在正式介绍 5 种数据结构之前，了解⼀下 Redis 的⼀些全局命令、数据结构和内部编码、单线程 命令处理机制是⼗分必要的，它们能为后⾯内容的学习打下⼀个良好的基础。
主要体现在两个方面
- Redis的命令有上百个，只是死记硬背比较困难，但是如何理解Redis的一些机制，会发现这些命令有很强的通用性。
- Redis不是万金油，有些数据结构和命令必须在特定的场景下使用，一旦使用不当可能会对Redis自身造成致命伤害
全局命令
Redis有5种数据结构，但是它们都是对值而言，不过对于键，倒是有一些通用的命令。
KEYS
返回所有满足样式的key。支持如下
• h?llo 匹配 hello , hallo 和 hxllo
• h*llo 匹配 hllo 和 heeeello
• h[ae]llo 匹配 hello 和 hallo 但不匹配 hillo
• hello 匹配 hallo , hbllo , ... 但不匹配 hello
• h[a-b]llo 匹配 hallo和 hbllo
举例如下
EXISTS
判断某个key是否存在
举个例子
DEL
删除指定的key
举个例子
EXPIRE
为执行的key添加过期时间
举个例子
TTL
获取指定key的剩余时间
TYPE
返回key对应的数据类型
返回值： none , string , list , set , zset , hash and stream
数据结构和内部编码
type 命令实际返回的就是当前键的数据结构类型，它们分别是：string（字符串）、list（列
表）、hash（哈希）、set（集合）、zset（有序集合），但这些只是 Redis 对外的数据结构
Redis的数据结构和内部编码
| 数据结构 | 内部编码 |
| string | raw |
| int | |
| embstr | |
| hash | hashtable |
| ziplist | |
| list | linkedlist |
| ziplist | |
| set | hashtable |
| intset | |
| zset | skiplist |
| ziplist |
可以看到每种数据结构都有⾄少两种以上的内部编码实现，例如 list 数据结构包含了 linkedlist 和
ziplist 两种内部编码。同时有些内部编码，例如 ziplist，可以作为多种数据结构的内部实现，可以通过 object encoding 命令查询内部编码，举例：
Redis这样设计有很大的好处：
1) 可以改进内部编码，⽽对外的数据结构和命令没有任何影响，这样⼀旦开发出更优秀的内部编码， ⽆需改动外部数据结构和命令，例如 Redis 3.2 提供了 quicklist，结合了 ziplist 和 linkedlist 两者的优势，为列表类型提供了⼀种更为优秀的内部编码实现，⽽对⽤⼾来说基本⽆感知
2)多种内部编码实现可以在不同场景下发挥各⾃的优势，例如 ziplist ⽐较节省内存，但是在列表元素 ⽐较多的情况下，性能会下降，这时候 Redis 会根据配置选项将列表类型的内部实现转换为 linkedlist，整个过程⽤⼾同样⽆感知。
单线程架构
Redis 使⽤了单线程架构来实现⾼性能的内存数据库服务，本节⾸先通过多个客⼾端命令调⽤的例⼦说明 Redis 单线程命令处理机制，接着分析 Redis 单线程模型为什么性能如此之⾼，最终给出为什么理解单线程模型是使⽤和运维 Redis 的关键。
简介
宏观上同时要求服务的客户端
微观上客户端发送命令的时间是有先后次序的
为什么单线程可以这么快
通常来讲，单线程处理能⼒要⽐多线程差，例如有 10 000 公⽄货物，每辆⻋的运载能⼒是每次
200 公⽄，那么要 50 次才能完成；但是如果有 50 辆⻋，只要安排合理，只需要依次就可以完成任务。那么为什么 Redis 使⽤单线程模型会达到每秒万级别的处理能⼒呢？可以将其归结为三点
- 纯内存访问。Redis将所有的数据放在内存中，内存的响应时长大约是100ns，这是Redis达到每秒万级别的重要基础。
- 非阻塞IO。Redis使用epoll作为IO多路复用技术的实现，在加上Redis自身的事件处理模型将epoll中的链接、读写、关闭都转换成事件，不在网络IO上浪费过多的事件。
- 单线程避免了线程切换和竞态产生的消耗。单线程可以简化数据结构和算法的视线，让程序模型更加简单；其次避免了多线程中在线程竞争同一份共享资源时带来的切换的等待消耗。
虽然单线程给 Redis 带来很多好处，但还是有⼀个致命的问题：对于单个命令的执⾏时间都是有
要求的。如果某个命令执⾏过⻓，会导致其他命令全部处于等待队列中，迟迟等不到响应，造成客户端的阻塞，对于 Redis 这种⾼性能的服务来说是⾮常严重的，所以 Redis 是⾯向快速执⾏场景数据库。
String字符串
字符串类型是 Redis 最基础的数据类型，关于字符串需要特别注意：
- Redis中的所有的键的类型都是字符串类型，而且其他几种数据类型也都是在字符串类似基础上构建的。
- 字符串的值实际可以是字符串，包含一般格式的字符串或者类似JSON、XML格式的字符串，数字。可以使整型或者浮点型；甚至是二进制流数据
常见命令
set
将string类型的value设置到key中。如果key之前存在，就修改；不存在就创建。
SET key value [expiration EX seconds|PX milliseconds] [NX|XX]SET命令支持多种选项来影响它的行为
- EX seconds —— 使用秒为单位来设置key的过期时间
- PX milliseconds——使用毫秒作为单位设置key的过期时间
- NX——只有key不存在的时候才设置
- XX——只有key存在的时候才设置
举个例子
get
获取 key 对应的 value。如果 key 不存在，返回 nil。如果 value 的数据类型不是 string，会报错
GET key
MGET
一次性获取多个 key 的值。如果对应的 key 不存在或者对应的数据类型不是 string，返回 nil。
MGET key [key ...]举个例子
mset
一次性设置多个key的值
MSET key value [key value ...]举个例子
setnx
设置 key-value 但只允许在 key 之前不存在的情况下。
SETNX key value
计数命令
incr
将 key 对应的 string 表⽰的数字加⼀。如果 key 不存在，则视为 key 对应的 value 是 0。如果 key 对应的 string 不是⼀个整型或者范围超过了 64 位有符号整型，则报错。
incrby
将 key 对应的 string 表⽰的数字加上对应的值。如果 key 不存在，则视为 key 对应的 value 是 0。如果 key 对应的 string 不是⼀个整型或者范围超过了 64 位有符号整型，则报错。
INCRBY key decrement举个例子
DECR
将 key 对应的 string 表⽰的数字减⼀。如果 key 不存在，则视为 key 对应的 value 是 0。如果 key 对应的 string 不是⼀个整型或者范围超过了 64 位有符号整型，则报错
DECR key
DECYBY
将 key 对应的 string 表⽰的数字减去对应的值。如果 key 不存在，则视为 key 对应的 value 是 0。如果 key 对应的 string 不是⼀个整型或者范围超过了 64 位有符号整型，则报错。
DECRBY key decrementINCRBYFLOAT
将 key 对应的 string 表⽰的浮点数加上对应的值。如果对应的值是负数，则视为减去对应的值。如果key 不存在，则视为 key 对应的 value 是 0。如果 key 对应的不是 string，或者不是⼀个浮点数，则报错。允许采⽤科学计数法表⽰浮点数。
INCRBYFLOAT key increment
其他命令
append
如果 key 已经存在并且是⼀个 string，命令会将 value 追加到原有 string 的后边。如果 key 不存在，则效果等同于 SET 命令。
APPEND KEY VALUE
getrange
返回 key 对应的 string 的⼦串，由 start 和 end 确定（左闭右闭）。可以使⽤负数表⽰倒数。-1 代表倒数第⼀个字符，-2 代表倒数第⼆个，其他的与此类似。超过范围的偏移量会根据 string 的⻓度调整成正确的值
GETRANGE key start end
SETRANGE
覆盖字符串的⼀部分，从指定的偏移开始。
SETRANGE key offset value
STRLEN
获取 key 对应的 string 的⻓度。当 key 存放的类似不是 string 时，报错。
STRLEN key
结算
内部编码
字符串类型的内部编码有 3 种：
- int：8个字节的整型
- embstr：小于等于39个字节的字符串
- raw：大于39个字节的字符串
Redis 会根据当前值的类型和⻓度动态决定使⽤哪种内部编码实现。
格式化/隐藏参数一锅端 四语言输出流参数宇宙（附源码/截图/参数表/避坑指南/老板沉默术）)
