微服务 - Redis缓存 · 数据结构 · 持久化 · 分布式 · 高并发

本篇内容基于 Redis v7.0 的阐述；官网：https://redis.io/

本篇计划用 Docker 容器辅助部署，所以需要了解点 Docker 知识；官网：https://www.docker.com

一、分布式解决 Session 的问题

在单站点中，可以将在线用户信息存储在Session中，随时变更获取信息；在多站点分布式集群如何做到Session共享呢？架设一个Session服务，供多服务使用。

频繁使用的数据存在DB端，频繁的DB连接，频繁的IO；数据存于内存中更能减少性能的消耗，更能提高使用效率。

集群化分布式时，为解决以上现象，建立缓存服务显得尤为重要。

建立缓存服务选择性很多，如：Redis、MongoDB等，以下以 Redis 为例：

作者：[Sol·wang] - 博客园，原文出处：https://www.cnblogs.com/Sol-wang/

二、内存数据库 Redis

Remote Dictionary Server；
远程字典服务，Key/Value 存储系统、列存储、文档型存储等，NoSQL开源内存数据库。最多的使用场景是作为数据缓存，存在于应用与DB之间，减少对DB的访问，提高数据操作的性能。

下图展示了缓存服务在整体架构中的位置：

2.1 Redis 特性

高性能 / 高可用 / 持久化 / 集群化，单实例每秒读写达10万次；

丰富的数据类型 ：String / Hash / Set / Zset / 队列 / 订阅 / 发布；

高性能数据结构：SDS / Intset / ziplist / listpack / quicklist / skiplist；

支持 ACL：Access Control List；精细化的权限管理策略；

单线程处理事务：顺序执行，容易上锁；

多线程处理辅助功能：连接请求 / 持久化等；

2.2 单线程IO多路复用

通常情况下，同时连接 Redis 的客户端有成千上万的，但 Redis 只有一个主线程处理事务，那如何做到多路连接集中到一个线程处理呢？

当多个客户端同时发起连接后，这也是需要一个过程的，也是有连接完成的先后，谁连接完成就会告诉 Redis，这里的告诉用的是回调方式，Redis就会把他的任务放到单一的队列中，队列的另一头连接着主线程。

在这个过程当中，多路的连接汇集到一个有足够处理能力的队列中进行传输；是不是可以理解为：多路连接重复利用了单个管道；我想...这里也是体现了 Redis 的多路复用技术。当然，单单就多路复用来讲，也会是多路集中到一路，然后这一路又分成了多路到各各目标。

多路复用也有不同的算法：select、poll、epoll，Redis用的是epoll算法，所以其中有回调的动作，目前而言，epoll是最高效的；关于每个具体的算法，有兴趣的同学可以继续研究一下。

2.3 启动 Redis

用 Docker 启动 Redis 简单示例：

1、拉取镜像docker pull redis

2、运行容器 docker run -d --name=some-redis redis

3、连接到 Redis docker exec -it some-redis redis-cli

Redis Docker版默认是没有配置文件的，官网说：可以再生成镜像方式解决...

既然没有配置文件，那 Redis 启动完全是按所有配置项的默认值运行的；如下传参启动：

# 启动 redis-server，多参数配置
docker run -d --name some-redis -p 6379:6379 redis redis-server \
    --bind 0.0.0.0 \        # 支持任意的连接
    --save 60 1 \           # 每60秒 持久化一次
    --protected-mode no \   # 取消保护模式
    --requirepass 123456    # 登录密码 123456；连接后用 auth {passwd} 方式登录

传参也就是覆盖了配置项的默认值，以下查看覆盖后的配置项效果：config get *列出所有配置项

Redis 启动后，都包含 redis-server / redis-client；
所以任意 Redis 都可用 redis-client 连接到其它 redis-server：docker exec -it some-redis redis-cli -h {目标IP} -p {目标端口}

2.4 重要配置项

通常配置参数于配置文件中；比如：/etc/redis/redis.conf

三、数据类型 / 常用命令

Key/Value 的存储系统，Key相当于区分的变量名称，类型区别在于Value；常用数据类型有：

String：字符，基础类型，过期时长，递增

