Redis
2024-01-29 14:16:46 0 举报AI智能生成
登录查看完整内容
极客时间Redis 系统思维导图
作者其他创作
大纲/内容
字节数组 二进制安全
<1MB free = len；>1MB free = 1MB
空间预分配，惰性释放 (free记录空闲空间) ，来减少内存重分配
SDS 动态字符串
双向链表
可以存储字符串或整数
无序，只能通过遍历查找
压缩列表节点有一个 previous_entry_length 来记录前一个结点长度，长度 < 254 用一个字节保存，否则用 5 个 字节，如果将一个大于等于结点插入到列表中，可能引起后续，previous_entry_length 全部改变
连锁更新
压缩列表
哈希表
跳表更容易实现，不易出错
区间查询跳表效率更高
更加灵活，可以通过改变节点抽取的间隔，平衡时间和空间复杂度
为什么不用平衡树 (红黑树)
1 - 32 的随机数，也就是说 redis 中的跳跃表层数最大为 32
Redis 中跳表节点高度是
跳表 O(logn)
只能存储整数
从小到大有序，不重复，支持二分
添加的元素所占字节数比所有元素大
引发升级
我们不用担心内心添加元素的类型与数组类型不一致
升级好处
升级
整数数组
因为如果 ziplist 占据内存太大，重新分配内存和拷贝内存就会有很大的消耗
为什么压缩列表不适合存储大型字符串
内存利用率高
数组对 CPU 高速缓存支持更友好
程序局部性原理
整数数组和压缩列表在查找时间复杂度方面并没有很大的优势，那为什么 Redis 还会把它们作为底层数据结构呢
它们的操作特征都是顺序读写，也就是通过数组下标或者链表的指针逐个元素访问，操作复杂度基本是 O(N)
整数数组、双向链表
头尾 O(1) 其余 O(n)
压缩列表
增加了多级索引，通过索引位置的几个跳转，实现数据的快速定位 O(logn)
跳表
O(1)
哈希表
查找的时间复杂度
Redis 底层数据结构
全局哈希表，其实就是一个数组，数组的每个元素称为一个哈希桶，哈希桶中的 entry 元素中保存了 *key 和 *value 指针， (*next)，分别指向了实际的 键 和 值
键和值用什么结构组织
注意 过期 和 淘汰不是一个意思
对内存友好，但是会占用CPU，影响吞吐量
定时删除
下次访问到键，才会删除，对CPU友好，但是导致内存泄漏
惰性删除
隔一段时间进行一次删除，通过限制删除操作 执行时间 和 频率 减少操作使用 CPU时间，也一定层度上避免了内存浪费
Redis 每 100 毫秒采集默认 20 个 key，删除过期 key
如果超过 25% 的 key 过期了会持续删，导致阻塞，可以在过期函数上加一个随机数
定期删除
Redis 采用惰性删除和定期删除
过期键删除策略
生成RDB不会保存过期键
载入RDB，主库不会加载过期键，从库会，但是主从同步后，数据又一致了
RDB
AOF写入时候，过期键会被写入，当过期键被删除，会AOF文件末尾显示追加删除操作
AOF重写，不会写入过期键
AOF
AOF 与 RDB 对过期键的处理
文件事件处理器是基于单 Reactor 单线程模式
套接字
I/O多路复用程序
文件事件分派器
事件处理器
文件事件
定时事件
serverCron 函数负责管理服务器的资源
周期事件
时间事件
事件
hash 冲突
为什么哈希表操作变慢了
rehash 不是一次完成的，有一个 rehashidx 属性，在 rehash 期间，每次增删改查除了执行指定的操作之外，还会顺带将原 hash 表 rehashidx 索引上的键值对 rehash 到新 hash表，完成后 rehashidx+1
渐进式 rehash
客户端将命令转成协议通过连接到服务端的套接字发送给服务器
服务端读取套接字中命令请求，将其保存到客户端输入缓冲区，并提取出命令参数和参数个数保存在客户端状态中，清空输入缓存
查询命令表，并将查询到的命令保存到客户端状态中
执行预备操作：如检查命令是否合法，客户端是否有权限，是否要先进行内存回收
调用命令的实现函数，并将命令回复保存到客户端状态的输出缓冲区，将客户端套接字的可写事件和命令回复处理器关联在一起，当客户端准备好接收消息时，触发可写事件，命令回复器将信息全部写入客户端套接字，解除命令回复处理器与套接字事件关联，清空客户端输出缓冲区
主从复制将命令发给从服务器；开启了AOF 持久化，将命令写入 AOF 文件的内存缓冲区
客户端接收到回复并将回复转换格式后打印
服务端处理命令请求过程
《Redis 设计 与 实现》
一个键值数据库包括了 访问框架、索引模块、操作模块 和 存储模块四部分
一个键值数据库包含什么
内存数据库
底层数据结构
Redis 的网络 IO 和 键值对读写是由一个线程来完成的，多线程存在共享资源的并发访问控制问题，使用单线程可以避免，同时实现简单
多路复用机制
硬件性能提升，瓶颈在 IO
Redis 6.0 之后为何引入了多线程
使用的单线程
Redis 为什么快
可以避免出现记录错误命令的情况
不会阻塞当前的写操作
写后日志好处
写 AOF 日志也是在主线程中执行的，可能阻塞后续操作
如果 Redis 当数据库，写完内存没写AOF宕机了，导致恢复的时候数据丢失
写后日志存在的两个潜在的风险
同步写回：每个写命令执行完，立马同步地将日志写回磁盘
Always
每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘
Everysec
No
三种写回策略
写后日志 AOF
文件系统本身对文件大小有限制
如果文件太大，之后再往里面追加命令记录的话，效率也会变低
如果发生宕机，用AOF恢复过程慢
为什么需要重写
主线程 fork 出一个子进程，由子进程执行 AOF 重写，采用了 COW ，在此期间，如果 Redis 执行了写命令，会将其写入 AOF 缓冲区并定期写入同步到 AOF 文件，也会写入到 AOF 重写缓冲区，当 AOF 重写完成，写入新的 AOF 文件
重写机制：一个拷贝，两处日志
AOF 重写
宕机了，Redis 如何避免数据丢失
save：在主线程中执行，会导致阻塞
bgsave(默认)：创建一个子进程，专门用于写入 RDB 文件，避免了主线程的阻塞。使用写时复制，在执行快照的同时，正常处理写操作
Redis 生成 RDB 的两种方式
内存快照： 宕机后，Redis 如何实现快速恢复
RDB 只是单纯用来快速恢复的， 数据不丢失还是得依赖 AOF 的 always
数据不能丢失时，内存快照和 AOF 的混合使用
如果允许分钟级别的数据丢失，丢失数据不敏感，可以只使用 RDB
如果只用 AOF，优先使用 everysec 的配置选项，因为它在可靠性和性能之间取了一个平衡
AOF RDB 如何选择
子进程复制了主进程的页表，所以通过页表映射，能读到主线程的原始数据，而当有新数据写入或数据修改时，主线程会把新数据或修改后的数据写到一个新的物理内存地址上，并修改主线程自己的页表映射
写时复制
一是数据尽量少丢失
增加副本冗余量，即使有一个实例出现了故障，其他实例也可以对外提供服务，并使用主从库模式，以保证数据副本的一致
二是服务尽量少中断
从库比较多，都和主库复制，fork 这个操作会阻塞主线程处理正常请求，从而导致主库响应应用程序的请求速度变慢
从库比较多可以采用主 — 从 — 从模式
replicaof ip port 建立主从关系
psync runID 为 ?，offset -1
FULLRESYNC 主库 runID 和 目前的复制进度 offset，返回给从库
第一阶段
bgsave 命令，生成 RDB 文件发给从库
replication buffer
第二阶段
发送 replication buffer
第三阶段
全量复制 3个阶段
主从之间建立长网络连接，进行基于长连接的命令传播
长连接复制
psync
repl_backlog_buffer 复制挤压缓冲区
Redis 2.8 网络断连 增量复制
主从同步原理
Redis 如何高可靠性
主观下线
quorum 一般配置为 n/2+1
当有 quorum 个哨兵实例做出 Y 响应，就可以标记主库为 \"客观下线\"
客观下线
监控任务中，哨兵需要判断主库是否处于下线状态
监控
判断客观下线后，这个哨兵就可以再给其他哨兵发送命令，表明希望由自己来执行主从切换，并让所有其他哨兵进行投票，并且他会投自己一票，后续接收到别人的投票请求会投反对票
拿到半数以上的赞成票并且拿到的票数大于等于哨兵配置文件中的 quorum，成为 Leader 由它来执行主从切换
本轮没有选出 Leader，哨兵集群会等待一段时间 (也就是哨兵故障转移超时时间的 2 倍)，再重新选举
选举领头 Sentinel
检查从库的当前在线状态，排除不在线，并判断在线从库的网络连接状态 (使用配置项 down-after-milliseconds(主从库断连的最大连接超时时间) * 10 (超过十次) 就排除它)
依据按照从库优先级 、从库复制进度以及从库 ID 号选出新主库
选出新主库
让从库复制新主库；客户端把请求发送到新主库
通知
哨兵检测主库多久没有响应就提升从库为新的主库，这个时间是可以配置的（down-after-milliseconds参数）
哨兵机制的基本流程
主库挂了，如何不间断服务
sentinel monitor <master-name> <ip> <redis-port> <quorum> 哨兵与主库建立连接
如何配置集群
哨兵如何建立与从库的连接
哨兵集群的组成和运行机制
通过 pub/sub 机制
哨兵和客户端之间如何进行信息同步
哨兵挂了，主从库还能切换吗
当数据量大生成RDB成本高，fork 阻塞主线程，成本逐渐增高
纵向扩展
搭建多个实例 Redis 切片集群
横向扩展
Redis Cluster集群方案，采用哈希槽来处理数据和实例之间的映射关系，有16384个槽，key 按照 CRC16 算法计算一个 16 bit 的值；然后再用这个 16bit 值对16384 取模，得到 0~16383 范围内的模数，每个模数代表一个相应编号的哈希槽。N 个实例，每个实例上的槽个数为 16384/N 个
数据切片后，在多个实例之间如何分布
Redis 会自动把 Hash Slot 平均分布在集群实例
cluster create 创建集群
必须全分完集群才能工作
cluster meet 命令手动建立实例间的连接，cluster addslots 指定实例的哈希槽数量
创建集群的两种方式
在集群中，实例有新增或删除，Redis 需要重新分配哈希槽
为了负载均衡，Redis 需要把哈希槽在所有实例上重新分布一遍
这些变化对客户端是无感的，Redis Cluster 提供了重定向功能，当客户端发请求给一个实例，实例上没有这个键值对应的哈希槽，实力会给客户端返回 MOVED 命令响应。客户端就会再次向相应实例发送请求，同时更新本地缓存
客户端会收到ASK，返回键值所在实例，客户端向对应实例发送ASKING，让这个实例允许执行客户端接下来发送的命令。然后，客户端再向这个实例发送命令。 ASK 并不会更新客户端的本地缓存。下次还是会发请求给原来的实例，直到迁移完成，请求返回 MOVED
槽的数据未迁移完毕，但请求的 key 已经被迁移过去
实例和哈希槽的对应关系发生变化
切片集群：数据增多了，是该加内存还是加实例
基础篇
key 和 value 都是 RedisObject，RedisObject 由元数据信息和 ptr 构成，各占8B，共16B
另外全局 hash 表 key value next 指针占 24B，由于 jemalloc 会分配 32B
String 为什么占内存
有三种编码 int 编码、embstr 编码、raw编码
保存 64 位有符号整数，会将它保存为8字节的Long类型整数，指针就直接赋值为整数数据
int 编码
保存字符串数据，并且字符串小于等于 44 字节时 RedisObject 中的元数据、指针和 SDS 是一块连续的内存区域
embstr 编码
> 44 字节时，Redis 就不再把 SDS 和 RedisObject 布局在一起了，而是会给 SDS 分配独立的空间，并用指针指向 SDS 结构
raw 编码
String 如何保存数据
压缩列表（ziplist），这是一种非常节省内存的结构
用什么数据结构可以节省内存
Hash 类型的键，Hash 类型值中的 key 和 value
把一个单值的数据拆分成两部分，前一部分作为 Hash 集合的 key，后一部分作为 Hash 集合的 value
hash-max-ziplist-entries：表示用压缩列表保存时哈希集合中的最大元素个数。超过转哈希表
hash-max-ziplist-value：表示用压缩列表保存时哈希集合中单个元素的最大长度。超过转哈希表
基于 Hash 类型的二级编码
如何用集合类型保存单值的键值
String 记录小数据时，元数据占用空间大
List、Hash、Set、Sorted Set
集合类型的特点就是一个键对应一系列的数据
Redis 常用的 4 个集合类型
Set 类型合适
App 每天的新增用户数
聚合统计 (并交差)
Sorted Set
插入数据可能导致数据重复展示
List
分页显示最新的评论列表
排序统计
Bitmap 用 String类型作为底层数据结构实现的一种统计二值状态的数据类型，String 类型底层是一个字节数组
Bitmap
统计一个月签到
二值状态统计
需要准确还是 Set 或 Hash 但当UV很大，页面很多时耗费内存
概率算法，标准误算率是 0.81%
网页 UV (去重)
基数统计
集合类型常见的四种统计模式
有一亿个 keys 要统计，应该用哪种集合
key（例如车 ID）对应一个 value（一组经纬度）
基于位置信息服务(LBS)
GEO 类型是把经纬度所在的区间编码作为 Sorted Set 中元素的权重分数，把和经纬度相关的车辆 ID 作为 Sorted Set 中元素本身的值保存下来
GEO 类型的底层数据结构就是用 Sorted Set 来实现的
GeoHash 的编码原理(\"二分区间，区间编码\")，(偶经 奇维 从左往右)
解决：同时查询给定经纬度所在的方格周围的 4 个或 8 个方格
有的编码值虽然在大小上接近，但实际对应的方格却距离比较远
GEO
要求写入快
单点查询、范围查询和聚合计算
查询模式多
时间序列数据的读写特点
String 不适合，因为记录小数据时，元数据占用空间大
Hash 不支持范围查询，SortSet 不能直接进行聚合计算(求平均值等)
Hash 和 Sorted Set 组合起来
底层数据结构使用了链表，它的范围查询的复杂度是 O(N)
查询只能返回最新的数据，不能像 Hash 返回任意时间点数据
RedisTimeSeries
数据类型的选择
时序数据库
如何在 Redis 中保存时间序列数据
消息保序
重复消息处理
消息可靠性保证
消息队列的消息存取需求
本身有序
消费者收到一次的处理结果和收到多次的处理结果是一致的
通过全局唯一ID 实现幂等性
相比 List 支持消费组形式的消息读取，能更快处理消息，防止消息堆积
Streams
消息队列的考验：Redis 有哪些解决方案
布隆过滤器由一个初值都为 0 的 bit 数组和 N 个哈希函数组成，可以用来快速判断某个数据是否存在
首先，使用 N 个哈希函数，分别计算这个数据的哈希值，得到 N 个哈希值
然后，我们把这 N 个哈希值对 bit 数组的长度取模，得到每个哈希值在数组中的对应位置
最后，我们把对应位置的 bit 位设置为 1，这就完成了在布隆过滤器中标记数据的操作
标记某个数据存在
使用 N 个哈希函数，分别计算这个数据的哈希值，得到 N 个哈希值，与数组长度取模，得到这个数据在 bit 数组中对应的 N 个位置
只要这 N 个 bit 值有一个不为 1，就代表带数据不存在
查询
增加 hash 函数的个数
如何降低误判概率
布隆过滤器
数据结构篇
读取缓存、读取数据库和更新缓存的操作都需要在应用程序中来完成
什么是旁路缓存
使用缓存只需要第一次需要查询数据库，可以减少读磁盘的随机 IO，当然要保证缓存一致性
高性能
高并发
为什么要用缓存
快
容量小
缓存的特征
Redis 天然就具有高性能访问 和 数据淘汰机制，正好符合缓存的这两个特征的要求
缓存的特征、为什么 Redis 适合做缓存
缓存命中
缓存缺失，进行缓存更新 (读数据库，写入Redis)
Redis缓存 处理请求的两种情况
先读取 Redis
发生缓存缺失时，需要从数据库读取数据
发生缓存缺失时，还需要更新缓存
Redis 缓存时，我们基本有三个操作
写请求直接发给数据库 ，删改数据要删除缓存 ，下次会发生缓存缺失，从数据库中读
只读缓存直接在数据库中更新数据的好处是，所有最新的数据都在数据库中，而数据库是提供数据可靠性保障的，这些数据不会有丢失的风险
适用于写请求很少，或者是只需要提升读请求的响应速度的话，我们选择只读缓存
只读缓存
读写请求都会发给 Redis
两操作的原子性，失败重试
同步直写: Redis MySQL 两者都写完了才返回，增加了缓存的响应延迟
数据一致性的要求不高
异步写回: 等待数据将要被淘汰的时候才会写回，有丢失风险
有同步直写，异步写回两种策略
对写请求进行加速，我们选择读写缓存，异步写回策略
读写缓存
缓存的类型
旁路缓存：Redis 是如何工作的
什么是数据的一致性
如果不能保证删除缓存和更新数据库操作的原子性就会出现
删除缓存值和更新数据库的过程中有大量并发请求
删改数据
什么情况下会出现缓存和数据库的数据不一致 (只读缓存)
异步重试：避免重试占用线程资源，把重试请求写到消息队列中
线程A更新主库，线程A删除缓存，线程B查询缓存缺失，从从库读取到旧值，更新缓存，主从同步完成(缓存是旧值，主从是新值)
读写分离 + 主从复制延迟，先更新数据库，再删除缓存也不一致 (通过延时消息)，核心还是应该减少主备延迟
不重试防止失败的话可以设置过期时间，过期后重新读 (短暂不一致)
先更新数据库 + 再删除缓存
订阅数据库变更日志，再操作缓存
解决缓存不一致的方法 (只读缓存)
缓存和数据库的数据一致性
为什么要缓存替换策略
CONFIG SET maxmemory 4GB
需要结合应用数据实际访问特征(长尾 重尾 效应) 和 成本来综合考虑
设置多大的缓存容量合适
allkeys-lru 使用 LRU 算法在所有数据中进行筛选
allkeys-lfu 使用 LFU 算法在所有数据中进行筛选
allkeys-random 从所有键值对中随机选择并删除数据
volatile-lru 使用 LRU 算法筛选设置了过期时间的键值对
volatile-lfu 使用 LFU 算法选择设置了过期时间的键值对
volatile-random 设置了过期时间的键值对中，进行随机删除
volatile-ttl 设置了过期时间的键值对，根据过期时间的先后进行删除，越早过期的越先被删除
3.0 及之后默认，Redis 使用的内存空间超过 maxmemory，不淘汰直接报错，不用于 Redis 缓存
redis 3.0 之前，默认是 volatile-lru
no - eviction 不删除策略
缓存替换机制
并未用链表管理缓存数据
LRU 优化
RedisObject 中的 lru 字段记录，会记录每个数据的最近一次访问的时间戳，在决定淘汰的数据时，第一次会随机选出 N 个数据，把 lru 字段值最小的数据从缓存中淘汰出去，之后淘汰数据时，只有比该集合中最小 lru 还小才会进入集合，达到 N个 后淘汰 lru 最小的数据
CONFIG SET maxmemory-samples 100 设置候选集的个数
Redis LRU 的实现
LRU 只看数据的访问时间，在处理扫描式单次查询操作时，无法解决缓存污染
LRU 策略存在的问题
CONFIG SET maxmemory xxx
保证 Redis 只存 20w 的数据
allkeys-lru 淘汰策略
保留热点数据
MySQL 里有 2000 w 数据，Redis 中只存 20w 的数据，如何保证 Redis 中的数据都是热点数据
allkeys - lru 策略
业务数据中有明显的冷热数据区分
volatile - lru 策略，置顶的数据不设置过期时间
业务中有置顶的需求
allkeys-random
没有明显的冷热数据区分
如何选择淘汰策略
替换策略：缓存满了怎么办
大量的应用请求无法在 Redis 缓存中进行处理，紧接着，应用将大量请求发送到数据库层，导致数据库层的压力激增
EXPIRE 时加一个较小的随机数
服务降级 来应对缓存雪崩 非核心业务 直接返回预定义信息核心业务仍允许先查询缓存再查数据库
某一个时刻，大量数据同时过期
搭建高可用集群
服务熔断，直到其恢复
请求限流
Redis 实例宕机
什么情况下会发生雪崩
缓存雪崩
热点数据过期失效，对热数据的请求，无法在缓存中进行处理，紧接着，访问该数据的大量请求，一下子都发送到了后端数据库
访问特别频繁的热点数据不设置过期时间
缓存击穿
缓存穿透 是 指要访问的数据既不在 Redis 缓存中，也不在数据库中
业务层误操作，数据被删除
恶意攻击
针对查询的数据，缓存并返回一个默认值
布隆过滤器快速判断数据是否存在
前端进行请求检测，过略掉恶意的请求
应对
缓存穿透
缓存雪崩、缓存击穿、缓存穿透
数据被访问后不会再被访问却一直留存在缓存中，占用缓存空间
什么是缓存污染
在明确知道数据被访问的时长时使用 volatile-ttl，并设置过期时间，可以有效避免缓存污染
4.0 引入的 LFU
如何避免缓存污染
LFU 策略筛选淘汰数据时，首先会根据数据的访问次数进行筛选，把访问次数最低的数据淘汰出缓存。如果两个数据的访问次数相同，LFU 策略再比较这两个数据的访问时效性，把距离上一次访问时间更久的数据淘汰出缓存
LFU 是怎么淘汰数据的
LFU 是 在 LRU 上的改进，把 lru 字段 24bit 前 16bit 表示数据时间戳，后 8bit 表示访问次数 但是只能记录 8bit 访问 255 次，所以并未采取访问 1 加 1 ，采用了非线性递增的计数器方法，避免短时间大量访问，后不访问使用衰减因子
LFU 实现原理
LRU 策略更加关注数据的时效性；而 LFU 策略更加关注数据的访问频次
LRU 与 LFU 对比
缓存污染
缓存篇
对多个客户端访问操作同一份数据的过程进行控制，保证操作具有互斥性
并发访问中需要对什么进行控制
加锁 和 原子操作
Redis 提供了什么方法保证并发访问的正确性
锁是保存在一个共享存储系统中的，可以被多个客户端共享访问和获取
什么是分布式锁
保证共享存储系统的可靠性
加锁和释放锁的过程的原子性
分布式锁有什么要求 (两个)
Redis 本身就是共享存储系统 (基于多个节点，高可靠)，支持原子操作，Redis 的读写性能高可以应对高并发的锁操作场景
Redis 为什么可以 Redis 实现分布式锁
唯一标识 防止误释放锁
超时时间，防止客户端异常，一直持有锁
加锁 SET + 唯一标识 + 过期时间 + NX 解锁 LUA (需要判断标识)
实例发生故障宕机了，锁变量没有了，也就无法进行锁操作了
单个 Redis 节点实现分布式锁的缺点
基于单个 Redis 节点实现分布式锁
客户端和多个独立的 Redis 实例依次请求加锁 (和单实例加锁操作一样)，如果客户端能够和半数以上的实例成功地完成加锁操作，那么我们就认为，客户端成功地获得分布式锁了，否则加锁失败
RedLock 算法
客户端获取当前时间
客户端按顺序依次向 N 个 Redis 实例执行加锁操作
一旦客户端完成了和所有 Redis 实例的加锁操作，客户端就要计算整个加锁过程的总耗时
客户端获取锁的总耗时没有超过锁的有效时间
大于等于 N/2+1 个实例加锁成功
加锁成功必须满足的条件
条件不满足
锁剩余的有效时间来不及完成共享数据的操作
什么时候释放锁
RedLock 算法加锁三个过程
基于多个 Redis 节点实现高可靠的分布式锁
Redis 如何实现分布式锁
INCR / DECR
把多个操作在 Redis 中实现成一个操作 —— 单命令操作
EVAL 命令来执行脚本
把多个操作写到一个 Lua 脚本中，以原子性方式执行单个 Lua 脚本
Lua 脚本
Redis 如何实现原子操作
无锁的原子操作：Redis 如何应对并发访问
MULTI 开启一个事务，命令入队，EXEC 执行队列中的命令
Redis 如何实现事务
DISCARD 主动放弃事务，清空任务队列
如何放弃一个事务
命令入队时就报错，会放弃事务执行，保证原子性
命令和操作的数据类型不匹配
命令入队时没报错，实际执行时报错，不保证原子性
使用 redis-check-aof 工具，把未完成的事务操作从 AOF 文件中去除，使用 AOF 恢复实例后能保证原子性
EXEC 命令执行时实例故障，如果开启了 AOF 日志，可以保证原子性
原子性
命令入队时就报错，事务本身就会被放弃执行
命令入队时没报错，实际执行时报错，正确的命令可以正常执行
没有开启 RDB 或 AOF，数据就没有了，能保障
RDB 快照不会在事务执行时执行
开启 AOF 可以利用 redis-check-aof 清除事务中已经完成的操作，也能保障
EXEC 命令执行时
都可以保证
一致性
MULTI 命令前有 WATCH命令，就能保证隔离性
隔离性
无论采用什么持久化模式，事务的持久性属性是得不到保证的，内存数据库，持久性不是重点
持久性
Redis 的事务机制能保证哪些属性
事务机制：Redis 能实现 ACID 属性吗
主从库间的网络延迟
从库正在执行高复杂度的命令，之后才会执行传播过来的命令
什么原因会导致主从数据不一致
从库 和 主库间的复制进度差值大于预期就不在该从库上读
slave-serve-stale-data no (从库只能执行 INFO、SLAVEOF)
读到旧数据
不能保证过期数据全被被删除，还是会有留存
定期删除策略
惰性删除
与 Redis 过期键删除策略有关
给数据设置的过期时间在从库上被延后
为什么会导致读到过期数据
使用 3.2 以上，数据过期从库返回 null
使用 EXPIREAT / PEXPIREAT 将过期时间设置为具体的过期时间点，并且主从库同步时钟
读到过期数据
protected-mode yes 哨兵实例只能在部署的服务器本地进行访问，与其它服务器上的哨兵无法通信，主库故障，无法判断主库下线，无法进行主从切换，最终 Redis 服务不可用
protected-mode no + bind
protected - mode
Cluster 集群每个实例都是一主一从，当半数以上实例主从切换(可能)导致半数以上实例心跳超时 (cluster-node-timeout) ，集群挂掉
cluster- node-timeout 过小
cluster-node-timeout 定义了集群实例被判断为故障的心跳超时时间
不合理配置项导致的服务挂掉
Redis 主从同步 与 故障切换，可能存在的问题
采用哨兵机制进行主从切换，如果原主库只是 \"假故障\" ，它会触发哨兵启动主从切换，一旦等它从假故障中恢复后，又开始处理请求，这样一来，就会和新主库同时存在，形成脑裂
什么是脑裂
主库的数据还没有同步到从库，结果主库发生了故障，等从库升级为主库后，未同步的数据就丢失了；比对原主库 master_repl_offset 和 原从库 slave_repl_offset 的差值看是否是这个原因
等到哨兵让原主库执行 (slave of) 和 新主库做全量同步后，原主库会清空本地的数据，加载新主库发送的 RDB 文件，原主库在主从切换期间保存的新写数据就丢失了
脑裂
什么情况下可能数据丢失
主库自身遇到了阻塞的情况，如处理 bigkey 或是发生内存 swap 短时间内无法响应心跳
脑裂发生的原因
通过配置让其在假故障期间不能接收请求，只能有新主库接受请求，等切换完成后，原主库会被哨兵降为从库，就不会出现脑裂进而出现数据丢失了
min-slaves-to-write 设置了主库能进行数据同步的最少从库数量
min-slaves-max-lag 主从库间进行数据复制时，从库给主库发送 ACK 消息的最大延迟
原主库是假故障，它在假故障期间也无法响应哨兵心跳，也不能和从库进行同步，自然也就无法和从库进行 ACK 确认了
如何解决脑裂
脑裂：一次奇怪的数据丢失
读多写少
瞬时并发访问量非常高
秒杀场景的负载特征
高速处理请求的特性支持高并发，并且可以使用分片集群存储商品，避免请求到一个实例
LUA 脚本保证原子性
使用分布式锁
保证库存查验和库存扣减原子性执行
Redis 如何支撑秒杀场景
CDN缓存静态化元素
第一阶段是秒杀活动前
库存查验
库存扣减
要保证处理的事务性(会涉及支付、商品出库、物流等，涉及多张表)
订单处理
第二阶段是秒杀活动开始
服务器端一般都能支撑
秒杀活动结束后
秒杀的各个阶段
数据库处理较慢，大量请求读取到旧值，出现超售
库存查验 和 库存扣减这两个操作需要保证原子性
查验库存 和 库存扣减为什么必须放在 Redis 处理
Redis 支撑秒杀
实例上的数据分布不均衡，某个实例上的数据特别多
什么是数据倾斜
bigkey 是集合类型则把 bigkey 拆分成很多个小的集合类型数据，分散保存在不同的实例上
避免 bigKey
bigKey
使用迁移命令迁移到其他实例
Slot 手工分配不均
数据分布倾斜
每一个数据副本的 key 中增加一个随机前缀，让他们被映射到不同的 Slot 中，并将Slot分配到不同的实例，这样不同的实例就都能提供访问
热点只读数据多副本
要保证多副本间的数据一致性，会带来额外的开销
为什么读写数据不能使用多副本
数据访问倾斜
如何避免数据倾斜
数据分布优化：如何应对数据倾斜
Gossip 协议
如何让集群中的每个实例都知道其它所有实例的状态信息
节点彼此不断通信交换信息 (PING PONG)，一段时间后所有的节点都会知道集群完整的信息，类似流言传播
实例自身 + 1 / 10 集群
PING / PONG
Gossip 协议工作原理
每秒会随机选取5个节点，找出最久没有通信的节点发送 PING 消息
每隔 100 毫秒 都会扫描本地节点列表，如果发现节点最近一次接受 PONG 消息的时间大于 cluster-node-timeout/2 ，则立刻发送 PING 消息
每秒发送 PING 消息数量 ～= 1 + 10 * 实例数
具体发送规则
通信消息大小不能改变，因为要维持集群状态的统一
调整 cluster-node-timeout 时间 缓解PONG消息接收超时的情况，但也要避免设置过大
过大，发生故障，就需要等待更长时间才能检测出，从而导致了故障恢复时间被延长，影响集群服务的使用
降低实例间发送消息的频率
最核心就是 合理设置集群数目，避免因为集群过大，集群之间通信开销大于处理请求的开销
如何降低实例间的通信开销
Redis 的作者测试发现这个数对 2^14 求模的会将 key 在 0-2^14-1 之间分布得很均匀
如果槽位为 65536，这个 PING/PONG 消息太大
为什么 Redis Cluster 是16384 个槽位 2^14
通信开销：限制Redis Cluster规模的关键因素
随着网络硬件的性能提升，Redis 的性能瓶颈有时会出现在网络 IO 的处理上，也就是说，单个主线程处理网络请求的速度跟不上底层网络硬件的速度
为什么引入多线程
采用多个 IO 线程来处理网络请求，主线程会创建和客户端的连接，通过轮询方法把 Socket 连接分配给 IO 线程，同时仍然使用单线程执行命令操作
例如：多个请求进来了，轮询分发给多个线程包括主线程，多线程并行读取，解析，主线程按照请求的顺序依次执行命令
网络 IO 方面
支持创建不同用户来使用 Redis
支持以用户为粒度设置命令操作的访问权限
6.0 之前通过客户端连接实例前输入密码
细粒度的权限控制，更好的安全性
客户端就可以把读取的数据缓存在业务应用本地
key 的值发生变化，服务端会给客户端发送 invalidate 消息，通知客户端缓存失效
普通模式
广播模式
数据被修改如何做失效处理
服务端协助的客户端缓存功能
直接通过不同的开头字符，区分不同的数据类型，来实现数据转换
RESP 3
Redis 6.0
集合全量查询 (HGETALL，SMEMBERS) 和 聚合统计操作 (交、并和差集)
删除 bigkey 在应用程序释放内存时，空闲内存块链表操作时间就会增加
清空数据库 涉及到删除 和 释放所有的键值对
和客户端交互时的阻塞点
AOF 日志同步写回，写磁盘，会阻塞
和磁盘交互时的阻塞点
接收 RDB 快照要 FLUSHDB
加载 RDB 文件会阻塞
主从节点交互时的阻塞点
负载均衡或者有实例增删时，数据会在不同的实例间进行迁移(渐进式)，哈希槽的信息量不大影响不大，如果有 bigkey 就会造成主线程的阻塞
切片集群实例交互时的阻塞点
使用 Redis 的异步子线程机制，然后把一些(非关键路径上的任务)任务交给这些子线程，让它们在后台完成
Redis 主线程启动后，会使用操作系统提供的 pthread_create 函数创建 3 个子线程，主线程会通过一个任务队列和三个子线程进行交互。主线程会把操作封装成一个任务，放入到任务队列中，然后返回给客户端已执行完成，子线程会从任务队列中取出任务，根据任务的具体类型，来执行相应的异步操作
异步的子线程机制
读
从库加载 RDB 文件
什么是关键路径
bigkey 删除、清空数据库、AOF 日志同步写 (everysec)
只有非关键路径操作才可用子线程完成
键值对删除 当集合类型中有大量元素 UNLINK 命令
清空数据库 FLUSHDB ASYNC
4.0 之后 提供了惰性(异步) 删除
应对阻塞
集合全量查询 和 聚合统计操作：可以使用 SCAN 命令，分批读取数据，再在客户端进行聚合计算
从库加载 RDB 文件：把主库的数据量大小控制在 2~4 GB 左右，以保证 RDB 文件能以较快的速度加载
不能用子线程如何应对阻塞
异步机制：如何避免单线程模型的阻塞
绑核可以降低尾延迟
请求的处理延迟从小到大排个序，99% 的请求延迟小于的值就是 99% 尾延迟
什么是尾延迟
Redis 如果在不同的核上运行，就需要频繁地进行上下文切换，会增加 Redis 的执行时间
把实例和某个核绑定
CPU 多核对 Redis 性能的影响
CPU Socket(插口) 就是 CPU处理器
在多 CPU 架构下，一个应用程序访问所在 Socket 的本地内存和访问远端内存的延迟不一致
非统一内存访问架构
为了避免 Redis 跨 CPU Socket 访问网络数据，我们最好把网络中断程序和 Redis 实例绑在同一个 CPU Socket
CPU 的 NUMA 架构对 Redis 性能的影响
物理核通常都会运行两个超线程，也叫作逻辑核
如果 Redis 实例绑定的是逻辑核，子进程和后台线程会导致主线程阻塞
应该绑定物理核，而不是逻辑核，以缓解 CPU 资源竞争
绑核带来的问题
CPU 核和 NUMA 架构的影响
系统在低压力、无干扰下的基本性能，这个性能只由当前的软硬件配置决定
redis - cli -- intrinsic(基本) - latency(延迟时间) 120 (监控多少秒内)
响应延迟是基线性能两倍以上，就认为 Redis变慢了
基于基线性能判断
要测网络对Redis性能影响可以用 iPerf 工具
避免网络影响，应该运行在服务端
判断 Redis 是否变慢
通过 Redis 日志，或者是 latency monitor 工具，查询变慢的请求
用其他高效命令代替 聚合计算读取到客户端，再自己处理
如何应对
慢查询命令
如果超过 25% 的 key 过期了，则重复删除的过程，直到过期 key 的比例降至 25% 以下
可以在过期函数上加一个随机数
同一秒内有大量的 key 同时过期 会触发重复删除
过期 key 操作
1. Redis 自身操作特性的影响
潜在的风险点
everysec Redis 会使用后台的子线程异步完成 fsync 的操作
always 策略使用的主线程
当主线程使用后台子线程执行了一次 fsync，需要再次把新接收的操作记录写回磁盘时，主线程发现上一次的 fsync 还没有执行完，那么它就会阻塞
换机械硬盘
解决方法
AOF 重写占用了大量的磁盘 IO 带宽，可能会阻塞后台线程执行 fsync
2. 文件系统对 Redis 性能的影响
增加机器的内存或者使用 Redis 集群(分摊每个实例服务的数据量，进而减少每个实例所需的内存量)
选用内存大的做主库
操作系统 SWAP
Redis 做持久化保存过程中，主线程仍然能够接收命令，Redis 会采用写时复制，会导致拷贝大量的页，导致性能变慢
关闭内存大页
操作系统 内存大页
3. 操作系统对 Redis 性能的影响
影响 Redis 性能的三大要素
波动的响应延迟：如何应对变慢的 Redis
数据删除后，Redis 释放的内存空间会由内存分配器管理，并不会立即返回给操作系统，所以，操作系统仍然会记录着给 Redis 分配了大量内存
潜在的风险点：释放的内存空间可能不是连续的成为难以利用的内存碎片，还会降低 Redis 运行机器的成本回报率
外因：键值对大小不一样 和 键值对修改删除 导致空间的扩容和释放
内因：按照jemalloc(默认) 2^n 次幂 固定分配，可能用不完
内存碎片是如何形成
INFO memory 中 mem_fragmentation_ratio=操作系统分配的内存空间/Redis使用的空间
mem_fragmentation_ratio 1-1.5正常
判断是否有内存碎片
重启
config set activedefrag yes 启用自动内存碎片清理
碎片达到100mb
active-defrag-ignore-bytes 100mb
占总内存10%
active-defrag-threshold-lower 10
开始清理的条件
占用 CPU 百分比最少是多少
active-defrag-cycle-min
active-defrag-cycle-max
占CPU时间
通过合理的配置参数，减小对 Redis 性能的影响
Redis 4.0 提供了碎片清理机制 将不连续的空间清理为连续的(阻塞)
解决内存碎片的方法
删除数据后，为什么内存占用率还是很高
写入了 bigkey，比如一下子写入了多个百万级别的集合类型数据
服务器端处理请求的速度过慢，导致客户端输入缓冲区堆积
CLIENT LIST
通常存在多个客户端
避免bigKey
避免Redis主线程阻塞
应对溢出方法
输入缓冲区溢出
1.暂存客户端发送的命令数据的客户端输入缓冲区
输出缓冲区 16KB 固定缓冲空间(OK+出错信息) + 动态增加的缓冲空间(存可变的响应结果)
返回bigkey
MONITOR 命令输出结果会持续输出监测到的各个命令操作占用输出缓冲区
缓冲区大小设置得不合理
发生输出缓冲区溢出
避免 bigkey 操作返回大量数据结果
避免在线上环境中持续使用 MONITOR 命令
常规和 Redis 服务器端进行读写命令交互的普通客户端
超过多大直接关闭；持续超过某大小，直接关闭
订阅了 Redis 频道的订阅客户端
主节点上的从节点客户端
客户端类型
根据不同客户端类型设置缓冲区大小
应对输出缓冲区溢出
输出缓冲区溢出
2.暂存服务器端返回给客户端的数据结果的客户端输出缓冲区
溢出导致主节点会直接关闭和从节点进行复制操作的连接，导致全量复制失败
client-output-buffer-limit 配置项，来设置合理的复制缓冲区大小
控制主节点保存数据量的大小，2-4 GB，让全同步执行的快，避免复制缓冲区积累过多的命令
控制从节点的数量，来避免主节点中复制缓冲区占用过多内存
如何避免复制缓冲区溢出
复制缓冲区 (全增量复制)
是一个环形缓冲区，溢出就相当于覆盖旧命令数据，一旦覆盖就要主从节点全增量复制
缓冲空间大小 = (主库写入命令速度 * 操作大小 - 主从库间网络传输命令速度 * 操作大小) x 2
repl_backlog_size
复制积压缓冲区 (增量复制)
3.主从节点间进行数据同步期间，用来暂存主节点接收的写命令和数据
缓冲区在Redis中的应用场景
缓冲区：一个可能引发 \"惨案\" 的地方
性能篇
Redis 是 C 语言开发的内存数据库，由于是内存数据库，所以读写速度非常快，常用来做缓存，除了做缓存还可以实现分布式锁，和 轻量级的消息队列，它提供了多种数据结构来应对不同的场景，还支持 持久化 、集群 与 事务
什么是 Redis
缓存 (票证 ticket)
计数器 incr
分布式锁 setnx
String
链表、队列、微博关注人 时间轴列表等
Hash 表
Hash
去重、赞、踩，共同好友 (交集)
Set
评论列表 (按权重)
数据类型及其应用场景
缓存 ticket 解决分布式 Session
缓存
使用 SETNX 和 DEL 命令组合来实现加锁和释放锁
分布式锁
如何控制一段时间用户的访问次数
限流 (String incr+ LUA)
基数统计 Hyp
保存时间序列数据
通过 incr 命令
计数器
基于位置信息服务 (LBS)
GEO
排行榜，Redis 的有序集合
Redis 场景
Memcached，Redis
都采用哈希表作为 key - value 索引
都是基于内存的数据库，一般都用来当做缓存使用
都有过期策略
相同
Memcached 支持的 value 类型仅为 String 类型
Redis 提供了持久化功能
Redis 支持事务
Memcached 是多线程，Redis 6.0 也是
不同点
说一下 Redis 和 Memcached 的区别和共同点
分布式缓存常见的技术选型方案有哪些
补充
Redis
0 条评论
回复 删除
下一页
