Redis知识点面试篇1.为什么使用nosql主要是由于随着互联网发展数据量越来越大对性能要求越来越高传统数据库存在着先天性的缺陷即单机单库性能瓶颈并且扩展困难。NoSQL 根本性的优势在于在云计算时代简单、易于大规模分布式扩展并且读写性能非常高2.nosql数据库分类列存储、文档存储 、key-values存储、图存储、对象存储、xml数据库3.CAP理论对于一个分布式计算系统不可能同时满足以下三点只能两两满足。CConsistency。即一致性 所有节点在同一时间具有相同的数据视图。换句话说如果一个节点在写入操作完成后所有其他节点都能立即读取到最新的数据。AAvailability即可用性所有的节点都保持高可用性,要求服务在接收到客户端请求后都能够给出响应。每个非故障节点都能够在有限的时间内返回有效的响应即系统一直可用。可用性强调系统对用户请求的及时响应。PPartiton tolerance。分区容错性。分区是指系统中的节点由于网络故障无法相互通信导致系统被分成多个孤立的子系统。在分布式系统中不同节点之间通过网络进行通信。分区容忍性是指当分布式系统中出现网络分区即系统中的一部分节点无法和其他节点进行通信时系统能够容忍这种情况并且分离的系统也能够正常运行。这意味着即使系统中某些节点或网络分区出现故障或延迟整个系统仍然能够继续运作不会受到单点故障的影响。CA - 单点集群满足一致性可用性的系统通常在可扩展性上不太强大。比如单一数据中心数据库所有节点都位于同一个数据中心并且节点之间的通信是高可靠的。CP-满足一致性分区容忍性的系统通常性能不是特别高。例如: Zookeeper,ETCD,Consul,MySQL的PXC等集群就是追求的强一致AP - 满足可用性分区容忍性的系统通常可能对一致性要求低一些。例如MySQL主从复制默认是异步机制就可以实现AP但是用户接受所查询的到数据在一定时间内不是最新的.4.缓存的实现流程5.缓存穿透缓存击穿和缓存雪崩缓存穿透指缓存和数据库中都没有的数据而用户不断发起请求这时的用户可能是攻击者会导致数据库压力过大。解决接口层增加校验如用户鉴权校验ID做基础校验缓存击穿指缓存中没有但数据库中有的数据比如热点数据的缓存时间到期后这时由于并发用户特别多同时读缓存没读到数据又同时去数据库去取数据引起数据库压力瞬间增大解决设置热点数据永不过期缓存雪崩指缓存中数据大批量到过期时间而查询数据量巨大引起数据库压力过大甚至down机解决缓存数据的过期时间设置随机防止同一时间大量数据过期现象发生如果缓存数据库是分布式部署将热点数据均匀分布在不同缓存数据中设置热点数据永不过期缓存宕机crashRedis 缓存服务宕机造成 缓存服务失效解决方法Redis高可用集群6、redis慢查询6.1什么是redis慢查询和mysql慢查询有什么区别Redis 慢查询Redis 会记录执行时间超过预设阈值的命令存入慢查询日志用来定位执行耗时过高的 Redis 命令。区别统计范围MySQL 慢查询包含网络传输、锁等待、执行时间Redis 慢查询只统计服务端命令执行耗时不统计网络往返、队列等待时间。命令在队列排队阻塞哪怕整体客户端耗时很久只要命令本身执行快不会进慢查询。存储方式MySQL写入磁盘日志文件Redis 慢查询默认存内存环形队列重启全部丢失不会自动落盘。触发对象MySQL 是 SQL 语句Redis 是 Redis 命令keys、hgetall、smembers 等。6.2Redis 慢查询两个核心配置参数 slowlog-log-slower-than、slowlog-max-len含义单位是啥slowlog-log-slower-than慢查询阈值单位微秒值为0记录所有命令值为负数关闭慢查询超过阈值的命令会被记录慢查询slowlog-max-len慢查询内存队列最大长度redis慢查询保存在内存环形队列不写磁盘。达到长度上限后旧的慢查询记录会被新的记录挤出去丢弃。6.3线上 Redis客户端反馈请求响应很慢但是看 Redis 慢查询日志几乎没有记录会是什么原因因为redis慢查询值统计命令执行耗时下面这些场景客户端延迟很高但是不会产生慢查询记录命令排队阻塞Redis 单线程模型如果前面有一条大命令占住主线程后面大量请求在队列排队等待。后面的命令本身执行很快但排队等待时间久。客户端看到延迟高但是这些后续命令执行时间很短不会进入慢查询。网络问题客户端和服务端网络抖动、带宽打满、TCP 丢包网络往返耗时高服务端执行命令很快。客户端自身问题客户端 CPU 高、线程池耗尽、连接池耗尽请求在客户端排队等待发送。Redis 触发持久化 fork 子进程RDB fork操作系统拷贝页表会短暂阻塞主线程造成请求卡顿但实际每条命令执行本身很快。大量 key 过期、大 key 驱逐内存淘汰策略触发大量 key 清理主线程阻塞。排查思路看 Redis 的latency延迟监控、查看 CPU、网络、客户端连接池情况不能只依赖慢查询。6.4线上大量慢查询拿到慢查询记录之后完整排查、处理的思路是什么通过slowlog get 拿到慢查询确认时哪一类命令是全量遍历keys/hgetall/smembers还是复杂操作还是大key操作记录命令、耗时、发生时间。确认慢查询发生频率是偶发还是持续大量出现判断根因若是高危全量命令推动业务改成 scan 迭代方式若是大 key定位大 key拆分 key若是批量操作业务侧拆分请求减少单次操作数据量环境侧检查Redis 内存是否打满、是否频繁内存淘汰、是否有 fork RDB/AOF 刷盘阻塞。监控加固脚本定时采集慢查询日志落盘配置监控告警当慢查询数量突增触发告警输出记录给到开发推动业务代码优化更新运维故障文档6.5慢查询日志抓到一条慢查询是 KEYS *为什么这个命令会很慢生产怎么处理keys *遍历 Redis 全量 key单线程执行key 数量巨大的时候会阻塞整个 Redis 主线程所有其他命令全部被阻塞属于高危命令。禁止在线上业务直接使用 keys替代方案如果要遍历 key生产使用 SCAN游标迭代遍历分批获取 key不会阻塞主线程运维排查可在从库执行 scan避免影响主库业务。7持久化7.1什么是 RDBRDB 持久化的两种触发方式分别是什么RDB 是 Redis 的快照持久化机制把 Redis 某一时刻内存中全量数据以二进制快照文件保存到磁盘文件名叫dump.rdb。分为自动触发、手动触发。手动触发SAVE主线程同步执行 RDBRedis 阻塞大数据量会卡死业务生产基本禁用。BGSAVEfork 子进程做快照父进程继续处理客户端请求不会阻塞主线程fork 瞬间会短暂阻塞。自动触发配置 save 参数redis.conf 中save 900 1 #含义900 秒内至少发生 1 次 key 改动则执行 BGSAVE。注意save 配置本质是自动调用 BGSAVE不是 SAVE。额外触发场景Redis 正常关闭shutdown如果没有开启 AOF会自动执行 BGSAVE 生成 rdb主从全量同步主库执行 BGSAVE把 RDB 发送给从库做数据同步。7.2RDB模式的优缺点优点RDB快照只保存某个时间点的数据恢复的时候直接加载到内存即可不用做其他处理这种文件适合用于做灾备处理.可以通过自定义时间点执行redis指令bgsave或者save保存快照实现多个版本的备份。比如: 可以在最近的24小时内每小时备份一次RDB文件并且在每个月的每一天也备份一个RDB文件。这样的话即使遇上问题也可以随时将数据集还原到指定的不同的版本。RDB在大数据集时恢复的速度比AOF方式要快缺点不能实时保存数据可能会丢失自上一次执行RDB备份到当前的内存数据。如果需要尽量避免在服务器故障时丢失数据那么RDB并不适合。虽然Redis允许设置不同的保存点save point来控制保存RDB文件的频率但是因为RDB文件需要保存整个数据集的状态所以它可能并不是一个非常快速的操作。因此一般会超过5分钟以上才保存一次RDB文件。在这种情况下一旦发生故障停机就可能会丢失较长时间的数据。在数据集比较庞大时fork()子进程可能会非常耗时造成服务器在一定时间内停止处理客户端请求,如果数据集非常巨大并且CPU时间非常紧张的话那么这种停止时间甚至可能会长达整整一秒或更久。另外子进程完成生成RDB文件的时间也会花更长时间.误删除无法恢复7.3SRE 视角线上 RDB 生产最佳实践是什么不要把 RDB 作为唯一持久化方案生产建议 RDB AOF 同时开启大内存主库关闭自动 save 触发RDB 备份放在从库执行减轻主库 fork 阻塞压力定时将 rdb 文件异地备份其他机器 / 对象存储不要只存在本机监控 BGSAVE 执行状态、fork 耗时配置告警预留足够磁盘空间防止生成 rdb 时磁盘满导致备份失败业务高峰期避免手动执行 BGSAVE系统内核参数调优vm.overcommit_memory1避免 fork 失败。7.4什么是 AOFAOF 三种刷盘策略分别是什么SRE 角度分析各自优缺点AOFAppend‑Only File日志追加持久化。Redis 把每一条写命令以文本协议格式追加写入 AOF 日志文件重启时重放 AOF 里面的命令恢复内存数据。appendfsync三个刷盘策略appendfsync always每执行一条写命令就调用 fsync 刷盘到磁盘。 优点最多丢失 1 条命令数据安全性最高 缺点IO 极其频繁磁盘压力巨大性能很差生产几乎不用。appendfsync everysec生产默认推荐Redis 每秒执行一次 fsync把缓冲区数据刷入磁盘。 优点性能较好最坏情况宕机丢失1 秒的数据兼顾性能与安全。 缺点如果磁盘 IO 压力很高fsync 会被阻塞。appendfsync no交给操作系统控制刷盘时机Redis 不主动 fsync。 优点性能最好 缺点丢失数据取决于操作系统可能丢失几秒到几十秒数据风险高。生产会结合业务容忍丢失数据的程度选择刷盘策略7.5AOF 重写AOF‑Rewrite是什么为什么需要 AOF 重写触发方式为什么需要重写。AOF 不断追加写命令文件会越变越大。比如同一个 key 多次 setAOF 会保存多条 set恢复时全部重放文件臃肿、重启恢复慢。 AOF 重写Redis 生成一份新 AOF 文件只保留 key 最终状态丢弃中间冗余命令实现 AOF 文件压缩变小。重写不会读取旧 AOF读取当前内存数据生成新日志。触发分为手动、自动手动触发BGREWRITEAOF后台子进程执行类似BGSAVE自动触发配置两个参数控制auto‑aof‑rewrite‑percentage100#AOF文件相比上次重写后增长100%触发重写auto‑aof‑rewrite‑min‑size 64mb#AOF至少达到64MB才允许触发重写8消息队列8.1说一下消息队列两种模式生产者消费者模式生产者消费者模式下多个消费者同时监听一个频道(redis用队列实现)但是生产者产生的一个消息只能被最先抢到消息的一个消费者消费一次,队列中的消息由可以多个生产者写入也可以有不同的消费者取出进行消费处理.此模式应用广泛发布者订阅者模式在发布者订阅者Publisher/Subscriber模式下发布者Publisher将消息发布到指定的频道channel事先监听此channel的一个或多个订阅者Subscriber都会收到相同的消息。即一个消息可以由多个订阅者获取到. 对于社交应用中的群聊、群发、群公告等场景适用于此模式9高可用9.1主从复制故障恢复当从节点宕机时将redis client指向另一个slave节点即可并及时修复故障从节点当master节点故障时需要提升slave为新的mastermaster故障后当前还只能手动提升一个slave节点为master而master的切换会导致master_repild发生变化slave之前的这个和当前的master不一致从而会引发所有的slave的全量同步将redis client指向另一个slave节点即可并及时修复故障从节点当master节点故障时需要提升slave为新的mastermaster故障后当前还只能手动提升一个slave节点为master而master的切换会导致master_repild发生变化slave之前的这个和当前的master不一致从而会引发所有的slave的全量同步