• SET/GET key value写入/取值
• GET key key key取多个值
• INCR/DECR key递增1/递减1

List：队列，先进先出，先进后出

• LPUSH/RPUSH key value头/尾添加
• LPOP/RPOP key头/尾移除
• LLEN key队列长度

Set：无序集合，可查询 交集、并集、差集等

• SADD|SREM key member member member插入/移除 元素
• SISMEMBER key member是否存在成员
• SINTER key1 key2多集合取交集
• SCARD key元素个数总数

ZSet：带排序的Set集合；比Set多出一个专用的score值，又可排出名次列

• ZADD key score member score member新增成员及序列数，可覆盖
• ZRANGE key start stop按序列范围取集合
• ZRANK key member取正序排名；从0开始的名次
• ZREVRANK key member取倒序排名；从0开始的名次

Hash：可同时设置/获取多个属性值

• HSET key field value field value成对设置多个属性与值
• HMGET key field [field field]取多个列的值
• HINCRBY key field -5指定属性的值，递增/递减

四、数据结构

为什么 Redis 要有自己的数据结构

• 查询要快：体现在单条Key用了连续性的内存空间
• 占用空间少，节约内存：体现在了集合的数据压缩

Redis 中有这么几种数据结构：sds (动态字符串)、hashtable (字典)、linkedlist (链表)、intset (整数集合)、ziplist (压缩列表)、listpack (紧凑列表)、quicklist (混合列表)、skiplist (跳表)；它们分别应用于Redis各数据类型中，使得Redis在资源利用和运行效率上有着明显的效果。

以下列出了数据类型与数据结构的应用关系图：

关于 Listpack；未来作为 Ziplist 的升级替代品，v7.0版本也会有 Ziplist 的存在，后续版本中逐渐被替代。

数据结构的自动切换

每种数据类型也会有多种数据结构，至于何种数据类型在什么情况下用何种数据结构，取决于存储的数据；
比如：List 每元素小于8KB时，自动使用 Ziplist，否则自动切换为 Quicklist；
比如：Set 每元素为数字，元素小于512个时，自动使用 Intset，否则自动切换为 Hashtable；
比如：Hash 元素小于512个，每元素长度小于64字节，自动使用 Ziplist；否则自动切换为 Hashtable。

影响数据结构转换的配置项

# 配置文件中 各数据类型中的数据结构
# 能承载的最大长度/个数/容量
# 超出最大限制后，变更为其它数据结构
hash-max-listpack-value 64
hash-max-listpack-entries 512
list-max-listpack-size -2(8KB)
set-max-intset-entries 512
set-max-listpack-value 64
set-max-listpack-entries 128
zset-max-listpack-value 64
zset-max-listpack-entries 128

以下主要以 sds / ziplist / listpack / skiplist 为例的阐述，基本涵盖了重要的数据结构，一些扩展性的数据结构有兴趣的同学再深入了解下。

4.1 动态字符串 - SDS

很多计算机语言都一样，Redis 也是基于C语言写的；对于String类型，当给一个变量拼接一个字符串时，都是以一个新对象在内存中重新开辟新的更长的连续空间来存储；重新开辟/释放旧空间这样的内存损耗。。。所以为什么开发人员会避免strname + "xxx"这样的拼接方式；字符串长度也是底层每次通过遍历得出的结果。。。Redis为了避免这样的损耗，于是就有了 Simple Dynamic Strings 这样的解决方案 SDS。

Redis String 会事先分配好比实际字符串更长的内存空间，并记录实际字符串的长度，也记录存储后剩余的空间长度。

1. 取字符串长度时，直接返回记录的长度值
2. 追加字符串时，直接使用空闲的剩余空间

预分配空间有多长？总有用完的时候：

1. 当实际字符串长度<1M时，预分配实际字符串两倍的连续长度，相当于本次只会占用一半
2. 当实际字符串长度>1M时，每次预分配多出1M的长度空间。便于下次直接存储
3. 当字符串减少缩短时，多出的剩余空间保留，便于下次追加，或手动命令清除空闲空间

这种 空间预分配策略 和 惰性删除策略 就是SDS的性能优势。

4.2 压缩列表 - ziplist

