网站开发的关键,电商设计有前景吗,山东网站建设企业,网上商城有哪些平台文章目录一 Redis 概述Redis 为什么是单线程#xff0c;单线程为什么这么快#xff1f;数据存储结构二 常用数据类型1 String2 HashHash 的扩容机制#xff1a;渐进式 rehash*3 List4 Set5 Zset三 Redis 事务1 乐观锁与 watch 命令2 事务的三个特性四 Redis 持久化1 RDB(Red…
文章目录一 Redis 概述Redis 为什么是单线程单线程为什么这么快数据存储结构二 常用数据类型1 String2 HashHash 的扩容机制渐进式 rehash*3 List4 Set5 Zset三 Redis 事务1 乐观锁与 watch 命令2 事务的三个特性四 Redis 持久化1 RDB(Redis Database)与写时复制2 AOF(Append Only File)五 Redis 高可用主从复制1 分布式与集群2 Redis 复制原理2 哨兵模式 Redis Sentinel3 Redis Cluster六 典型问题及解决1 缓存穿透2 缓存击穿3 缓存雪崩4 解决缓存穿透布隆过滤器5 如何保证 Redis 缓存与数据库的一致性七 数据过期与内存淘汰1 数据过期策略惰性删除 定期删除2 内存淘汰策略一 Redis 概述
属于一种 NoSQL非关系型数据库另一种常用的非关系型数据库是 MongoDBRedis 的数据都在内存中并且支持持久化主要用作备份恢复除了支持简单的 key-value 模式还支持多种数据结构的存储 string、list、set、hash、zset 等这些数据类型都支持 push / pop、add / remove 及取交集并集和差集等操作而且这些操作都是原子性的但 Redis 事务不具有原子性一般是作为缓存数据库辅助持久化的数据库Redis 不支持自定义数据库的名字每个数据库都以编号命名开发者必须自己记录哪些数据库存储了哪些数据Redis 也不支持为每个数据库设置不同的访问密码所以一个客户端要么可以访问全部数据库要么连一个数据库也没有权限访问多个数据库之间并不是完全隔离的这些数据库更像是一种命名空间而不适宜存储不同应用程序的数据比如可以使用0号数据库存储某个应用生产环境中的数据使用1号数据库存储测试环境中的数据但不适宜使用0号数据库存储A应用的数据而使用1号数据库B应用的数据不同的应用应该使用不同的Redis实例存储数据
Redis 为什么是单线程单线程为什么这么快
因为 Redis 是基于内存的操作CPU 不是 Redis 的瓶颈Redis 的瓶颈最有可能是内存大小或者网络带宽。既然单线程容易实现而且 CPU 不会成为瓶颈那就顺理成章地采用单线程的方案了在单线程的情况下处理逻辑更简单不用去考虑各种锁的问题不存在加锁释放锁操作没有因为可能出现死锁而导致的性能消耗不存在多进程或者多线程导致的切换而消耗 CPURedis 采用网络 I/O 多路复用技术来保证在多连接的时候系统的高吞吐量
数据存储结构 Redis 的 Db 默认情况下有16个每个 redisDb 内部包含一个 dict 的数据结构dict 内部包含 ht 的数组数组个数为2元素类型为 dictht主要用于 hash 扩容使用参考下面的 Hash 扩容dictht 内部包含 dictEntry 的数组可以理解就是 hash 桶然后使用拉链法解决冲突dictEntry 当中的 key 和 v 的指针指向的是 redisObjectredisObject 是 Redis server 存储最原子数据的数据结构其中的void *ptr 会指向真正的存储数据结构 typedef struct redisDb {//数据字典保存着数据库中的所有键值对dict *dict; //过期字典字典的值为键的过期时间是一个UNIX时间戳dict *expires; //正处于阻塞状态的键dict *blocking_keys;//可以解除阻塞的键dict *ready_keys;//正在被 WATCH 命令监视的键dict *watched_keys;//失效池根据对象lru时间戳保存要被淘汰的对象struct evictionPoolEntry *eviction_pool;int id;//数据库的键的平均 TTL 统计信息long long avg_ttl;
} redisDb;typedef struct dict {//类型特定函数dictType *type;//私有数据void *privdata;//哈希表dictht ht[2];//rehash 索引当rehash不在进行时值为 -1int rehashidx;//目前正在运行的安全迭代器的数量int iterators;
} dict;typedef struct dictht {//哈希表数组dictEntry **table;//哈希表大小unsigned long size;//哈希表大小掩码用于计算索引值总是等于 size - 1unsigned long sizemask;// 该哈希表已有节点的数量unsigned long used;
} dictht;typedef struct dictEntry{//键void *key;//值union {void *val;uint64_t u64;int64_t s64;} v;//指向下个哈希表节点的指针拉链法解决哈希冲突struct dictEntry *next;
} dictEntry;typedef struct redisObject {// 类型unsigned type:4;// 编码unsigned encoding:4;// 对象最后一次被访问的时间unsigned lru:REDIS_LRU_BITS; /* lru time (relative to server.lruclock) */// 引用计数int refcount;// 指向实际值的指针void *ptr;
} robj;二 常用数据类型
1 String
参考链接
具有二进制安全binary safe特性这意味着它的长度是已知的不由任何其他终止字符决定的一个字符串类型的值最多能够存储 512 MB 的内容。所有 SDS API 都会以处理二进制的方式来处理 SDS 存放在 buf 数组里的数据程序不会对其中的数据做任何限制、过滤、或者假设保证数据在写入时是什么样的 它被读取时就是什么样这也是 SDS 的 buf 属性称为字节数组的原因Redis 不是用这个数组来保存字符 而是用它来保存一系列二进制数据Redis 实现了SDSSimple Dynamic String简单动态字符串的抽象类型它通过存储额外数据能简单地得到自身信息总长度、可用长度等SDS 遵循 C 字符串以空字符结尾的惯例 保存空字符的 1 字节空间不计算在 SDS 的 len 属性里面 并且为空字符分配额外的 1 字节空间遵循空字符结尾这一惯例的好处是 SDS 可以直接重用一部分 C 字符串函数库里面的函数SDS 还被用作缓冲区比如 AOF 模块中的 AOF 缓冲区
struct sdshdr {// 记录 buf 数组中已使用字节的数量// 等于 SDS 所保存字符串的长度int len;// 记录 buf 数组中未使用字节的数量int free;// 字节数组用于保存字符串char buf[];};2 Hash
底层存储使用 ziplist 或 hashtable再底层是字典 当一个哈希对象可以满足以下两个条件时哈希对象会选择使用ziplist编码来进行存储 1 哈希对象中的所有键值对总长度(包括键和值)小于64字节这个阈值可以通过参数hash-max-ziplist-value 来进行控制 2 哈希对象中的键值对数量小于512个这个阈值可以通过参数hash-max-ziplist-entries 来进行控制 一旦不满足这两个条件中的任意一个哈希对象就会选择使用hashtable来存储 使用拉链法解决哈希冲突可以理解成一个包含了多个键值对的集合一般用于存储对象
Hash 的扩容机制渐进式 rehash*
将 rehash 的操作分摊在每一个的访问中避免集中式 rehash 可能会导致服务器在一段时间内停止服务 参考链接 Hash 底层有两个数组 ht[0] 和 ht[1] 还有一个 rehashidx 用来控制 rehash 过程 初始默认长度为4当元素个数与 Hash 表长度一致时负载因子为1发生扩容长度变为原来的二倍同时 rehashindex 的值设置为0表示 rehash 工作正式开始 在 rehash 期间每次对字典执行增删改查时还会顺带将 ht[0] 哈希表在rehashindex 索引上的所有键值对 rehash 到 ht[1] 当 rehash 工作完成以后rehashindex 的值 1 随着字典操作的不断执行最终会在某一时间段上 ht[0] 的所有键值对都会被 rehash 到 ht[1]这时将 rehashindex 的值设置为 -1表示 rehash 操作结束 在渐进式 rehash 的过程中如果有增删改查操作index 大于 rehashindex访问 ht[0] 否则访问 ht[1]
3 List
单键多值内容按照插入的顺序排序lpush 和 rpush 的顺序不同可以向头部或尾部添加数据底层是快速链表 QuickList每个部分是压缩链表 ZipList内部是一段连续的内存所以只需要额外存储 ZipList 之间的指针
4 Set
单键多值集合中的元素无序不重复底层实现为 intset 或 hashtableintset 实现为数组这个数组以有序、无重复的方式保存集合元素在有需要时程序会根据新添加元素的类型改变这个数组的类型
5 Zset
ZSet 基于跳表实现是一种有序的数据结构支持平均 O(logn) 的查询效率每个元素都关联了一个 score被用来按照从最低分到最高分的方式排序集合中的成员集合里的成员是唯一的但是 score 可以重复底层实现为 ziplist 或 跳表 跳表的作用是根据 score 给元素排序方便获取指定 score 范围的元素列表 每次创建一个新跳表节点的时候程序都根据幂次定律power law越大的数出现的概率越小随机生成一个1和32之间的值作为新节点所在的层的高度 跳表的插入/删除首先需要执行查找平均时间复杂度 O(logn)跳表详解 三 Redis 事务
Redis 事务是一个单独的隔离操作事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中不会被其他客户端发送来的命令请求所打断。主要作用就是串联多个命令防止别的命令插队。事务操作通过命令 multi - discard / exec 执行 multi 过程中某个命令出现错误执行时整个的所有命令都会被取消 exec 阶段某个命令出现错误则只有报错的命令不会被执行
1 乐观锁与 watch 命令
在读数据时不认为该数据会被更新不会上锁在更新的时候会判断在此期间该数据是否被更新如果被更新则不能执行需要获取最新的版本。可以使用版本号等机制乐观锁适用于多读的应用类型可以提高吞吐量如果在事务执行之前被 watch 的 key 被其他命令改动那么事务将被打断
2 事务的三个特性
单独的隔离操作事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中不会被其他客户端发送来的命令请求所打断没有隔离级别的概念队列中的命令没有提交之前都不会实际被执行不保证原子性事务中除了执行失败的命令其它的命令仍然会被执行 四 Redis 持久化
1 RDB(Redis Database)与写时复制
在指定的时间间隔内将内存中的数据集快照写入磁盘恢复时将快照文件直接读到内存里RDB 持久化的流程主进程不进行任何IO操作而是创建子进程子进程将快照先写入临时文件再用这个临时文件替换上次持久化好的文件优点 适合大规模的数据恢复 节省磁盘空间恢复速度快 对数据完整性和一致性要求不高时更适合使用缺点 如果 Redis 意外停止会丢失最后一次快照后的数据 Redis持久化时可以进行写操作吗 BGSAVE 命令的保存工作是由子进程执行的所以在子进程下创建RDB文件的过程中Redis 服务器仍然可以继续处理客户端的命令请求子进程是通过 fork 系统调用创建的刚创建时由于 CopyOnWrite 机制会与父进程共享同一块地址空间此时如果父进程收到写请求CopyOnWrite 机制就会创建新页面存放修改的数据不影响持久化的 RDB 写时复制通俗来说是多个调用者同时去请求一个资源数据的时候有一个调用者需要对当前的数据源进行修改这个时候系统将会复制一个当前数据源的副本给调用者修改写时复制的优势是在并发的场景下进行读操作不需要加锁
2 AOF(Append Only File)
AOF 的策略是增量保存以日志的形式来记录每个写操作不记录读操作对于 AOF 文件只允许追加但不可以改写AOF 的持久化流程 客户端的请求写命令会被追加到 AOF 缓冲区内 AOF 缓冲区根据 AOF 同步频率的设置 always / everysec / no 将操作同步到磁盘的 AOF 文件中 AOF 文件大小超过重写策略或手动重写时对 AOF 文件 Rewrite 压缩 AOF 文件容量 Redis 服务重启时会重新加载 AOF 文件中的写操作达到数据恢复的目的AOF 同步频率
always始终同步每次 Redis 的写入都会立刻记入日志everysec每秒同步每秒记入日志一次no不主动进行同步把同步时机交给操作系统
RewriteAOF 文件的大小超过所设定的阈值时Redis 就会启动 AOF 文件的内容压缩 只保留可以恢复数据的 最小指令集。重写也是 fork 子进程完成的类似 RDBAOF 优点 丢失数据概率更低AOF 缺点 比起 RDB 占用更多的磁盘空间恢复备份速度更慢 五 Redis 高可用主从复制
参考链接
1 分布式与集群 分布式解决高并发问题将一个业务分拆多个子业务部署在不同的服务器上。通过将业务拆细为不同的子业务配置不同性能的服务器提高整个系统的性能 集群解决高可用问题同一个业务部署在多个服务器上。分散每台服务器的压力任意一台或者几台服务器宕机也不会影响整个系统 Redis 主从复制是一种 集群 的具体应用可以实现读写分离Master 以写为主Slave 以读为主、容灾恢复高可用
2 Redis 复制原理
Slave 启动成功连接到 Master 后会发送一个 sync 命令Master 接收到命令后执行持久化并将持久化的文件发送给 Slave全量复制Slave 接收到持久化文件存盘并加载到内存后续 Master 继续将新的所有收集到的修改命令依次传给 Slave增量复制 2 哨兵模式 Redis Sentinel
Redis 官方推荐的高可用解决方案哨兵实现的功能 监控Sentinel 会不断地检查主服务器和从服务器是否运作正常提醒当被监控的某个 Redis 服务器出现问题时Sentinel 可以通过 API 发送通知自动故障迁移当一个主服务器不能正常工作时Sentinel 会开始自动故障迁移操作根据一定的策略将失效主服务器的其中一个从服务器升级为新的主服务器并让失效主服务器的其他从服务器改为复制新的主服务器 当客户端试图连接失效的主服务器时 集群也会向客户端返回新主服务器的地址使得集群可以使用新主服务器代替失效服务器 3 Redis Cluster
Redis 3.0 版本提出的方案同样可以实现高可用Redis Cluster 是一个 去中心化 的分布式实现方案客户端和集群中 任一节点 连接然后通过节点交互得到全局的数据分片映射关系在 Redis Sentinel 模式中每个节点需要保存全量数据冗余比较多而在Redis Cluster 模式中每个分片只需要保存一部分的数据引入哈希方法根据哈希值确定数据所在的服务节点只有 master 对外提供写服务读服务可由 master/slave 提供所有节点之间通过 Redis Bus 连接并交换信息包括数据分片和节点对应关系、节点可用状态等 六 典型问题及解决
1 缓存穿透 问题 key 对应的数据在数据源并不存在每次针对此 key 的请求从 Redis 缓存获取不到请求都会传递到数据源从而可能压垮数据源解决 1、对空值缓存如果一个查询返回的数据为空不管是数据是否不存在仍然把空结果进行缓存设置过期时间相对短 2、白名单、布隆过滤器 3、实时监控当发现 Redis 的命中率开始急速降低排查访问对象和访问的数据设置黑名单限制服务
2 缓存击穿 问题 Redis 中的 某个 key 过期了但这个 key 又被超高并发地访问从后端 DB 加载数据并返回到缓存这个时候大并发的请求可能会瞬间把后端 DB 压垮解决 1、实时监控 2、预先设置热门数据在 Redis 高峰访问之前把一些热门数据提前存入到 Redis 里面加大这些热门数据 key 的时长 3、使用锁保证 DB 不会承受过高的访问压力但是了降低效率
3 缓存雪崩
问题 和缓存击穿类似区别在于缓存雪崩针对很多 key 缓存缓存击穿则是某一个 key解决 1、构建多级缓存架构nginx 缓存 redis 缓存 其他缓存ehcache 等 2、使用锁或队列降低 DB 压力但降低效率不适于高并发的情况 3、记录缓存数据是否过期可以在此设置提前量如果过期或快过期会触发通知另外的线程后台更新 key 的缓存 4、将缓存失效时间分散开
4 解决缓存穿透布隆过滤器
由 一个 二进制向量或者说位数组和 一系列 随机映射函数哈希函数两部分组成的数据结构对于一个字符串用所有的哈希函数对其进行计算将得到的一系列值作为下标并将位数组对应位置的值设置为1如果该字符串再次插入用相同的方法验证出位数组的对应位置都是1则说明重复加入理论情况下添加到集合中的元素越多误报的可能性就越大不同的字符串可能哈希出来的位置相同这种情况可以适当增加位数组大小或者调整哈希函数布隆过滤器认为某个元素存在小概率会误判。布隆过滤器认为某个元素不在那么这个元素一定不在 5 如何保证 Redis 缓存与数据库的一致性
参考链接
四种同步策略 先更新缓存再更新数据库先更新数据库再更新缓存先删除缓存再更新数据库先更新数据库再删除缓存
策略优点缺点更新缓存查询时不易出现未命中的情况频繁的更新缓存影响服务器的性能删除缓存更优操作简单无论更新操作是否复杂都是将缓存中的数据直接删除删除缓存后下一次查询缓存会出现未命中需要重新读取一次数据库先删除缓存再更新数据库 情况1线程A删除缓存成功更新数据库失败时缓存和数据库的数据是一致的但仍然是旧的数据 情况2线程A删除缓存成功更新数据库也成功但B的读操作发生在线程A两次操作之间导致 缓存中存储了旧的数据而数据库中存储了新的数据二者数据不一致 先更新数据库再删除缓存推荐 情况1线程A更新数据库成功线程A删除缓存失败后续会尝试重新删除缓存缓存和数据库的数据是一致的但是会有一些线程读到旧的数据 情况2线程A更新数据库成功线程A删除缓存也成功缓存和数据库的数据是一致的但是会有一些线程读到旧的数据但A的两步操作执行速度比较快影响并不大 七 数据过期与内存淘汰
1 数据过期策略惰性删除 定期删除
对过期的数据进行删除
定时删除每个设置过期时间的key都需要创建一个定时器到过期时间就会立即清除。这种策略对内存友好但对 CPU 不友好惰性删除在获取某个 key 的时候Redis 对该数据进行检查如果该 key 设置了过期时间则判断该过期时间是否已经过期如果过期则删除。这种策略对 CPU 是友好的但对内存不友好定期删除Redis 每隔固定时间随机抽取一些设置了过期时间的 key检查其是否过期如果过期就删除。是上述两种方法的折中
2 内存淘汰策略
当 Redis 内存数据达到一定的大小时根据配置的策略来进行数据淘汰被淘汰的数据不是过期的数据
策略行为no-enviction默认策略禁止驱逐数据仅对写操作返回错误volatile-lru从已设置过期时间的数据中选择最近最少使用的数据淘汰volatile-ttl从已设置过期时间的数据中选择将要过期的数据淘汰volatile-random从已设置过期时间的数据中任意选择数据淘汰allkeys-lru从所有数据中选择最近最少使用的数据淘汰allkeys-random从所有数据中任意选择数据淘汰
