seo网站页面优化,网站 支付宝 接口,金蓝盟企业管理咨询公司,所有做网站公司目录 Redis 什么是Redis Redis解决了什么问题 Redis的实现原理 数据结构 String 常用命令 应用场景 List(列表) 常用命令 应用场景 Hash(哈希) 常用命令 应用场景 set(集合) 常见命令​编辑 应用场景 Sorted Set(有序集合) 常见命令​编辑 应用场景 数据持…目录 Redis 什么是Redis Redis解决了什么问题 Redis的实现原理 数据结构 String 常用命令 应用场景 List(列表) 常用命令 应用场景 Hash(哈希) 常用命令 应用场景 set(集合) 常见命令​编辑 应用场景 Sorted Set(有序集合) 常见命令​编辑 应用场景 数据持久化 RDB 优缺点 AOF 工作流程 AOF持久化的策略 AOF重写 AOF校验 Redis内存管理 内存淘汰机制 Redis实现分布式锁 Redis缓存问题 缓存穿透 解决方法 缓存击穿 解决办法 缓存雪崩 解决办法 缓存预热 数据库和缓存一致性 CAP原理 解决方法 常见问题 Redis 什么是Redis Remote Dictionary Server(远程字典服务)是一个开源的使用C语言编写基于内存并且支持持久化的一个NoSQL数据库。 Redis解决了什么问题 Redis实现了 高性能高并发缓存Redis的数据是存放在内存中所以读写都是非常快速 数据结构存储Redis支持多种数据结构字符串哈希列表等 数据持久化使用AOF持久化RDB持久化方案 发布与订阅Redis支持发布与订阅模式可以实现消息的发布和订阅。 Redis的实现原理 1、高性能 将经常访问的数据都放在Redis中保证用户下一次再访问这些数据的时候就可以直接从缓存中获取了。操作缓存就是直接操作内存不用去磁盘中读取所以速度相当快。 2、高并发 一般像 MySQL 这类的数据库的 QPS 大概都在 w 左右 但是使用 Redis 缓存之后很容易达到 10w级别就单机 Redis 的情况Redis 集群的话会更高。 QPSQuery Per Second服务器每秒可以执行的查询次数 所以我们可以考虑把数据库中的部分数据转移到缓存中去这样用户的一部分请求会直接到缓存这里而不用经过数据库。进而我们也就提高了系统整体的并发。 数据结构 5 种基础数据类型String字符串、List列表、Set集合、Hash散列、Zset有序集合。 String 常用命令 应用场景 存储键值对的场景 需要计数的场景使用INCR key进行数字的增减 分布式锁 List(列表) Redis 的 List 的实现为一个 双向链表即可以支持反向查找和遍历 常用命令 应用场景 保存历史记录按照日期进行保存 Hash(哈希) Redis 中的 Hash 是一个 String 类型的 field-value键值对 的映射表特别适合用于存储对象后续操作的时候你可以直接修改这个对象中的某些字段的值。 常用命令 应用场景 可以用来对象数据的存储一个用户下面的各种信息 set(集合) 类似Java中的 HashSet集合中的元素无序但是唯一提供了查询元素是否存在的接口 常见命令 应用场景 可以做两个集合的交集例如共同好友 抽奖系统能够随机出一个名额 Sorted Set(有序集合) Sorted Set 类似于 Set但和 Set 相比Sorted Set 增加了一个权重参数 score使得集合中的元素能够按 score 进行有序排列还可以通过 score 的范围来获取元素的列表。有点像是 Java 中 HashMap 和 TreeSet 的结合体。 常见命令 应用场景 数据持久化 数据持久化指的是将数据保存到磁盘中Redis在4.0以后支持了三种持久化方式: 快照snapshottingRDB 只追加文件append-only file, AOF RDB 和 AOF 的混合持久化(Redis 4.0 新增) 数据持久化解决了重启机器或者就是机器故障以后的数据恢复工作 RDB 通过创建快照来获得存储在内存里面的数据在某个时间的副本。Redis获得了快照以后可以使用快照进行重启恢复可以复制给从服务器进行同步(提高Redis性能和高可用) 开启 通过在 redis.conf配置文件中设置 save 900 1           #在900秒(15分钟)之后如果至少有1个key发生变化Redis就会自动触发bgsave命令创建快照。 ​ save 300 10          #在300秒(5分钟)之后如果至少有10个key发生变化Redis就会自动触发bgsave命令创建快照。 ​ save 60 10000        #在60秒(1分钟)之后如果至少有10000个key发生变化Redis就会自动触发bgsave命令创建快照。 ​ 是否阻塞主线程 Redis 提供了两个命令来生成 RDB 快照文件 save : 同步保存操作会阻塞 Redis 主线程 bgsave : fork 出一个子进程子进程执行不会阻塞 Redis 主线程默认选项。 这里说 Redis 主线程而不是主进程的主要是因为 Redis 启动之后主要是通过单线程的方式完成主要的工作。如果你想将其描述为 Redis 主进程也没毛病 执行后会在服务端目录下生成一个dump.rdb文件而这个文件中就保存了内存中存放的数据当服务器重启后会自动加载里面的内容到对应数据库中。 优缺点 优点恢复快速保存简单 缺点 可能丢失最新更新的数据 性能开销如果我们数据比较大的时候子线程进行保存的时候会消耗较多的cpu资源 AOF 与快照持久化相比AOF 持久化的实时性更好。 开启 AOF 持久化后每执行一条会更改 Redis 中的数据的命令Redis 就会将该命令写入到 AOF 缓冲区 server.aof_buf 中然后再写入到 AOF 文件中此时还在系统内核缓存区未同步到磁盘最后再根据持久化方式 fsync策略的配置来决定何时将系统内核缓存区的数据同步到硬盘中的。 只有同步到磁盘中才算持久化保存了否则依然存在数据丢失的风险比如说系统内核缓存区的数据还未同步磁盘机器就宕机了那这部分数据就算丢失了。 AOF 文件的保存位置和 RDB 文件的位置相同都是通过 dir 参数设置的默认的文件名是 appendonly.aof。 工作流程 AOF 持久化功能的实现可以简单分为 5 步 命令追加append所有的写命令会追加到 AOF 缓冲区中。 文件写入write将 AOF 缓冲区的数据写入到 AOF 文件中。这一步需要调用write函数系统调用write将数据写入到了系统内核缓冲区之后直接返回了延迟写。注意此时并没有同步到磁盘。 文件同步fsyncAOF 缓冲区根据对应的持久化方式 fsync 策略向硬盘做同步操作。这一步需要调用 fsync 函数系统调用 fsync 针对单个文件操作对其进行强制硬盘同步fsync 将阻塞直到写入磁盘完成后返回保证了数据持久化。 文件重写rewrite随着 AOF 文件越来越大需要定期对 AOF 文件进行重写达到压缩的目的。 重启加载load当 Redis 重启时可以加载 AOF 文件进行数据恢复 AOF持久化的策略 在 Redis 的配置文件中存在三种不同的 AOF 持久化方式 fsync策略它们分别是 appendfsync always主线程调用 write 执行写操作后后台线程 aof_fsync 线程立即会调用 fsync 函数同步 AOF 文件刷盘fsync 完成后线程返回这样会严重降低 Redis 的性能write fsync。 appendfsync everysec主线程调用 write 执行写操作后立即返回由后台线程 aof_fsync 线程每秒钟调用 fsync 函数系统调用同步一次 AOF 文件writefsyncfsync间隔为 1 秒 appendfsync no主线程调用 write 执行写操作后立即返回让操作系统决定何时进行同步Linux 下一般为 30 秒一次write但不fsyncfsync 的时机由操作系统决定。 可以看出这 3 种持久化方式的主要区别在于 fsync 同步 AOF 文件的时机刷盘。 为了兼顾数据和写入性能可以考虑 appendfsync everysec 选项 让 Redis 每秒同步一次 AOF 文件Redis 性能受到的影响较小。而且这样即使出现系统崩溃用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候Redis 还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。 AOF重写 当 AOF 变得太大时Redis 能够在后台自动重写 AOF 产生一个新的 AOF 文件这个新的 AOF 文件和原有的 AOF 文件所保存的数据库状态一样但体积更小。 AOF 重写 AOF 重写rewrite 是一个有歧义的名字该功能是通过读取数据库中的键值对来实现的程序无须对现有 AOF 文件进行任何读入、分析或者写入操作。 由于 AOF 重写会进行大量的写入操作为了避免对 Redis 正常处理命令请求造成影响Redis 将 AOF 重写程序放到子进程里执行。 AOF 文件重写期间Redis 还会维护一个 AOF 重写缓冲区该缓冲区会在子进程创建新 AOF 文件期间记录服务器执行的所有写命令。当子进程完成创建新 AOF 文件的工作之后服务器会将重写缓冲区中的所有内容追加到新 AOF 文件的末尾使得新的 AOF 文件保存的数据库状态与现有的数据库状态一致。最后服务器用新的 AOF 文件替换旧的 AOF 文件以此来完成 AOF 文件重写操作。 AOF校验 AOF 校验机制是 Redis 在启动时对 AOF 文件进行检查以判断文件是否完整是否有损坏或者丢失的数据。这个机制的原理其实非常简单就是通过使用一种叫做 校验和checksum 的数字来验证 AOF 文件。这个校验和是通过对整个 AOF 文件内容进行 CRC64 算法计算得出的数字。如果文件内容发生了变化那么校验和也会随之改变。因此Redis 在启动时会比较计算出的校验和与文件末尾保存的校验和计算的时候会把最后一行保存校验和的内容给忽略点从而判断 AOF 文件是否完整。如果发现文件有问题Redis 就会拒绝启动并提供相应的错误信息。AOF 校验机制十分简单有效可以提高 Redis 数据的可靠性。 Redis内存管理 一般我们都是需要给内存设置过期时间首先考虑我们的内存是有限的其次有些数据也是有时效性的。 如何判断数据过期 Redis 通过一个叫做过期字典可以看作是 hash 表来保存数据过期的时间。 过期数据的删除策略 惰性删除只会在取出 key 的时候才对数据进行过期检查。这样对 CPU 最友好但是可能会造成太多过期 key 没有被删除。 定期删除每隔一段时间抽取一批 key 执行删除过期 key 操作。并且Redis 底层会通过限制删除操作执行的时长和频率来减少删除操作对 CPU 时间的影响。 定期删除对内存更加友好惰性删除对 CPU 更加友好。两者各有千秋所以 Redis 采用的是 定期删除惰性/懒汉式删除 。 但是仅仅通过给 key 设置过期时间还是有问题的。因为还是可能存在定期删除和惰性删除漏掉了很多过期 key 的情况。这样就导致大量过期 key 堆积在内存里然后就 Out of memory 了。 怎么解决这个问题呢答案就是Redis 内存淘汰机制。 内存淘汰机制 因为过期时间的删除策略都是具有局限性惰性删除有时无法及时删除定期删除会占用cpu大量的时间 相关问题MySQL 里有 2000w 数据Redis 中只存 20w 的数据如何保证 Redis 中的数据都是热点数据? Redis 提供 6 种数据淘汰策略 volatile-lruleast recently used从已设置过期时间的数据集server.db[i].expires中挑选最近最少使用的数据淘汰。 volatile-ttl从已设置过期时间的数据集server.db[i].expires中挑选将要过期的数据淘汰。 volatile-random从已设置过期时间的数据集server.db[i].expires中任意选择数据淘汰。 allkeys-lruleast recently used当内存不足以容纳新写入数据时在键空间中移除最近最少使用的 key这个是最常用的。 allkeys-random从数据集server.db[i].dict中任意选择数据淘汰。 no-eviction禁止驱逐数据也就是说当内存不足以容纳新写入数据时新写入操作会报错。这个应该没人使用吧 Redis实现分布式锁 Redis缓存问题 缓存穿透 指的是访问一个数据库和缓存中都不存在的数据每一次都会去访问数据库也不会存在缓存中 解决方法 布隆过滤 布隆过滤器是将我们数据库中存在的数据都放置在一个二进制向量中使用N个哈希值将数据进行hash然后存放在里面。每一次查询的时候都先将我们查询的目标都进行N次hash然后如果有一个位置为0则表示数据不存在。 缺点 数据越来越多则会越来越不准确。 存放在布隆过滤器中的值不容易删除 接口限流 按照我们的用户或者IP对接口进行限流设置防刷机制。 缓存击穿 比如某条热点数据过期然后大量的数据去访问数据库带来巨大的压力 穿透和击穿的区别就是数据库中有或者没有 解决办法 设置热点数据永不过期或者过期时间比较长。 针对热点数据提前预热将其存入缓存中并设置合理的过期时间比如秒杀场景下的数据在秒杀结束之前不过期。 请求数据库写数据到缓存之前先获取互斥锁保证只有一个请求会落到数据库上减少数据库的压力。 缓存雪崩 当你的Redis服务器炸了或是大量的Key在同一时间过期这时相当于缓存直接GG了那么如果这时又有很多的请求来访问不同的数据同一时间内缓存服务器就得向数据库大量发起请求来重新建立缓存很容易把数据库也搞GG。 解决办法 采用 Redis 集群避免单机出现问题整个缓存服务都没办法使用。 限流避免同时处理大量的请求。 多级缓存例如本地缓存Redis 缓存的组合当 Redis 缓存出现问题时还可以从本地缓存中获取到部分数据。 缓存预热 常见的缓存预热方式有两种 使用定时任务比如 xxl-job来定时触发缓存预热的逻辑将数据库中的热点数据查询出来并存入缓存中。 使用消息队列比如 RabbitMQ来异步地进行缓存预热将数据库中的热点数据的主键或者 ID 发送到消息队列中然后由缓存服务消费消息队列中的数据根据主键或者 ID 查询数据库并更新缓存。 数据库和缓存一致性 Redis可以将常访问的数据保存起来新的请求先在Redis中进行查询能够缓解数据库的压力。 在读的情况下无论怎样都是不会出现问题的所以关键就是读写出现不一致的问题。 CAP原理 根据CAP原理CAP原则又称CAP定理指的是在一个分布式系统中存在Consistency一致性、Availability可用性、Partition tolerance分区容错性三者不可同时保证最多只能保证其中的两者。 一致性C在分布式系统中的所有数据备份在同一时刻都是同样的值所有的节点无论何时访问都能拿到最新的值 可用性A系统中非故障节点收到的每个请求都必须得到响应比如我们之前使用的服务降级和熔断其实就是一种维持可用性的措施虽然服务返回的是没有什么意义的数据但是不至于用户的请求会被服务器忽略 分区容错性P一个分布式系统里面节点之间组成的网络本来应该是连通的然而可能因为一些故障比如网络丢包等这是很难避免的使得有些节点之间不连通了整个网络就分成了几块区域数据就散布在了这些不连通的区域中这样就可能出现某些被分区节点存放的数据访问失败我们需要来容忍这些不可靠的情况 总的来说数据存放的节点数越多分区容忍性就越高但是要复制更新的次数就越多一致性就越难保证。同时为了保证一致性更新所有节点数据所需要的时间就越长那么可用性就会降低。 所以这里我们只能保证最终一致性 解决方法 当我们修改数据库的数据的时候先更新数据库还是Redis缓存 先删除缓存再更新数据库 当多线程进行访问的时候当线程A需要写入X然后更新数据库的时候线程2来访问缓存X缓存中没有消息进入数据库进行读取读取旧的值X到缓存中这个时候线程1再修改好数据库则最终一致性都不能保证。 先更新数据库再删除缓存 虽然有可能还是会最终一致性无法满足但是概率很小因为读和写请求的并发读请求会更快的读取并且更新到缓存中而读更慢。 双重删除 消息队列 使用消息队列异步删除因为消息队列采用了确认机制所以能够确保缓存中的数据被删除虽然也会读取到脏数据但是这个可以看作MVcc读的操作是在更新的操作之前不能看到更新完成后的失误最后也能实现数据的最终一致性 常见问题 String 还是 Hash存储对象更好呢 具体看我们的使用情况string存储的是已经序列化的数据存放整个对象。Hash是对每个字段单独的进行存储可以获取部分的信息可以修改。所以如果需要经常修改则Hash合适 String 存储更加的节省内存因为Hash 需要保存更多的结构信息