一块连续性的内存空间存放了整个Value，也就是一个ziplist，如何做的呢？一个集合的示例：

bytes：记录 ziplist 的总长度
tail：记录最后一个 entry 的偏移量，便于快速定位
len：记录 entry 的总个数
entry：列表元素，数据存放的元素
end：单个 ziplist 的结束符
prevlen：记录上个 entry 的总长度；这里记录值所占用的空间长度，取决于上个 entry 的长度，所以1-5会自动切换
encoding：记录 data 的实际数据类型 及长度；如：int时占空间小，可直接存到 encoding，就不用 data 了
data：实际数据；占用空间小的数据类型，可直接放到 encoding 中，所以这时候没有 data 的存在，省空间。

ziplist 的取值：
结构图中，有总长/个数/偏移量/结束符/上个元素长度；所以 ziplist 正序倒序是都可以算出每个 entry 具体位置并取出数据。

ziplist 的写入，插/改/删 统一为覆盖方式：
1、为新元素找到被覆盖元素的位置，位置之前的元素 + 新元素 + 位置之后的元素 = 新的ziplist的完整结构
2、申请新ziplist所需长度的内存连续空间，并存入新空间
3、释放旧空间

看起来挺不错的，相比链表的非连续性存储所带来的性能提升明显。。那为什么还会有新的改进版本 listpack 的出现？

4.3 紧凑列表 - listpack

listpack 是 ziplist 的升级版于v7.0中，作为替代品都有什么变化，listpack结构如下图：

上图看出，listpack 与 ziplist 的区别在于：
1、header 取消 tail
2、entry 取消 prevlen
3、当前 entry 中增加 encoding + data 的总长度 element-total-len
4、element-total-len 中的首位会标识出左侧是否还有值，主要用于逆序读

element-total-len 编码
长度 1-5 bytes 是可变的，不固定长度如何读出整个 element-total-len？这其中0/1标识了左侧是否有数据；

listpack 的读，假设逆序读出每个元素的值，已知end固定长度，跳过 1 bytes 到 element-total-len 中读固定(7)位数，就会知道左侧是否有值，这样会把 element-total-len 整个读下来，也就知道了当前 entry 长度，那么也就知道了相邻 entry 的起始位置；继续这样按序把每个 entry 读出来就完成逆序读数据。

listpack 的写入，同样是基于 ziplist 的方式，新元素替换旧元素组成新的长度，存储到新申请的内存连续空间，释放旧空间；由于未影响到其它元素，申请一次新空间后完成写入操作。

这样以来，listpack 任何写入的操作，entry 都是在变更自己，不会牵连到其它 entry，这就是对 ziplist 改善的地方。

4.4 跳跃列表 - skiplist

跳表是在链表的基础上追加了更多指针的存储；链表的指针指向了相邻元素的地址，但跳表又追加了指向间隔元素的指针；这使得跳表在查询元素的效率上更快。

下表 Linkedlist 与 Skiplist 的查询区别：

上图：两种查询的路径不同，影响到的元素数量也不同，链表搜了11次才找到指定的元素，而跳表仅搜了5次就找到了指定的元素。
比如：元素1 既存了指向下个元素2 的指针，也存了指向元素4 的指针；所以跳表多存的指针让其可以跳跃搜索，相对于链表减少了搜索次数，这就体现了相比链表搜索的高效率。

五、持久化

5.1 RDB 模式

Redis Database：持久化以指定的时间间隔执行数据集的时间点的快照整库备份。

触发RDB配置：save 36000 1 600 10 30 100
以上从右往左，成对解释：
  当30秒内写入了100次，触发持久化，如果未满足条件，继续下一对；
  当600秒内写入了10次，触发持久化，如果未满足条件，继续下一对；
  当36000秒内写入了1次，触发持久化。

持久化过程：内存 -> 临时文件 -> 磁盘。

影响RDB效率的配置项：
  stop-writes-on-bgsave-error yes当持久化失败后强制停止写入
  rdbcompression yes快照数据压缩，损耗CPU
  rdbchecksum yes是否检测备份文件，损耗CPU≈10%

关闭RDB持久化模式：save ""

5.2 AOF 模式

