## redis过期删除策略 Redis 是可以对 key 设置过期时间的，因此需要有相应的机制将已过期的键值对删除，而做这个工作的就是过期键值删除策略。 在说 Redis 过期删除策略之前，先跟大家介绍下，常见的三种过期删除策略： ### 定时删除 在设置 key 的过期时间时，同时创建一个定时事件，当时间到达时，由事件处理器自动执行 key 的删除操作** 定时删除策略的**优点**： - 可以保证过期 key 会被尽快删除，也就是内存可以被尽快地释放。因此，定时删除对内存是最友好的。 定时删除策略的**缺点**： - 在过期 key 比较多的情况下，删除过期 key 可能会占用相当一部分 CPU 时间，在内存不紧张但 CPU 时间紧张的情况下，将 CPU 时间用于删除和当前任务无关的过期键上，无疑会对服务器的响应时间和吞吐量造成影响。所以，定时删除策略对 CPU 不友好。 ### 惰性删除 不主动删除过期键，每次从数据库访问 key 时，都检测 key 是否过期，如果过期则删除该 key。 惰性删除策略的**优点**： - 因为每次访问时，才会检查 key 是否过期，所以此策略只会使用很少的系统资源，因此，惰性删除策略对 CPU 时间最友好。 惰性删除策略的**缺点**： - 如果一个 key 已经过期，而这个 key 又仍然保留在数据库中，那么只要这个过期 key 一直没有被访问，它所占用的内存就不会释放，造成了一定的内存空间浪费。所以，惰性删除策略对内存不友好。 ### 定期删除 每隔一段时间「随机」从数据库中取出一定数量的 key 进行检查，并删除其中的过期key。 定期删除策略的**优点**： - 通过限制删除操作执行的时长和频率，来减少删除操作对 CPU 的影响，同时也能删除一部分过期的数据减少了过期键对空间的无效占用。 定期删除策略的**缺点**： - 内存清理方面没有定时删除效果好，同时没有惰性删除使用的系统资源少。 - 难以确定删除操作执行的时长和频率。如果执行的太频繁，定期删除策略变得和定时删除策略一样，对CPU不友好；如果执行的太少，那又和惰性删除一样了，过期 key 占用的内存不会及时得到释放。 **Redis 选择「惰性删除+定期删除」这两种策略配和使用** ## redis内存淘汰策略 *1、不进行数据淘汰的策略* **noeviction**（Redis3.0之后，默认的内存淘汰策略） ：它表示当运行内存超过最大设置内存时，不淘汰任何数据，这时如果有新的数据写入，则会触发 OOM，但是如果没用数据写入的话，只是单纯的查询或者删除操作的话，还是可以正常工作。 *2、进行数据淘汰的策略* 针对「进行数据淘汰」这一类策略，又可以细分为「在设置了过期时间的数据中进行淘汰」和「在所有数据范围内进行淘汰」这两类策略。 在设置了过期时间的数据中进行淘汰： - **volatile-random**：随机淘汰设置了过期时间的任意键值； - **volatile-ttl**：优先淘汰更早过期的键值。 - **volatile-lru**（Redis3.0 之前，默认的内存淘汰策略）：淘汰所有设置了过期时间的键值中，最久未使用的键值； - **volatile-lfu**（Redis 4.0 后新增的内存淘汰策略）：淘汰所有设置了过期时间的键值中，最少使用的键值 ## Redis 持久化 Redis 共有三种数据持久化的方式： - **AOF 日志**：每执行一条写操作命令，就把该命令以追加的方式写入到一个文件里； - **RDB 快照**：将某一时刻的内存数据，以二进制的方式写入磁盘； - **混合持久化方式**：Redis 4.0 新增的方式，集成了 AOF 和 RBD 的优点； ### AOF ![img](assets/98987d9417b2bab43087f45fc959d32a-20230309232253633.png) > AOF 日志过大，会触发什么机制？ Redis 为了避免 AOF 文件越写越大，提供了 **AOF 重写机制**，当 AOF 文件的大小超过所设定的阈值后，Redis 就会启用 AOF 重写机制，来压缩 AOF 文件。 AOF 重写机制是在重写时，读取当前数据库中的所有键值对，然后将每一个键值对用一条命令记录到「新的 AOF 文件」，等到全部记录完后，就将新的 AOF 文件替换掉现有的 AO F 文件。 Redis 的**重写 AOF 过程是由后台子进程 \*bgrewriteaof\* 来完成的**，bgrewriteaof 子进程执行 AOF 重写期间，主进程需要执行以下三个工作:（**写时复制(\*Copy On Write\*)**） - 执行客户端发来的命令； - 将执行后的写命令追加到 「AOF 缓冲区」； - 将执行后的写命令追加到 「AOF 重写缓冲区」； ### RDB RDB 快照就是记录某一个瞬间的内存数据，记录的是实际数据， Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave，他们的区别就在于是否在「主线程」里执行： - 执行了 save 命令，就会在主线程生成 RDB 文件，由于和执行操作命令在同一个线程，所以如果写入 RDB 文件的时间太长，**会阻塞主线程**； - 执行了 bgsave 命令，会创建一个子进程来生成 RDB 文件，这样可以**避免主线程的阻塞**； Redis 还可以通过配置文件的选项来实现每隔一段时间自动执行一次 bgsave 命令，默认会提供以下配置： ```c save 900 1 save 300 10 save 60 10000 ``` 执行 bgsave 过程中，Redis 依然**可以继续处理操作命令**的。关键的技术就在于**写时复制技术** 如果主线程（父进程）要修改共享数据里的某一块数据（比如键值对 A）时，就会发生写时复制，于是这块数据的物理内存就会被复制一份（键值对 A'），然后主线程在这个数据副本（键值对 A'）进行修改操作。与此同时，bgsave 子进程可以继续把原来的数据（键值对 A）写入到 RDB 文件。 ### 为什么会有混合持久化？ Redis 4.0 提出了**混合使用 AOF 日志和内存快照** AOF 文件的**前半部分是 RDB 格式的全量数据，后半部分是 AOF 格式的增量数据**。 ![img](assets/f67379b60d151262753fec3b817b8617-20230309232312657.png) ## Redis安全控制 ### 缓存穿透--没有key 产生的背景： 缓存穿透是指使用不存在的key进行大量的高并发查询，导致缓存无法命中，每次请求都要都要穿透到后端数据库查询（同时也查不到），使得数据库的压力非常大，甚至导致数据库服务压死；**既不在缓存中，也不在数据库中** 解决方案： 1. 接口层实现api限流、用户授权、id检查等； 2. 从缓存和数据库都取不到数据的话，一样将数据库空值放入缓存中，设置30s有效期避免使用同一个id对数据库攻击压力大； 3. 布隆过滤器 ### 缓存击穿--单个key 产生背景： 在高并发的情况下，当一个缓存key过期时，因为访问该key请求较大，多个请求同时发现缓存过期，因此对多个请求同时数据库查询、同时向Redis写入缓存数据，这样会导致数据库的压力非常大； 解决方案： 1. 使用分布式锁 保证在分布式情况下，使用分布式锁保证对于每个key同时只允许只有一个线程查询到后端服务，其他没有获取到锁的权限，只需要等待即可；这种高并发压力直接转移到分布式锁上，对分布式锁的压力非常大。 2. 使用本地锁 使用本地锁与分布式锁机制一样，只不过分布式锁适应于服务集群、本地锁仅限于单个服务使用。 3. 软过过期 设置热点数据永不过期或者异步延长过期时间； 4. 布隆过滤器 ### 缓存雪崩--多个key 缓存雪崩指缓存服务器重启或者大量的缓存集中在某个时间段失效，突然给数据库产生了巨大的压力，甚至击垮数据库的情况。 解决思路：对不用的数据使用不同的失效时间，加上随机数 ## 数据库和缓存如何保证一致性？ ### 先更新数据库，再更新缓存 ![图片](assets/8febac10b14bed16cb96d1d944cd08da.png) **出现了缓存和数据库中的数据不一致的现象**。 ### 先更新缓存，再更新数据库 ![图片](assets/454a8228a6549176ad7e0484fba3c92b.png) **出现了缓存和数据库中的数据不一致的现象**。 ### 先删除缓存，再更新数据库 ![图片](assets/cc208c2931b4e889d1a58cb655537767.png) **先删除缓存，再更新数据库，在「读 + 写」并发的时候，还是会出现缓存和数据库的数据不一致的问题**。 ### 先更新数据库，再删除缓存 ![图片](assets/1cc7401143e79383ead96582ac11b615.png) ## 说说常见的缓存更新策略？ ### Cache Aside（旁路缓存）策略 **写策略的步骤：** - 先更新数据库中的数据，再删除缓存中的数据。 **读策略的步骤：** - 如果读取的数据命中了缓存，则直接返回数据； - 如果读取的数据没有命中缓存，则从数据库中读取数据，然后将数据写入到缓存，并且返回给用户。 ### Read/Write Through（读穿 / 写穿）策略 ***1、Read Through 策略*** 先查询缓存中数据是否存在，如果存在则直接返回，如果不存在，则由缓存组件负责从数据库查询数据，并将结果写入到缓存组件，最后缓存组件将数据返回给应用。 ***2、Write Through 策略*** 当有数据更新的时候，先查询要写入的数据在缓存中是否已经存在： - 如果缓存中数据已经存在，则更新缓存中的数据，并且由**缓存组件同步**更新到数据库中，然后缓存组件告知应用程序更新完成。 - 如果缓存中数据不存在，直接更新数据库，然后返回； ### Write Back（写回）策略； Write Back（写回）策略在更新数据的时候，只更新缓存，同时将缓存数据设置为脏的，然后立马返回，并不会更新数据库。对于数据库的更新，会通过批量**异步更新**的方式进行。 ## 布隆过滤器 ### 什么是布隆过滤器？ 布隆过滤器它实际上是一个很长的二进制向量和一系列随机映射函数。以Redis中的布隆过滤器实现为例，Redis中的布隆过滤器底层是**一个大型位数组（二进制数组）+多个无偏hash函数。** **一个大型位数组（二进制数组）**： ![位数组.png](assets/e94e504adc5a75a2d7f562dc44166511.png) **多个无偏hash函数：** 无偏hash函数就是能把元素的hash值计算的比较均匀的hash函数，能使得计算后的元素下标比较均匀的映射到位数组中。 如下就是一个简单的布隆过滤器示意图，其中k1、k2代表增加的元素，a、b、c即为无偏hash函数，最下层则为二进制数组。 ![布隆过滤器.png](assets/9ebde5c11ad69447314c216acf188fc8.png) ### 增删查改 * 增加元素 往布隆过滤器增加元素，添加的key需要根据k个无偏hash函数计算得到多个hash值，然后对数组长度进行取模得到数组下标的位置，然后将对应数组下标的位置的值置为1 - 通过k个无偏hash函数计算得到k个hash值 - 依次取模数组长度，得到数组索引 - 将计算得到的数组索引下标位置数据修改为1 例如，key = Liziba，无偏hash函数的个数k=3，分别为hash1、hash2、hash3。三个hash函数计算后得到三个数组下标值，并将其值修改为1. 如图所示： ![增加元素.png](assets/a3e7d217ecb825e94bdc577a467eb29d.png) * 查询元素 布隆过滤器最大的用处就在于判断某样东西一定不存在或者可能存在，而这个就是查询元素的结果。其查询元素的过程如下： - 通过k个无偏hash函数计算得到k个hash值 - 依次取模数组长度，得到数组索引 - 判断索引处的值是否全部为1，如果全部为1则存在（这种存在可能是误判），如果存在一个0则必定不存在 关于误判，其实非常好理解，hash函数在怎么好，也无法完全避免hash冲突，也就是说可能会存在多个元素计算的hash值是相同的，那么它们取模数组长度后的到的数组索引也是相同的，这就是误判的原因。例如李子捌和李子柒的hash值取模后得到的数组索引都是1，但其实这里只有李子捌，如果此时判断李子柒在不在这里，误判就出现啦！因此布隆过滤器最大的缺点误判只要知道其判断元素是否存在的原理就很容易明白了！ * 删除元素 布隆过滤器对元素的删除不太支持，目前有一些变形的特定布隆过滤器支持元素的删除！关于为什么对删除不太支持，其实也非常好理解，hash冲突必然存在，删除肯定是很苦难的！ * 修改元素 无 ## Redis为什么快 - 内存存储：Redis是一种基于内存的数据存储系统，所有数据都存储在内存中，这使得它可以快速地读取和写入数据，因为内存访问速度比磁盘快得多。 - 精简的数据结构：Redis支持多种数据结构，如字符串、列表、哈希表、集合和有序集合等。这些数据结构经过精心设计，具有高效的操作复杂度，使得Redis在执行常见的数据操作时非常快速。 - 单线程模型：Redis采用单线程模型来处理所有客户端请求。这意味着在任何给定时间点，Redis只会执行一个操作，避免了多线程之间的竞争条件和锁操作，从而减少了上下文切换的开销。单线程模型使得Redis非常高效，并且能够在现代计算机系统中充分利用CPU缓存。 - 非阻塞I/O：Redis使用了非阻塞的I/O多路复用机制，通常使用epoll或kqueue等，这使得它能够同时处理多个客户端请求而不会导致线程阻塞。这样一来，在I/O等待的过程中，Redis可以继续处理其他请求，提高了系统的吞吐量。 ## Redis 线程模型 ### Redis 是单线程吗？ **Redis 单线程指的是「接收客户端请求->解析请求 ->进行数据读写等操作->发送数据给客户端」这个过程是由一个线程（主线程）来完成的**，这也是我们常说 Redis 是单线程的原因。 但是，**Redis 程序并不是单线程的**，Redis 在启动的时候，是会**启动后台线程**（BIO）的： - **Redis 在 2.6 版本**，会启动 2 个后台线程，分别处理关闭文件、AOF 刷盘这两个任务； - **Redis 在 4.0 版本之后**，新增了一个新的后台线程，用来异步释放 Redis 内存，也就是 lazyfree 线程。 ![img](assets/后台线程.jpg) 关闭文件、AOF 刷盘、释放内存这三个任务都有各自的任务队列： - BIO_CLOSE_FILE，关闭文件任务队列：当队列有任务后，后台线程会调用 close(fd) ，将文件关闭； - BIO_AOF_FSYNC，AOF刷盘任务队列：当 AOF 日志配置成 everysec 选项后，主线程会把 AOF 写日志操作封装成一个任务，也放到队列中。当发现队列有任务后，后台线程会调用 fsync(fd)，将 AOF 文件刷盘， - BIO_LAZY_FREE，lazy free 任务队列：当队列有任务后，后台线程会 free(obj) 释放对象 / free(dict) 删除数据库所有对象 / free(skiplist) 释放跳表对象； ### Redis 单线程模式是怎样的？ ![img](assets/redis单线程模型.drawio.png) 图中的蓝色部分是一个事件循环，是由主线程负责的，可以看到网络 I/O 和命令处理都是单线程。 Redis 初始化的时候，会做下面这几件事情： - 首先，调用 epoll_create() 创建一个 epoll 对象和调用 socket() 创建一个服务端 socket - 然后，调用 bind() 绑定端口和调用 listen() 监听该 socket； - 然后，将调用 epoll_ctl() 将 listen socket 加入到 epoll，同时注册「连接事件」处理函数。 初始化完后，主线程就进入到一个**事件循环函数**，主要会做以下事情： - 首先，先调用**处理发送队列函数**，看是发送队列里是否有任务，如果有发送任务，则通过 write 函数将客户端发送缓存区里的数据发送出去，如果这一轮数据没有发送完，就会注册写事件处理函数，等待 epoll_wait 发现可写后再处理 。 - 接着，调用 epoll_wait 函数等待事件的到来： - 如果是**连接事件**到来，则会调用**连接事件处理函数**，该函数会做这些事情：调用 accpet 获取已连接的 socket -> 调用 epoll_ctl 将已连接的 socket 加入到 epoll -> 注册「读事件」处理函数； - 如果是**读事件**到来，则会调用**读事件处理函数**，该函数会做这些事情：调用 read 获取客户端发送的数据 -> 解析命令 -> 处理命令 -> 将客户端对象添加到发送队列 -> 将执行结果写到发送缓存区等待发送； - 如果是**写事件**到来，则会调用**写事件处理函数**，该函数会做这些事情：通过 write 函数将客户端发送缓存区里的数据发送出去，如果这一轮数据没有发送完，就会继续注册写事件处理函数，等待 epoll_wait 发现可写后再处理 。 ### Redis 采用单线程为什么还这么快？ 之所以 Redis 采用单线程（网络 I/O 和执行命令）那么快，有如下几个原因： - Redis 的大部分操作**都在内存中完成**，并且采用了高效的数据结构，因此 Redis 瓶颈可能是机器的内存或者网络带宽，而并非 CPU，既然 CPU 不是瓶颈，那么自然就采用单线程的解决方案了； - Redis 采用单线程模型可以**避免了多线程之间的竞争**，省去了多线程切换带来的时间和性能上的开销，而且也不会导致死锁问题。 - Redis 采用了 **I/O 多路复用机制**处理大量的客户端 Socket 请求，IO 多路复用机制是指一个线程处理多个 IO 流，就是我们经常听到的 select/epoll 机制。简单来说，在 Redis 只运行单线程的情况下，该机制允许内核中，同时存在多个监听 Socket 和已连接 Socket。内核会一直监听这些 Socket 上的连接请求或数据请求。一旦有请求到达，就会交给 Redis 线程处理，这就实现了一个 Redis 线程处理多个 IO 流的效果。 ### Redis 6.0 之前为什么使用单线程？ 使用了单线程后，可维护性高，多线程模型虽然在某些方面表现优异，但是它却引入了程序执行顺序的不确定性，带来了并发读写的一系列问题，**增加了系统复杂度、同时可能存在线程切换、甚至加锁解锁、死锁造成的性能损耗**。 ### Redis 6.0 之后为什么引入了多线程？ 随着硬件性能提升，Redis 的性能瓶颈可能出现网络 IO 的读写，也就是：**单个线程处理网络读写的速度跟不上底层网络硬件的速度**。 **Redis 多 IO 线程模型只用来处理网络读写请求，对于 Redis 的读写命令，依然是单线程处理**。 ![图片来源：后端研究所](assets/c55029a32a6448d9aa35bb3de6efcecatplv-k3u1fbpfcp-zoom-in-crop-mark4536000.awebp) ![Redis多线程与IO线程](assets/f109a45fe4904726b11fd36422f4abactplv-k3u1fbpfcp-zoom-in-crop-mark4536000.awebp) **主要流程**： 1. 主线程负责接收建立连接请求，获取 `socket` 放入全局等待读处理队列； 2. 主线程通过轮询将可读 `socket` 分配给 IO 线程； 3. 主线程阻塞等待 IO 线程读取 `socket` 完成； 4. 主线程执行 IO 线程读取和解析出来的 Redis 请求命令； 5. 主线程阻塞等待 IO 线程将指令执行结果回写回 `socket`完毕； 6. 主线程清空全局队列，等待客户端后续的请求。 思路：**将主线程 IO 读写任务拆分出来给一组独立的线程处理，使得多个 socket 读写可以并行化，但是 Redis 命令还是主线程串行执行。** ## Redis 大 Key 对持久化有什么影响？ 当 AOF 写回策略配置了 Always 策略，如果写入是一个大 Key，主线程在执行 fsync() 函数的时候，阻塞的时间会比较久，因为当写入的数据量很大的时候，数据同步到硬盘这个过程是很耗时的。 AOF 重写机制和 RDB 快照（bgsave 命令）的过程，都会分别通过 `fork()` 函数创建一个子进程来处理任务。会有两个阶段会导致阻塞父进程（主线程）： - 创建子进程的途中，由于要复制父进程的页表等数据结构，阻塞的时间跟页表的大小有关，页表越大，阻塞的时间也越长； - 创建完子进程后，如果父进程修改了共享数据中的大 Key，就会发生写时复制，这期间会拷贝物理内存，由于大 Key 占用的物理内存会很大，那么在复制物理内存这一过程，就会比较耗时，所以有可能会阻塞父进程。 大 key 除了会影响持久化之外，还会有以下的影响。 - 客户端超时阻塞。由于 Redis 执行命令是单线程处理，然后在操作大 key 时会比较耗时，那么就会阻塞 Redis，从客户端这一视角看，就是很久很久都没有响应。 - 引发网络阻塞。每次获取大 key 产生的网络流量较大，如果一个 key 的大小是 1 MB，每秒访问量为 1000，那么每秒会产生 1000MB 的流量，这对于普通千兆网卡的服务器来说是灾难性的。 - 阻塞工作线程。如果使用 del 删除大 key 时，会阻塞工作线程，这样就没办法处理后续的命令。 - 内存分布不均。集群模型在 slot 分片均匀情况下，会出现数据和查询倾斜情况，部分有大 key 的 Redis 节点占用内存多，QPS 也会比较大。 ### 如何删除大KEY - 分批次删除 每次分批删除，每次删除100个 - 异步删除（Redis 4.0版本以上） 从 Redis 4.0 版本开始，可以采用**异步删除**法，**用 unlink 命令代替 del 来删除**。这样 Redis 会将这个 key 放入到一个异步线程中进行删除，这样不会阻塞主线程。 ## redis数据结构 ### string 为什么不适用c语言默认的char* - 获取字符串长度的时间复杂度为 O（N）； - 字符串的结尾是以 “\0” 字符标识，字符串里面不能包含有 “\0” 字符，因此不能保存二进制数据； - 字符串操作函数不高效且不安全，比如有缓冲区溢出的风险，有可能会造成程序运行终止； redis自己封装了一个名为简单动态字符串（simple dynamic string，SDS） 的数据结构来表示字符串，也就是 Redis 的 String 数据类型的底层数据结构是 SDS。 ![img](assets/516738c4058cdf9109e40a7812ef4239.png) 结构中的每个成员变量分别介绍下： - **len，记录了字符串长度**。这样获取字符串长度的时候，只需要返回这个成员变量值就行，时间复杂度只需要 O（1）。 - **alloc，分配给字符数组的空间长度**。这样在修改字符串的时候，可以通过 `alloc - len` 计算出剩余的空间大小，可以用来判断空间是否满足修改需求，如果不满足的话，就会自动将 SDS 的空间扩展至执行修改所需的大小，然后才执行实际的修改操作，所以使用 SDS 既不需要手动修改 SDS 的空间大小，也不会出现前面所说的缓冲区溢出的问题。 - **flags，用来表示不同类型的 SDS**。一共设计了 5 种类型，分别是 sdshdr5、sdshdr8、sdshdr16、sdshdr32 和 sdshdr64，后面在说明区别之处。 - **buf[]，字符数组，用来保存实际数据**。不仅可以保存字符串，也可以保存二进制数据。 总的来说，Redis 的 SDS 结构在原本字符数组之上，增加了三个元数据：len、alloc、flags，用来解决 C 语言字符串的缺陷。 #### O（1）复杂度获取字符串长度 C 语言的字符串长度获取 strlen 函数，需要通过遍历的方式来统计字符串长度，时间复杂度是 O（N）。 而 Redis 的 SDS 结构因为加入了 len 成员变量，那么**获取字符串长度的时候，直接返回这个成员变量的值就行，所以复杂度只有 O（1）**。 #### 二进制安全 因为 SDS 不需要用 “\0” 字符来标识字符串结尾了，而是**有个专门的 len 成员变量来记录长度，所以可存储包含 “\0” 的数据**。但是 SDS 为了兼容部分 C 语言标准库的函数， SDS 字符串结尾还是会加上 “\0” 字符。 因此， SDS 的 API 都是以处理二进制的方式来处理 SDS 存放在 buf[] 里的数据，程序不会对其中的数据做任何限制，数据写入的时候时什么样的，它被读取时就是什么样的。 通过使用二进制安全的 SDS，而不是 C 字符串，使得 Redis 不仅可以保存文本数据，也可以保存任意格式的二进制数据。 #### 不会发生缓冲区溢出 C 语言的字符串标准库提供的字符串操作函数，大多数（比如 strcat 追加字符串函数）都是不安全的，因为这些函数把缓冲区大小是否满足操作需求的工作交由开发者来保证，程序内部并不会判断缓冲区大小是否足够用，当发生了缓冲区溢出就有可能造成程序异常结束。 所以，Redis 的 SDS 结构里引入了 alloc 和 len 成员变量，这样 SDS API 通过 `alloc - len` 计算，可以算出剩余可用的空间大小，这样在对字符串做修改操作的时候，就可以由程序内部判断缓冲区大小是否足够用。 而且，**当判断出缓冲区大小不够用时，Redis 会自动将扩大 SDS 的空间大小**，以满足修改所需的大小。 SDS 扩容的规则代码如下： ```c hisds hi_sdsMakeRoomFor(hisds s, size_t addlen) { ... ... // s目前的剩余空间已足够，无需扩展，直接返回 if (avail >= addlen) return s; //获取目前s的长度 len = hi_sdslen(s); sh = (char *)s - hi_sdsHdrSize(oldtype); //扩展之后 s 至少需要的长度 newlen = (len + addlen); //根据新长度，为s分配新空间所需要的大小 if (newlen < HI_SDS_MAX_PREALLOC) //新长度 struct test1 { char a; int b; } test1; int main() { printf("%lu\n", sizeof(test1)); return 0; } ``` 大家猜猜这个结构体大小是多少？我先直接说答案，这个结构体大小计算出来是 8。 ![img](assets/35820959e8cf4376391c427ed7f81495.png) 这是因为默认情况下，编译器是使用「字节对齐」的方式分配内存，虽然 char 类型只占一个字节，但是由于成员变量里有 int 类型，它占用了 4 个字节，所以在成员变量为 char 类型分配内存时，会分配 4 个字节，其中这多余的 3 个字节是为了字节对齐而分配的，相当于有 3 个字节被浪费掉了。 如果不想编译器使用字节对齐的方式进行分配内存，可以采用了 `__attribute__ ((packed))` 属性定义结构体，这样一来，结构体实际占用多少内存空间，编译器就分配多少空间。 比如，我用 `__attribute__ ((packed))` 属性定义下面的结构体 ，同样包含 char 和 int 两个类型的成员变量，代码如下所示： ```c #include struct __attribute__((packed)) test2 { char a; int b; } test2; int main() { printf("%lu\n", sizeof(test2)); return 0; } ``` 这时打印的结果是 5（1 个字节 char + 4 字节 int）。 ![img](assets/47e6c8fbc17fd6c89bdfcb5eedaaacff.png) 可以看得出，这是按照实际占用字节数进行分配内存的，这样可以节省内存空间。 ### ZSET（跳表） Redis 只有 Zset 对象的底层实现用到了跳表，跳表的优势是能支持平均 O(logN) 复杂度的节点查找。 zset 结构体里有两个数据结构：一个是跳表，一个是哈希表。这样的好处是既能进行高效的范围查询，也能进行高效单点查询。 ```c typedef struct zset { dict *dict; zskiplist *zsl; } zset; ``` Zset 对象在执行数据插入或是数据更新的过程中，会依次在跳表和哈希表中插入或更新相应的数据，从而保证了跳表和哈希表中记录的信息一致。但是我们讨论的时候，都会说跳表是 Zset 对象的底层数据结构，而不会提及哈希表，是因为 struct zset 中的哈希表只是用于以常数复杂度获取元素权重，大部分操作都是跳表实现的。 #### 跳表结构设计 链表在查找元素的时候，因为需要逐一查找，所以查询效率非常低，时间复杂度是O(N)，于是就出现了跳表。**跳表是在链表基础上改进过来的，实现了一种「多层」的有序链表**，这样的好处是能快读定位数据。 ![img](assets/2ae0ed790c7e7403f215acb2bd82e884.png) 图中头节点有 L0~L2 三个头指针，分别指向了不同层级的节点，然后每个层级的节点都通过指针连接起来： - L0 层级共有 5 个节点，分别是节点1、2、3、4、5； - L1 层级共有 3 个节点，分别是节点 2、3、5； - L2 层级只有 1 个节点，也就是节点 3 。 如果我们要在链表中查找节点 4 这个元素，只能从头开始遍历链表，需要查找 4 次，而使用了跳表后，只需要查找 2 次就能定位到节点 4，因为可以在头节点直接从 L2 层级跳到节点 3，然后再往前遍历找到节点 4。 可以看到，这个查找过程就是在多个层级上跳来跳去，最后定位到元素。当数据量很大时，跳表的查找复杂度就是 O(logN)。 那跳表节点是怎么实现多层级的呢？这就需要看「跳表节点」的数据结构了，如下： ```c typedef struct zskiplistNode { //Zset 对象的元素值 sds ele; //元素权重值 double score; //后向指针 struct zskiplistNode *backward; //节点的level数组，保存每层上的前向指针和跨度 struct zskiplistLevel { struct zskiplistNode *forward; unsigned long span; } level[]; } zskiplistNode; ``` Zset 对象要同时保存「元素」和「元素的权重」，对应到跳表节点结构里就是 sds 类型的 ele 变量和 double 类型的 score 变量。每个跳表节点都有一个后向指针（struct zskiplistNode *backward），指向前一个节点，目的是为了方便从跳表的尾节点开始访问节点，这样倒序查找时很方便。 跳表是一个带有层级关系的链表，而且每一层级可以包含多个节点，每一个节点通过指针连接起来，实现这一特性就是靠跳表节点结构体中的**zskiplistLevel 结构体类型的 level 数组**。 level 数组中的每一个元素代表跳表的一层，也就是由 zskiplistLevel 结构体表示，比如 leve[0] 就表示第一层，leve[1] 就表示第二层。zskiplistLevel 结构体里定义了「指向下一个跳表节点的指针」和「跨度」，跨度时用来记录两个节点之间的距离。 比如，下面这张图，展示了各个节点的跨度。 ![img](assets/3层跳表-跨度.png) 第一眼看到跨度的时候，以为是遍历操作有关，实际上并没有任何关系，遍历操作只需要用前向指针（struct zskiplistNode *forward）就可以完成了。 **跨度实际上是为了计算这个节点在跳表中的排位**。具体怎么做的呢？因为跳表中的节点都是按序排列的，那么计算某个节点排位的时候，从头节点点到该结点的查询路径上，将沿途访问过的所有层的跨度累加起来，得到的结果就是目标节点在跳表中的排位。 举个例子，查找图中节点 3 在跳表中的排位，从头节点开始查找节点 3，查找的过程只经过了一个层（L2），并且层的跨度是 3，所以节点 3 在跳表中的排位是 3。 另外，图中的头节点其实也是 zskiplistNode 跳表节点，只不过头节点的后向指针、权重、元素值都没有用到，所以图中省略了这部分。 问题来了，由谁定义哪个跳表节点是头节点呢？这就介绍「跳表」结构体了，如下所示： ```c typedef struct zskiplist { struct zskiplistNode *header, *tail; unsigned long length; int level; } zskiplist; ``` 跳表结构里包含了： - 跳表的头尾节点，便于在O(1)时间复杂度内访问跳表的头节点和尾节点； - 跳表的长度，便于在O(1)时间复杂度获取跳表节点的数量； - 跳表的最大层数，便于在O(1)时间复杂度获取跳表中层高最大的那个节点的层数量； #### 跳表节点查询过程 查找一个跳表节点的过程时，跳表会从头节点的最高层开始，逐一遍历每一层。在遍历某一层的跳表节点时，会用跳表节点中的 SDS 类型的元素和元素的权重来进行判断，共有两个判断条件： - 如果当前节点的权重「小于」要查找的权重时，跳表就会访问该层上的下一个节点。 - 如果当前节点的权重「等于」要查找的权重时，并且当前节点的 SDS 类型数据「小于」要查找的数据时，跳表就会访问该层上的下一个节点。 如果上面两个条件都不满足，或者下一个节点为空时，跳表就会使用目前遍历到的节点的 level 数组里的下一层指针，然后沿着下一层指针继续查找，这就相当于跳到了下一层接着查找。 举个例子，下图有个 3 层级的跳表。 ![img](assets/3层跳表-跨度.drawio.png) 如果要查找「元素：abcd，权重：4」的节点，查找的过程是这样的： - 先从头节点的最高层开始，L2 指向了「元素：abc，权重：3」节点，这个节点的权重比要查找节点的小，所以要访问该层上的下一个节点； - 但是该层的下一个节点是空节点（ leve[2]指向的是空节点），于是就会跳到「元素：abc，权重：3」节点的下一层去找，也就是 leve[1]; - 「元素：abc，权重：3」节点的 leve[1] 的下一个指针指向了「元素：abcde，权重：4」的节点，然后将其和要查找的节点比较。虽然「元素：abcde，权重：4」的节点的权重和要查找的权重相同，但是当前节点的 SDS 类型数据「大于」要查找的数据，所以会继续跳到「元素：abc，权重：3」节点的下一层去找，也就是 leve[0]； - 「元素：abc，权重：3」节点的 leve[0] 的下一个指针指向了「元素：abcd，权重：4」的节点，该节点正是要查找的节点，查询结束。 #### 跳表节点层数设置 跳表的相邻两层的节点数量的比例会影响跳表的查询性能。 举个例子，下图的跳表，第二层的节点数量只有 1 个，而第一层的节点数量有 6 个。 ![img](assets/2802786ab4f52c1e248904e5cef33a74.png) 这时，如果想要查询节点 6，那基本就跟链表的查询复杂度一样，就需要在第一层的节点中依次顺序查找，复杂度就是 O(N) 了。所以，为了降低查询复杂度，我们就需要维持相邻层结点数间的关系。 **跳表的相邻两层的节点数量最理想的比例是 2:1，查找复杂度可以降低到 O(logN)**。 下图的跳表就是，相邻两层的节点数量的比例是 2 : 1。 ![img](assets/cdc14698f629c74bf5a239cc8a611aeb.png) > **那怎样才能维持相邻两层的节点数量的比例为 2 : 1 呢？** 如果采用新增节点或者删除节点时，来调整跳表节点以维持比例的方法的话，会带来额外的开销。 Redis 则采用一种巧妙的方法是，**跳表在创建节点的时候，随机生成每个节点的层数**，并没有严格维持相邻两层的节点数量比例为 2 : 1 的情况。 具体的做法是，**跳表在创建节点时候，会生成范围为[0-1]的一个随机数，如果这个随机数小于 0.25（相当于概率 25%），那么层数就增加 1 层，然后继续生成下一个随机数，直到随机数的结果大于 0.25 结束，最终确定该节点的层数**。 这样的做法，相当于每增加一层的概率不超过 25%，层数越高，概率越低，层高最大限制是 64。 虽然我前面讲解跳表的时候，图中的跳表的「头节点」都是 3 层高，但是其实**如果层高最大限制是 64，那么在创建跳表「头节点」的时候，就会直接创建 64 层高的头节点**。 如下代码，创建跳表时，头节点的 level 数组有 ZSKIPLIST_MAXLEVEL个元素（层），节点不存储任何 member 和 score 值，level 数组元素的 forward 都指向NULL， span值都为0。 ```c /* Create a new skiplist. */ zskiplist *zslCreate(void) { int j; zskiplist *zsl; zsl = zmalloc(sizeof(*zsl)); zsl->level = 1; zsl->length = 0; zsl->header = zslCreateNode(ZSKIPLIST_MAXLEVEL,0,NULL); for (j = 0; j < ZSKIPLIST_MAXLEVEL; j++) { zsl->header->level[j].forward = NULL; zsl->header->level[j].span = 0; } zsl->header->backward = NULL; zsl->tail = NULL; return zsl; } ``` 其中，ZSKIPLIST_MAXLEVEL 定义的是最高的层数，Redis 7.0 定义为 32，Redis 5.0 定义为 64，Redis 3.0 定义为 32。 #### 为什么用跳表而不用平衡树？ - **从内存占用上来比较，跳表比平衡树更灵活一些**。平衡树每个节点包含 2 个指针（分别指向左右子树），而跳表每个节点包含的指针数目平均为 1/(1-p)，具体取决于参数 p 的大小。如果像 Redis里的实现一样，取 p=1/4，那么平均每个节点包含 1.33 个指针，比平衡树更有优势。 - **在做范围查找的时候，跳表比平衡树操作要简单**。在平衡树上，我们找到指定范围的小值之后，还需要以中序遍历的顺序继续寻找其它不超过大值的节点。如果不对平衡树进行一定的改造，这里的中序遍历并不容易实现。而在跳表上进行范围查找就非常简单，只需要在找到小值之后，对第 1 层链表进行若干步的遍历就可以实现。 - **从算法实现难度上来比较，跳表比平衡树要简单得多**。平衡树的插入和删除操作可能引发子树的调整，逻辑复杂，而跳表的插入和删除只需要修改相邻节点的指针，操作简单又快速。 ## Redis主从复制 ![图片](assets/22c7fe97ce5d3c382b08d83a4d8a5b96.png) 这个模式可以保证多台服务器的数据一致性，且主从服务器之间采用的是「读写分离」的方式。 主服务器可以进行读写操作，当发生写操作时自动将写操作同步给从服务器，而从服务器一般是只读，并接受主服务器同步过来写操作命令，然后执行这条命令。 ![图片](assets/2b7231b6aabb9a9a2e2390ab3a280b2d-20230309232920063.png) 也就是说，所有的数据修改只在主服务器上进行，然后将最新的数据同步给从服务器，这样就使得主从服务器的数据是一致的。 ### 第一次同步 主从服务器间的第一次同步的过程可分为三个阶段： - 第一阶段是建立链接、协商同步； - 第二阶段是主服务器同步数据给从服务器； - 第三阶段是主服务器发送新写操作命令给从服务器。 ![图片](assets/ea4f7e86baf2435af3999e5cd38b6a26.png) 接下来，我在具体介绍每一个阶段都做了什么。 *第一阶段：建立链接、协商同步* 执行了 replicaof 命令后，从服务器就会给主服务器发送 `psync` 命令，表示要进行数据同步。 psync 命令包含两个参数，分别是**主服务器的 runID** 和**复制进度 offset**。 - runID，每个 Redis 服务器在启动时都会自动生产一个随机的 ID 来唯一标识自己。当从服务器和主服务器第一次同步时，因为不知道主服务器的 run ID，所以将其设置为 "?"。 - offset，表示复制的进度，第一次同步时，其值为 -1。 主服务器收到 psync 命令后，会用 `FULLRESYNC` 作为响应命令返回给对方。 并且这个响应命令会带上两个参数：主服务器的 runID 和主服务器目前的复制进度 offset。从服务器收到响应后，会记录这两个值。 FULLRESYNC 响应命令的意图是采用**全量复制**的方式，也就是主服务器会把所有的数据都同步给从服务器。 所以，第一阶段的工作时为了全量复制做准备。 那具体怎么全量同步呀呢？我们可以往下看第二阶段。 *第二阶段：主服务器同步数据给从服务器* 接着，主服务器会执行 bgsave 命令来生成 RDB 文件，然后把文件发送给从服务器。 从服务器收到 RDB 文件后，会先清空当前的数据，然后载入 RDB 文件。 这里有一点要注意，主服务器生成 RDB 这个过程是不会阻塞主线程的，因为 bgsave 命令是产生了一个子进程来做生成 RDB 文件的工作，是异步工作的，这样 Redis 依然可以正常处理命令。 但是，这期间的写操作命令并没有记录到刚刚生成的 RDB 文件中，这时主从服务器间的数据就不一致了。 那么为了保证主从服务器的数据一致性，**主服务器在下面这三个时间间隙中将收到的写操作命令，写入到 replication buffer 缓冲区里**： - 主服务器生成 RDB 文件期间； - 主服务器发送 RDB 文件给从服务器期间； - 「从服务器」加载 RDB 文件期间； *第三阶段：主服务器发送新写操作命令给从服务器* 在主服务器生成的 RDB 文件发送完，从服务器收到 RDB 文件后，丢弃所有旧数据，将 RDB 数据载入到内存。完成 RDB 的载入后，会回复一个确认消息给主服务器。 接着，主服务器将 replication buffer 缓冲区里所记录的写操作命令发送给从服务器，从服务器执行来自主服务器 replication buffer 缓冲区里发来的命令，这时主从服务器的数据就一致了。 至此，主从服务器的第一次同步的工作就完成了。 ### 命令传播 主从服务器在完成第一次同步后，双方之间就会维护一个 TCP 连接。 ![图片](assets/03eacec67cc58ff8d5819d0872ddd41e.png) 后续主服务器可以通过这个连接继续将写操作命令传播给从服务器，然后从服务器执行该命令，使得与主服务器的数据库状态相同。 而且这个连接是长连接的，目的是避免频繁的 TCP 连接和断开带来的性能开销。 上面的这个过程被称为**基于长连接的命令传播**，通过这种方式来保证第一次同步后的主从服务器的数据一致性。 ### 分摊主服务器的压力 在前面的分析中，我们可以知道主从服务器在第一次数据同步的过程中，主服务器会做两件耗时的操作：生成 RDB 文件和传输 RDB 文件。 主服务器是可以有多个从服务器的，如果从服务器数量非常多，而且都与主服务器进行全量同步的话，就会带来两个问题： - 由于是通过 bgsave 命令来生成 RDB 文件的，那么主服务器就会忙于使用 fork() 创建子进程，如果主服务器的内存数据非大，在执行 fork() 函数时是会阻塞主线程的，从而使得 Redis 无法正常处理请求； - 传输 RDB 文件会占用主服务器的网络带宽，会对主服务器响应命令请求产生影响。 这种情况就好像，刚创业的公司，由于人不多，所以员工都归老板一个人管，但是随着公司的发展，人员的扩充，老板慢慢就无法承担全部员工的管理工作了。 要解决这个问题，老板就需要设立经理职位，由经理管理多名普通员工，然后老板只需要管理经理就好。 Redis 也是一样的，从服务器可以有自己的从服务器，我们可以把拥有从服务器的从服务器当作经理角色，它不仅可以接收主服务器的同步数据，自己也可以同时作为主服务器的形式将数据同步给从服务器，组织形式如下图： ![图片](assets/4d850bfe8d712d3d67ff13e59b919452.png) 此时如果目标服务器本身也是「从服务器」，那么该目标服务器就会成为「经理」的角色，不仅可以接受主服务器同步的数据，也会把数据同步给自己旗下的从服务器，从而减轻主服务器的负担。 ### 增量复制 如果主从服务器间的网络连接断开了，那么就无法进行命令传播了，这时从服务器的数据就没办法和主服务器保持一致了，客户端就可能从「从服务器」读到旧的数据。 ![图片](assets/4845008abadaa871613873f5ffdcb542.png) 那么问题来了，如果此时断开的网络，又恢复正常了，要怎么继续保证主从服务器的数据一致性呢？ 在 Redis 2.8 之前，如果主从服务器在命令同步时出现了网络断开又恢复的情况，从服务器就会和主服务器重新进行一次全量复制，很明显这样的开销太大了，必须要改进一波。 所以，从 Redis 2.8 开始，网络断开又恢复后，从主从服务器会采用**增量复制**的方式继续同步，也就是只会把网络断开期间主服务器接收到的写操作命令，同步给从服务器。 网络恢复后的增量复制过程如下图： ![图片](assets/e081b470870daeb763062bb873a4477e.png) 主要有三个步骤： - 从服务器在恢复网络后，会发送 psync 命令给主服务器，此时的 psync 命令里的 offset 参数不是 -1； - 主服务器收到该命令后，然后用 CONTINUE 响应命令告诉从服务器接下来采用增量复制的方式同步数据； - 然后主服务将主从服务器断线期间，所执行的写命令发送给从服务器，然后从服务器执行这些命令。 那么关键的问题来了，**主服务器怎么知道要将哪些增量数据发送给从服务器呢？** 答案藏在这两个东西里： - **repl_backlog_buffer**，是一个「**环形**」缓冲区，用于主从服务器断连后，从中找到差异的数据； - **replication offset**，标记上面那个缓冲区的同步进度，主从服务器都有各自的偏移量，主服务器使用 master_repl_offset 来记录自己「*写*」到的位置，从服务器使用 slave_repl_offset 来记录自己「*读*」到的位置。 那 repl_backlog_buffer 缓冲区是什么时候写入的呢？ 在主服务器进行命令传播时，不仅会将写命令发送给从服务器，还会将写命令写入到 repl_backlog_buffer 缓冲区里，因此 这个缓冲区里会保存着最近传播的写命令。 网络断开后，当从服务器重新连上主服务器时，从服务器会通过 psync 命令将自己的复制偏移量 slave_repl_offset 发送给主服务器，主服务器根据自己的 master_repl_offset 和 slave_repl_offset 之间的差距，然后来决定对从服务器执行哪种同步操作： - 如果判断出从服务器要读取的数据还在 repl_backlog_buffer 缓冲区里，那么主服务器将采用**增量同步**的方式； - 相反，如果判断出从服务器要读取的数据已经不存在 repl_backlog_buffer 缓冲区里，那么主服务器将采用**全量同步**的方式。 当主服务器在 repl_backlog_buffer 中找到主从服务器差异（增量）的数据后，就会将增量的数据写入到 replication buffer 缓冲区，这个缓冲区我们前面也提到过，它是缓存将要传播给从服务器的命令。 ![图片](assets/2db4831516b9a8b79f833cf0593c1f12.png) repl_backlog_buffer 缓行缓冲区的默认大小是 1M，并且由于它是一个环形缓冲区，所以当缓冲区写满后，主服务器继续写入的话，就会覆盖之前的数据。因此，当主服务器的写入速度远超于从服务器的读取速度，缓冲区的数据一下就会被覆盖。 那么在网络恢复时，如果从服务器想读的数据已经被覆盖了，主服务器就会采用全量同步，这个方式比增量同步的性能损耗要大很多。 因此，**为了避免在网络恢复时，主服务器频繁地使用全量同步的方式，我们应该调整下 repl_backlog_buffer 缓冲区大小，尽可能的大一些**，减少出现从服务器要读取的数据被覆盖的概率，从而使得主服务器采用增量同步的方式。 ### 面试精选 1. Redis主从节点时长连接还是短连接？ 长连接 2. 怎么判断 Redis 某个节点是否正常工作？ Redis 判断节点是否正常工作，基本都是通过互相的 ping-pong 心态检测机制，如果有一半以上的节点去 ping 一个节点的时候没有 pong 回应，集群就会认为这个节点挂掉了，会断开与这个节点的连接。 Redis 主从节点发送的心态间隔是不一样的，而且作用也有一点区别： - Redis 主节点默认每隔 10 秒对从节点发送 ping 命令，判断从节点的存活性和连接状态，可通过参数repl-ping-slave-period控制发送频率。 - Redis 从节点每隔 1 秒发送 replconf ack{offset} 命令，给主节点上报自身当前的复制偏移量，目的是为了： - 实时监测主从节点网络状态； - 上报自身复制偏移量， 检查复制数据是否丢失， 如果从节点数据丢失， 再从主节点的复制缓冲区中拉取丢失数据。 3. 主从复制架构中，过期key如何处理？ 主节点处理了一个key或者通过淘汰算法淘汰了一个key，这个时间主节点模拟一条del命令发送给从节点，从节点收到该命令后，就进行删除key的操作。 4. Redis 是同步复制还是异步复制？ Redis 主节点每次收到写命令之后，先写到内部的缓冲区，然后异步发送给从节点。 5. 主从复制中两个 Buffer(replication buffer 、repl backlog buffer)有什么区别？ replication buffer 、repl backlog buffer 区别如下： - 出现的阶段不一样： - repl backlog buffer 是在增量复制阶段出现，**一个主节点只分配一个 repl backlog buffer**； - replication buffer 是在全量复制阶段和增量复制阶段都会出现，**主节点会给每个新连接的从节点，分配一个 replication buffer**； - 这两个 Buffer 都有大小限制的，当缓冲区满了之后，发生的事情不一样： - 当 repl backlog buffer 满了，因为是环形结构，会直接**覆盖起始位置数据**; - 当 replication buffer 满了，会导致连接断开，删除缓存，从节点重新连接，**重新开始全量复制**。 ### 如何应对主从数据不一致？ > **为什么会出现主从数据不一致？** 主从数据不一致，就是指客户端从从节点中读取到的值和主节点中的最新值并不一致。 之所以会出现主从数据不一致的现象，是**因为主从节点间的命令复制是异步进行的**，所以无法实现强一致性保证（主从数据时时刻刻保持一致）。 具体来说，在主从节点命令传播阶段，主节点收到新的写命令后，会发送给从节点。但是，主节点并不会等到从节点实际执行完命令后，再把结果返回给客户端，而是主节点自己在本地执行完命令后，就会向客户端返回结果了。如果从节点还没有执行主节点同步过来的命令，主从节点间的数据就不一致了。 > **如何如何应对主从数据不一致？** 第一种方法，尽量保证主从节点间的网络连接状况良好，避免主从节点在不同的机房。 第二种方法，可以开发一个外部程序来监控主从节点间的复制进度。具体做法： - Redis 的 INFO replication 命令可以查看主节点接收写命令的进度信息（master_repl_offset）和从节点复制写命令的进度信息（slave_repl_offset），所以，我们就可以开发一个监控程序，先用 INFO replication 命令查到主、从节点的进度，然后，我们用 master_repl_offset 减去 slave_repl_offset，这样就能得到从节点和主节点间的复制进度差值了。 - 如果某个从节点的进度差值大于我们预设的阈值，我们可以让客户端不再和这个从节点连接进行数据读取，这样就可以减少读到不一致数据的情况。不过，为了避免出现客户端和所有从节点都不能连接的情况，我们需要把复制进度差值的阈值设置得大一些。 ### 主从切换如何减少数据丢失？ 主从切换过程中，产生数据丢失的情况有两种： - 异步复制同步丢失 - 集群产生脑裂数据丢失 我们不可能保证数据完全不丢失，只能做到使得尽量少的数据丢失。 #### 异步复制同步丢失 对于 Redis 主节点与从节点之间的数据复制，是异步复制的，当客户端发送写请求给主节点的时候，客户端会返回 ok，接着主节点将写请求异步同步给各个从节点，但是如果此时主节点还没来得及同步给从节点时发生了断电，那么主节点内存中的数据会丢失。 > **减少异步复制的数据丢失的方案** Redis 配置里有一个参数 min-slaves-max-lag，表示一旦所有的从节点数据复制和同步的延迟都超过了 min-slaves-max-lag 定义的值，那么主节点就会拒绝接收任何请求。 假设将 min-slaves-max-lag 配置为 10s 后，根据目前 master->slave 的复制速度，如果数据同步完成所需要时间超过10s，就会认为 master 未来宕机后损失的数据会很多，master 就拒绝写入新请求。这样就能将 master 和 slave 数据差控制在10s内，即使 master 宕机也只是这未复制的 10s 数据。 那么对于客户端，当客户端发现 master 不可写后，我们可以采取降级措施，将数据暂时写入本地缓存和磁盘中，在一段时间（等 master 恢复正常）后重新写入 master 来保证数据不丢失，也可以将数据写入 kafka 消息队列，等 master 恢复正常，再隔一段时间去消费 kafka 中的数据，让将数据重新写入 master 。 #### 集群产生脑裂数据丢失 先来理解集群的脑裂现象，这就好比一个人有两个大脑，那么到底受谁控制呢？ 那么在 Redis 中，集群脑裂产生数据丢失的现象是怎样的呢？ 在 Redis 主从架构中，部署方式一般是「一主多从」，主节点提供写操作，从节点提供读操作。 如果主节点的网络突然发生了问题，它与所有的从节点都失联了，但是此时的主节点和客户端的网络是正常的，这个客户端并不知道 Redis 内部已经出现了问题，还在照样的向这个失联的主节点写数据（过程A），此时这些数据被主节点缓存到了缓冲区里，因为主从节点之间的网络问题，这些数据都是无法同步给从节点的。 这时，哨兵也发现主节点失联了，它就认为主节点挂了（但实际上主节点正常运行，只是网络出问题了），于是哨兵就会在从节点中选举出一个 leeder 作为主节点，这时集群就有两个主节点了 —— **脑裂出现了**。 这时候网络突然好了，哨兵因为之前已经选举出一个新主节点了，它就会把旧主节点降级为从节点（A），然后从节点（A）会向新主节点请求数据同步，**因为第一次同步是全量同步的方式，此时的从节点（A）会清空掉自己本地的数据，然后再做全量同步。所以，之前客户端在过程 A 写入的数据就会丢失了，也就是集群产生脑裂数据丢失的问题**。 总结一句话就是：由于网络问题，集群节点之间失去联系。主从数据不同步；重新平衡选举，产生两个主服务。等网络恢复，旧主节点会降级为从节点，再与新主节点进行同步复制的时候，由于会从节点会清空自己的缓冲区，所以导致之前客户端写入的数据丢失了。 > **减少脑裂的数据丢的方案** 当主节点发现「从节点下线的数量太多」，或者「网络延迟太大」的时候，那么主节点会禁止写操作，直接把错误返回给客户端。 在 Redis 的配置文件中有两个参数我们可以设置： - min-slaves-to-write x，主节点必须要有**至少 x 个从节点连接**，如果小于这个数，主节点会禁止写数据。 - min-slaves-max-lag x，主从数据复制和同步的延迟**不能超过 x 秒**，如果主从同步的延迟超过 x 秒，主节点会禁止写数据。 我们可以把 min-slaves-to-write 和 min-slaves-max-lag 这两个配置项搭配起来使用，分别给它们设置一定的阈值，假设为 N 和 T。 这两个配置项组合后的要求是，**主节点连接的从节点中至少有 N 个从节点，「并且」主节点进行数据复制时的 ACK 消息延迟不能超过 T 秒**，否则，主节点就不会再接收客户端的写请求了。 即使原主节点是假故障，它在假故障期间也无法响应哨兵心跳，也不能和从节点进行同步，自然也就无法和从节点进行 ACK 确认了。这样一来，min-slaves-to-write 和 min-slaves-max-lag 的组合要求就无法得到满足，**原主节点就会被限制接收客户端写请求，客户端也就不能在原主节点中写入新数据了**。 **等到新主节点上线时，就只有新主节点能接收和处理客户端请求，此时，新写的数据会被直接写到新主节点中。而原主节点会被哨兵降为从节点，即使它的数据被清空了，也不会有新数据丢失。我再来给你举个例子。** 假设我们将 min-slaves-to-write 设置为 1，把 min-slaves-max-lag 设置为 12s，把哨兵的 down-after-milliseconds 设置为 10s，主节点因为某些原因卡住了 15s，导致哨兵判断主节点客观下线，开始进行主从切换。同时，因为原主节点卡住了 15s，没有一个从节点能和原主节点在 12s 内进行数据复制，原主节点也无法接收客户端请求了。这样一来，主从切换完成后，也只有新主节点能接收请求，不会发生脑裂，也就不会发生数据丢失的问题了 ## 为什么要有哨兵机制？ ### 为什么要有哨兵机制？ 在 Redis 的主从架构中，由于主从模式是读写分离的，如果主节点（master）挂了，那么将没有主节点来服务客户端的写操作请求，也没有主节点给从节点（slave）进行数据同步了。 ![主节点挂了](assets/db568766644a4d10b8a91cdd2f8a4070.png) 这时如果要恢复服务的话，需要人工介入，选择一个「从节点」切换为「主节点」，然后让其他从节点指向新的主节点，同时还需要通知上游那些连接 Redis 主节点的客户端，将其配置中的主节点 IP 地址更新为「新主节点」的 IP 地址。 这样也不太“智能”了，要是有一个节点能监控「主节点」的状态，当发现主节点挂了 ，它自动将一个「从节点」切换为「主节点」的话，那么可以节省我们很多事情啊！ Redis 在 2.8 版本以后提供的**哨兵（\*Sentinel\*）机制**，它的作用是实现**主从节点故障转移**。它会监测主节点是否存活，如果发现主节点挂了，它就会选举一个从节点切换为主节点，并且把新主节点的相关信息通知给从节点和客户端。 ### 哨兵机制是如何工作的？ 哨兵其实是一个运行在特殊模式下的 Redis 进程，所以它也是一个节点。从“哨兵”这个名字也可以看得出来，它相当于是“观察者节点”，观察的对象是主从节点。 当然，它不仅仅是观察那么简单，在它观察到有异常的状况下，会做出一些“动作”，来修复异常状态。 哨兵节点主要负责三件事情：**监控、选主、通知**。 ![哨兵的职责](assets/775865f6bd894dfba8d373ee54d79af1.png) ### 如何判断主节点真的故障了？ 哨兵会每隔 1 秒给所有主从节点发送 PING 命令，当主从节点收到 PING 命令后，会发送一个响应命令给哨兵，这样就可以判断它们是否在正常运行。 ![哨兵监控主从节点](assets/26f88373d8454682b9e0c1d4fd1611b4-20230309233114856.png) 如果主节点或者从节点没有在规定的时间内响应哨兵的 PING 命令，哨兵就会将它们标记为「**主观下线**」。这个「规定的时间」是配置项 `down-after-milliseconds` 参数设定的，单位是毫秒。 > **主观下线？难道还有客观下线？** 是的没错，客观下线只适用于主节点。 之所以针对「主节点」设计「主观下线」和「客观下线」两个状态，是因为有可能「主节点」其实并没有故障，可能只是因为主节点的系统压力比较大或者网络发送了拥塞，导致主节点没有在规定时间内响应哨兵的 PING 命令。 所以，为了减少误判的情况，哨兵在部署的时候不会只部署一个节点，而是用多个节点部署成**哨兵集群**（*最少需要三台机器来部署哨兵集群*），**通过多个哨兵节点一起判断，就可以就可以避免单个哨兵因为自身网络状况不好，而误判主节点下线的情况**。同时，多个哨兵的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低。 具体是怎么判定主节点为「客观下线」的呢？ 当一个哨兵判断主节点为「主观下线」后，就会向其他哨兵发起命令，其他哨兵收到这个命令后，就会根据自身和主节点的网络状况，做出赞成投票或者拒绝投票的响应。 ![img](assets/13e4361407ba46979e802eaa654dcf67.png) 当这个哨兵的赞同票数达到哨兵配置文件中的 quorum 配置项设定的值后，这时主节点就会被该哨兵标记为「客观下线」。 例如，现在有 3 个哨兵，quorum 配置的是 2，那么一个哨兵需要 2 张赞成票，就可以标记主节点为“客观下线”了。这 2 张赞成票包括哨兵自己的一张赞成票和另外两个哨兵的赞成票。 PS：quorum 的值一般设置为哨兵个数的二分之一加1，例如 3 个哨兵就设置 2。 哨兵判断完主节点客观下线后，哨兵就要开始在多个「从节点」中，选出一个从节点来做新主节点。 ## Redis热KEY问题 ### 引发问题 - 占用大量的CPU资源，影响其他请求并导致整体性能降低。 - 集群架构下，产生访问倾斜，即某个数据分片被大量访问，而其他数据分片处于空闲状态，可能引起该数据分片的连接数被耗尽，新的连接建立请求被拒绝等问题。 - 在抢购或秒杀场景下，可能因商品对应库存Key的请求量过大，超出Redis处理能力造成超卖。 - 热Key的请求压力数量超出Redis的承受能力易造成缓存击穿，即大量请求将被直接指向后端的存储层，导致存储访问量激增甚至宕机，从而影响其他业务。 ### 如何查找 1. 根据业务经验，预估哪些是热key。 - 优点：简单直接。 - 缺点：但并不是所有业务都能预估出哪些key是热key。 2. 在客户端收集。在操作redis之前，加上统计频次的逻辑，然后将统计数据发送给一个聚合计算的服务进行统计。 - 优点：方案简单。 - 缺点：无法支持大公司多语言环境的SDK，或者说多语言SDK对齐比较困难。此外SDK的维护升级成本会很高。 3. 在proxy层收集。有些服务在请求redis之前会请求一个proxy服务，这种场景可以使用在proxy层收集热key数据，收集机制类似于在客户端收集。 - 优点：方案对使用方完全透明；没有SDK多语言异构和升级成本高的问题。 - 缺点：并不是所有场景都会有proxy层。 4. redis集群监控。如果出现某个实例qps倾斜，说明可能存在热key。 - 优点：不需要额外开发。 - 缺点：每次发生状况需要人工排查，因为热key只是导致qps倾斜的一种可能。 5. redis 4.0版本之后热点key发现功能。执行redis-cli时加上 ```shell –-hotkeys ``` 选项即可。 - 优点：不需要额外开发。 - 缺点：该参数在执行的时候，如果key比较多，执行耗时会非常长，由此导致查询结果的实时性并不好。 6. redis客户端使用TCP协议与服务端进行交互。通过脚本监听端口，解析网络包并进行分析。 - 优点：对原有的业务系统没有改造。 - 缺点：开发成本高，维护困难，有丢包可能性。 ### 如何解决 1. 热key统计可以使用LFU数据结构并结合上面的发现方法，将最热topN的key进行统计，然后在client端使用本地缓存，从而降低redis集群对热key的访问量，但这种方法带来两个问题： 1. 如果对所有热key进行本地缓存，那么本地缓存是否会过大，从而影响应用程序本身的性能开销。 2. 可能需要保证本地缓存和redis数据的一致性。 2. 将热key加上前缀或者后缀，把热key的数量从1个变成实例个数，利用分片特性将这n个key分散在不同节点上，这样就可以在访问的时候，采用客户端[负载均衡](https://cloud.tencent.com/product/clb?from_column=20065&from=20065)的方式，随机选择一个key进行访问，将访问压力分散到不同的实例中。这个方案有个明显的缺点，就是缓存的维护成本大：假如有n为100，则更新或者删除key的时候需要操作100个key。 3. 利用读写分离，通过主从复制的方式，增加slave节点来实现读请求的负载均衡。这个方案明显的缺点就是使用机器硬抗热key的数据，资源耗费严重；而且引入读写分离架构，增加节点数量，都会增加系统的复杂度降低稳定性。