Append Only File：追加记录服务器接收到的每个写入命令，增量保存；如果写入错误，Redis 也会具有自动修复受损的AOF文件；恢复时，重新按序执行指令，从而重建内存库。

配置开启AOF模式：appendonly yes

持久化频率策略配置：appendfysnc always|everysec|no

• 每次命令追加：每次写命令立刻记录，太频繁，太耗性能
• 每秒追加一次：每秒集中记录一次，依然有可观的性能表现

文件压缩 Rewrite
主进程 redis-server 创建出一个子进程 bgrewriteaof 对 AOF文件的重新整理，先整理出一个临时文件，再覆盖原AOF文件。

Rewrite 的重写策略：

• 只针对写入命令的整理
• 相同数据只记录最后写入命令
• 过期数据不记录
• 多命令合并记录

多命令合并示例：如累加命令 Incrby 的累加总和合并成一次累加；如集合命令 rpush 的多次追加合并成一次追加多个。

手动触发执行重写命令：bgrewriteaof。

自动触发重写相关配置：
no-appendfsync-on-rewrite no重写开关
auto-aof-rewrite-min-size 64mb重写触发条件，文件超过指定大小
auto-aof-rewrite-percentage 100重写触发条件，文件超过已使用%

AOF文件64MB是不是显得太小了，可适当增加容量如3GB，以防止过多的触发压缩重写后影响性能；也不可过大，影响数据恢复效率。

Redis 默认开启 RDB，可同时开启 RDB + AOF，恢复数据时以 AOF 为优先。

六、分布式集群

6.1 虚拟插槽

Redis 分布式给出一个 16384 长度的集合，每个元素称为一个 Slot，将所有 Slots 分段平均映射到各个 Master 节点上；数据通过对 Key 的算法映射到各Slot，也就存到了对应的 Master 节点上，所以每个节点实例负责其中一部分的Slot读写。

通过控制节点与槽 Slot 的关系，决定每个 Master 节点所承载的数据量；这在集群节点维护的时候非常有用。

6.2 创建集群

集群必须了解的conf配置项：

# 每个节点必须的配置项
cluster-enabled yes
# 节点失去连接超时时间
cluster-node-timeout 15000
# 节点间传输效率 默认 no（yes:单次多量发送/no:单次少量多次发送）
tcp-nodelay no
# DOCKER/NAT support
# (地址端口可能被转发)静态配置公共地址
cluster-announce-ip <外部访问IP>
cluster-announce-port <外部访问端口>
cluster-announce-bus-port <节点互通外部端口>

按 Redis 要求的最低 Master 节点数量3实例，多主多从的模式，需要创建6个运行实例：(6371-6376,16371-16376)

# 实例示例1（6371,16371）
docker run -d --name clu-rds-1 \
    -p 6371:6371 -p 16371:16371 \        # 容器分别开放 对外连接端口 和 节点间通信端口
    redis \
    redis-server \                       # 启动 Redis 服务命令
    --bind 0.0.0.0 \                     # 不限连接的客户端来源
    --port 6371 \                        # 实例对外连接端口
    --protected-mode no \                # 非保护模式
    --cluster-enabled yes \              # 开启集群
    --cluster-announce-ip 13.13.1.16 \   # 对外的访问IP
    --cluster-announce-port 6371 \       # 集群对外的连接端口
    --cluster-announce-bus-port 16371    # 集群节点间通讯端口（通常为：10000+Port）

Docker 查看6个容器实例：

Docker 3主3从模式 创建集群：

docker exec -it clu-rds-1 \
    # 连接到任意实例
    redis-cli -p 6371 \
    # 创建集群 并指定 1主几从
    --cluster create --cluster-replicas 1 \
    # 要包含的所有(6个)运行实例<ip:port>
    13.13.1.16:6371 13.13.1.16:6372 13.13.1.16:6373 \
    13.13.1.16:6374 13.13.1.16:6375 13.13.1.16:6376

连接到任意容器节点，查看集群成员：docker exec -it <container-name> redis-cli -p <container-port> cluster nodes

6.3 节点管理

# 集群信息
redis-cli -p <port> cluster info
# 查看现有节点成员
redis-cli -p <port> cluster nodes
# 加入新成员，从节点
redis-cli --cluster add-node <new-node-ip:port> <cluster-member-ip:port> \
    --cluster-slave --cluster-master-id <to-master-id>
# 删除集群成员节点
redis-cli --cluster del-node <del-ip:port> <del-node-id>
# 重新分配节点与插槽映射
redis-cli --cluster reshard <member-ip:port>
# 查看某节点同步信息
redis-cli -p <port> info replication
# 停止某节点实例运行
redis-cli -p <port> shutdown

6.4 分布式锁

6.4.1 为什么会需要锁？

🔲场景 A：

多用户对同一产品下单购买，库存有10个，同一时间进来100个用户各买一个；
购买前都会看下库存是否够买，才会生成订单，否则提醒无货；
当前10个用户还没有下单成功并未扣库存完成时，后90个用户看到有库存，也继续生成订单；
最后卖出100各产品，实际库存不够。。。

如何确保有库存，不超买。
对库存加锁，每个用户按序进来扣库存，当前用户扣完库存后，释放自己加的锁，以视完成操作继续后续用户，下个用户再进来看库存是否能购买。

🔲场景 B：

当某个用户下单扣库存时，倘若发送了异常，导致未能释放自己加上去的锁，那么。。。没人负责释放此锁了，后续不能查扣库存，谁也不能下单了。

如何确保防止不能解锁。
对库存锁加过期时间，时间超出后，自动强制解锁。

是的，加锁、过期自动解锁，是确保以上场景能够顺利进行的必要条件，共享数据被多用户处理的时候，同一时间点，只能被一个用户访问处理，多用户有序访问处理，及时更新处理结果。

6.4.2 SET NX EX 命令

• SET：String 类型的KV操作
• NX：Key唯一，仅当没有Key时才能写入
• EX：Key 的有效时长，到期后自动删除

所以完整的命令为：set {business-key} {value} nx ex {过期时长}
返回失败，表示上个用户正使用
返回成功，表示自己已开始使用

符合分布式锁的必要条件

1、当 get {business-key} 有值时，表示已有用户在占用，需要等待
2、当 占用用户处理完成后，正常释放自己加的锁，del {business-key}
3、当 占用用户处理发生异常退出时，等ex {过期时长}后，系统自动解锁，后续用户继续购买

命令演示案例：(ttl：剩余过期时间秒)

也可以在 Value 中保存用户的标识，解锁的时候只能解除自己的锁，防止某些场景下解锁错误。

6.4.3 Lua 脚本

持续更新。。。

七、高并发带来的问题

7.1 缓存穿透

现象：

DB没有查询结果或为NULL，导致查询结果没有进入到缓存；当大批量的这种请求时，就会每次“穿透”缓存“直抵”DB，引发DB的高并发查询导致宕机，这种现象就叫缓存穿透。

方案：

黑名单策略（IP/用户名），防止恶意行为

对结果为空的DB查询，给出默认值于缓存中

7.2 缓存击穿

现象：

单个访问量大的 Key (热门数据)过期后，缓存需要重建该Key，大量的访问到DB引发高并发查询，导致DB宕机，这种情况称为缓存击穿。

方案：

当然也可以使用队列，就降低了并发的性能；也可以设置过期时间为永不过期；以下的重点是缓存重建Key的过程：双重锁机制

双重锁逻辑阐述：(也常应用于单例模式中)
第一把锁处理首个请求动作是否已有缓存，并挡住了第二或大量的后续请求动作；
当首个请求动作处理完成后结果于缓存中，并释放锁，处于等待的大量的请求动作会陆续进来，这就不对了，等待的请求动作应该直接用首个请求处理的结果才对；
所以，后续的请求进来后应该再次锁验证缓存中是否已有数据，也就是第二次的锁是为了解决并发时被阻塞的请求动作，防止重复查询DB更新缓存。

7.3 缓存雪崩

现象：

缓存中的热门 Key 短时间内大批量的同时过期，缓存运行正常，导致DB查询压力短时间内上升至宕机的现象。

方案：

随机的过期时间，分散过期时间，避免统一生成过期时间

为热度追加排名，时时调整热度数据，自动延长过期时间