关于redis:几率大的Redis面试题

Redis 长久化机制

Redis 是一个反对长久化的内存数据库，通过长久化机制把内存中的数据同步到硬盘文件来保证数据长久化。当 Redis 重启后通过把硬盘文件从新加载到内存，就能达到复原数据的目标。

实现 ：独自创立 fork() 一个子过程，将以后父过程的数据库数据复制到子过程的内存中，而后由子过程写入到临时文件中，长久化的过程完结了，再用这个临时文件替换上次的快照文件，而后子过程退出，内存开释。

RDB 是 Redis 默认的长久化形式。依照肯定的工夫周期策略把内存的数据以快照的模式保留到硬盘的二进制文件。即 Snapshot 快照存储，对应产生的数据文件为 dump.rdb，通过配置文件中的 save 参数来定义快照的周期。（快照能够是其所示意的数据的一个正本，也能够是数据的一个复制品。）

AOF：Redis 会将每一个收到的写命令都通过 Write 函数追加到文件最初，相似于 MySQL 的 binlog。当 Redis 重启是会通过从新执行文件中保留的写命令来在内存中重建整个数据库的内容。

当两种形式同时开启时，数据恢复 Redis 会优先选择 AOF 复原。

缓存雪崩、缓存穿透、缓存预热、缓存更新、缓存降级等问题

一、缓存雪崩

咱们能够简略的了解为：因为原有缓存生效，新缓存未到期间
(例如：咱们设置缓存时采纳了雷同的过期工夫，在同一时刻呈现大面积的缓存过期)，所有本来应该拜访缓存的申请都去查询数据库了，而对数据库 CPU 和内存造成微小压力，重大的会造成数据库宕机。从而造成一系列连锁反应，造成整个零碎解体。

解决办法：

大多数零碎设计者思考用加锁（最多的解决方案）或者队列的形式保障来保障不会有大量的线程对数据库一次性进行读写，从而防止生效时大量的并发申请落到底层存储系统上。还有一个简略计划就时讲缓存生效工夫扩散开。

二、缓存穿透

缓存穿透 是指用户查问数据，在数据库没有，天然在缓存中也不会有。这样就导致用户查问的时候，在缓存中找不到，每次都要去数据库再查问一遍，而后返回空（相当于进行了两次无用的查问）。这样申请就绕过缓存间接查数据库，这也是常常提的缓存命中率问题。

解决办法 ：
最常见的则是采纳 布隆过滤器，将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个肯定不存在的数据会被这个 bitmap 拦挡掉，从而防止了对底层存储系统的查问压力。

另外也有一个更为 简略粗犷的办法，如果一个查问返回的数据为空（不论是数据不存在，还是系统故障），咱们依然把这个空后果进行缓存，但它的过期工夫会很短，最长不超过五分钟。通过这个间接设置的默认值寄存到缓存，这样第二次到缓冲中获取就有值了，而不会持续拜访数据库，这种方法最简略粗犷。

5TB 的硬盘上放满了数据，请写一个算法将这些数据进行排重。如果这些数据是一些 32bit 大小的数据该如何解决？如果是 64bit 的呢？

对于空间的利用达到了一种极致，那就是 Bitmap 和布隆过滤器(Bloom Filter)。

Bitmap：典型的就是哈希表

毛病是，Bitmap 对于每个元素只能记录 1bit 信息，如果还想实现额定的性能，恐怕只能靠就义更多的空间、工夫来实现了。

布隆过滤器（举荐）

就是引入了 k(k>1)k(k>1)个互相独立的哈希函数，保障在给定的空间、误判率下，实现元素判重的过程。

它的长处是空间效率和查问工夫都远远超过个别的算法，毛病是有肯定的误识别率和删除艰难。

Bloom-Filter算法的核心思想就是利用多个不同的 Hash 函数来解决“抵触”。
Hash 存在一个抵触（碰撞）的问题，用同一个 Hash 失去的两个 URL 的值有可能雷同。为了缩小抵触，咱们能够多引入几个 Hash，如果通过其中的一个 Hash 值咱们得出某元素不在汇合中，那么该元素必定不在汇合中。只有在所有的 Hash 函数通知咱们该元素在汇合中时，能力确定该元素存在于汇合中。这便是 Bloom-Filter 的根本思维。

Bloom-Filter 个别用于在大数据量的汇合中断定某元素是否存在。

受揭示补充：缓存穿透与缓存击穿的区别
三、缓存击穿

缓存击穿：是指一个 key 十分热点，在不停的扛着大并发，大并发集中对这一个点进行拜访，当这个 key 在生效的霎时，继续的大并发就穿破缓存，间接申请数据。

解决方案：在拜访 key 之前，采纳 SETNX（set if not exists）来设置另一个短期 key 来锁住以后 key 的拜访，拜访完结再删除该短期 key。

增：给一个我公司解决的案例：背景双机拿 token，token 在存一份到 redis，保证系统在 token 过期时都只有一个线程去获取 token; 线上环境有两台机器，故应用分布式锁实现。

四、缓存预热

缓存预热这个应该是一个比拟常见的概念，置信很多小伙伴都应该能够很容易的了解，缓存预热就是零碎上线后，将相干的缓存数据间接加载到缓存零碎。这样就能够防止在用户申请的时候，先查询数据库，而后再将数据缓存的问题！用户间接查问当时被预热的缓存数据！

解决思路：

1、间接写个缓存刷新页面，上线时手工操作下；
2、数据量不大，能够在我的项目启动的时候主动进行加载；
3、定时刷新缓存；

五、缓存更新

除了缓存服务器自带的缓存生效策略之外（Redis 默认的有 6 中策略可供选择），咱们还能够依据具体的业务需要进行自定义的缓存淘汰，常见的策略有两种：

（1）定时去清理过期的缓存；
（2）当有用户申请过去时，再判断这个申请所用到的缓存是否过期，过期的话就去底层零碎失去新数据并更新缓存。

两者各有优劣，第一种的毛病是保护大量缓存的 key 是比拟麻烦的，第二种的毛病就是每次用户申请过去都要判断缓存生效，逻辑绝对比较复杂！具体用哪种计划，大家能够依据本人的利用场景来衡量。

六、缓存降级

当访问量剧增、服务呈现问题（如响应工夫慢或不响应）或非核心服务影响到外围流程的性能时，依然须要保障服务还是可用的，即便是有损服务。零碎能够依据一些要害数据进行主动降级，也能够配置开关实现人工降级。
降级的最终目标是保障外围服务可用，即便是有损的。而且有些服务是无奈降级的（如退出购物车、结算）。

以参考日志级别设置预案：

1. 个别：比方有些服务偶然因为网络抖动或者服务正在上线而超时，能够主动降级；
2. 正告：有些服务在一段时间内成功率有稳定（如在 95~100% 之间），能够主动降级或人工降级，并发送告警；
3. 谬误：比方可用率低于 90%，或者数据库连接池被打爆了，或者访问量忽然猛增到零碎能接受的最大阀值，此时能够依据状况主动降级或者人工降级；
4. 严重错误：比方因为非凡起因数据谬误了，此时须要紧急人工降级。

服务降级 的目标，是为了避免 Redis 服务故障，导致数据库跟着一起产生雪崩问题。因而，对于不重要的缓存数据，能够采取服务降级策略，例如一个比拟常见的做法就是，Redis 呈现问题，不去数据库查问，而是间接返回默认值给用户。

热点数据和冷数据是什么

热点数据，缓存才有价值

对于冷数据而言，大部分数据可能还没有再次拜访到就曾经被挤出内存，不仅占用内存，而且价值不大。频繁批改的数据，看状况思考应用缓存

对于下面两个例子，寿星列表、导航信息都存在一个特点，就是信息批改频率不高，读取通常十分高的场景。

对于热点数据，比方咱们的某 IM 产品，生日祝愿模块，当天的寿星列表，缓存当前可能读取数十万次。再举个例子，某导航产品，咱们将导航信息，缓存当前可能读取数百万次。

数据更新前至多读取两次，缓存才有意义。这个是最根本的策略，如果缓存还没有起作用就生效了，那就没有太大价值了。

那存不存在，批改频率很高，然而又不得不思考缓存的场景呢？有！比方，这个读取接口对数据库的压力很大，然而又是热点数据，这个时候就须要思考通过缓存伎俩，缩小数据库的压力，比方咱们的某助手产品的，点赞数，珍藏数，分享数等是十分典型的热点数据，然而又一直变动，此时就须要将数据同步保留到 Redis 缓存，缩小数据库压力。

Memcache 与 Redis 的区别都有哪些？

1. 存储形式 Memecache 把数据全副存在内存之中，断电后会挂掉，数据不能超过内存大小。Redis 有部份存在硬盘上，redis 能够长久化其数据
2. 数据反对类型 memcached 所有的值均是简略的字符串，redis 作为其替代者，反对更为丰盛的数据类型，提供 list，set，zset，hash 等数据结构的存储
3. 应用底层模型不同 它们之间底层实现形式 以及与客户端之间通信的利用协定不一样。Redis 间接本人构建了 VM 机制，因为个别的零碎调用零碎函数的话，会节约肯定的工夫去挪动和申请。
4. value 值大小不同：Redis 最大能够达到 512M；memcache 只有 1mb。
5. redis 的速度比 memcached 快很多
6. Redis 反对数据的备份，即 master-slave 模式的数据备份。

单线程的 redis 为什么这么快

1. 纯内存操作
2. 单线程操作，防止了频繁的上下文切换
3. 采纳了非阻塞 I / O 多路复用机制

redis 的数据类型，以及每种数据类型的应用场景

答复：一共五种

1. String

这个其实没啥好说的，最惯例的 set/get 操作，value 能够是 String 也能够是数字。个别做一些简单的计数性能的缓存。

2. hash

这里 value 寄存的是结构化的对象，比拟不便的就是操作其中的某个字段。博主在做单点登录的时候，就是用这种数据结构存储用户信息，以 cookieId 作为 key，设置 30 分钟为缓存过期工夫，能很好的模拟出相似 session 的成果。

3. list

应用 List 的数据结构，能够做简略的音讯队列的性能。另外还有一个就是，能够利用 lrange 命令，做基于 redis 的分页性能，性能极佳，用户体验好。自己还用一个场景，很适合—取行情信息。就也是个生产者和消费者的场景。LIST 能够很好的实现排队，先进先出的准则。

4. set

因为 set 堆放的是一堆不反复值的汇合。所以能够做全局去重的性能。为什么不必 JVM 自带的 Set 进行去重？因为咱们的零碎个别都是集群部署，应用 JVM 自带的 Set，比拟麻烦，难道为了一个做一个全局去重，再起一个公共服务，太麻烦了。
另外，就是利用交加、并集、差集等操作，能够计算独特爱好，全副的爱好，本人独有的爱好等性能。

5. sorted set

sorted set 多了一个权重参数 score, 汇合中的元素可能按 score 进行排列。能够做排行榜利用，取 TOP N 操作。

Redis 内部结构

Redis 是一种 key/value 型数据库，其中，每个 key 和 value 都是应用对象示意的。每个 Key 都是一个字符串对象, 每个 value 是一个 redisObject 对象. 其数据结构如下:

1. SDS(simple dynamic string)，即简略动静字符串

   SDS蕴含两种格局: raw 和 embstr

   raw 格局字符串实用于字符串长度大于 39 字节，redis3.2 版本当前为 44 个 embstr 编码专门用来保留短字符串的，通过一次内存调配函数来调配一块间断的空间，一次蕴含 redisObejct 和 sdshdr 两个构造；而 raw 会调用两次内存调配

2. 链表 是一种比拟常见的数据结构，易于插入和删除，但随机拜访艰难。

   列表 list 的底层实现就是链表(quicklist= 链表 +ziplist)，此外，Redis 的公布和订阅，慢查问，监视器等也都用到链表

3. 字典 (dict)
   底层 是 key-value 数据库每个字典自带两个 hash 表，一个平时应用，一个用来 rehash. 与 HashMap 原理一样，重要的属性蕴含（size 数组容量大小,Entry<K,V> 数组,usedSize 已应用数组大小,maskSize 用于取模定位槽位)，Entry(key,value,next)

   计算过程:
   依据 hash(key)&maskSize 计算出槽位，存储到数组中
   如何解决 hash 抵触：链表(Redis 采纳)，红黑树
   扩容：扩充一倍，新建数组，从新计算 hash 值和槽位，存储后，更换援用

4. 跳跃表 skiplist
   工夫复杂度：均匀 O(logN), 最坏 O(N)

   用处：sortedset
   程序性操作批量解决
   数据结构：有序汇合的底层实现之一（元素比拟多，元素均为长的字符串），集群节点外部

5. 整数汇合 intset

   用处：set
   类型：int16_t,int32_t,int64_t
   属性：encoding，length，int8_t []
   降级：新增整数大小超过之前的范畴

6. 压缩列表 ziplist

   用处：列表键 list，哈希键 hashtable

   应用场景：列表键蕴含大量列表项，每个列表项均不是长字符串（小整数或短字符串）

   介绍：压缩列表是 Redis 为了节俭内存而开发的，是由一系列非凡编码的间断内存块组成的程序型数据结构。

   一个压缩列表能够蕴含多个节点，每个节点可蕴含一个字节数组或一个整数值。

   构造 ：zlbytes(uint32 4 字节) zltails（uint32 4 字节）zllen（uint16 2 字节）entry1 entry2 … entryN zlend（uint8 1 字节 0xFF）
   解释：
   zlbytes 整个构造占用内存字节数（长度）
   zltail 尾部节点间隔起始地址字节数
   zllen 节点个数
   entryX 节点个数

   entry 构造：previous_entry_length | encoding | content
   问题：连锁更新

注：目前 redis 新版本的 list 采纳 quicklist，实质是 linkedlist+ziplist

redis 的过期策略以及内存淘汰机制

redis 采纳的是定期删除 + 惰性删除策略。

为什么不必定时删除策略?

定时删除, 用一个定时器来负责监督 key, 过期则主动删除。尽管内存及时开释，然而非常耗费 CPU 资源。在大并发申请下，CPU 要将工夫利用在解决申请，而不是删除 key, 因而没有采纳这一策略.

定期删除 + 惰性删除是如何工作的呢?

定期删除，redis 默认每个 100ms 查看，是否有过期的 key, 有过期 key 则删除。须要阐明的是，redis 不是每个 100ms 将所有的 key 查看一次，而是随机抽取进行查看(如果每隔 100ms, 全副 key 进行查看，redis 岂不是卡死)。因而，如果只采纳定期删除策略，会导致很多 key 到工夫没有删除。

于是，惰性删除 派上用场。也就是说在你获取某个 key 的时候，redis 会检查一下，这个 key 如果设置了过期工夫那么是否过期了？如果过期了此时就会删除。
采纳定期删除 + 惰性删除就没其余问题了么?

不是的，如果定期删除没删除 key。而后你也没即时去申请 key，也就是说惰性删除也没失效。这样，redis 的内存会越来越高。那么就应该采纳内存淘汰机制。
在 redis.conf 中有一行配置

maxmemory-policy volatile-lru

该配置就是配内存淘汰策略的(什么，你没配过？好好检查一下本人)

volatile-lru：从已设置过期工夫的数据集（server.db[i].expires）中筛选最近起码应用的数据淘汰

volatile-ttl：从已设置过期工夫的数据集（server.db[i].expires）中筛选将要过期的数据淘汰

volatile-random：从已设置过期工夫的数据集（server.db[i].expires）中任意抉择数据淘汰

allkeys-lru：从数据集（server.db[i].dict）中筛选最近起码应用的数据淘汰

allkeys-random：从数据集（server.db[i].dict）中任意抉择数据淘汰

no-enviction（驱赶）：禁止驱赶数据，新写入操作会报错

ps：如果没有设置 expire 的 key, 不满足先决条件(prerequisites); 那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行为, 和 noeviction(不删除) 基本上统一。

Redis 为什么是单线程的

官网 FAQ 示意，因为 Redis 是基于内存的操作，CPU 不是 Redis 的瓶颈，Redis 的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且 CPU 不会成为瓶颈，那就牵强附会地采纳单线程的计划了（毕竟采纳多线程会有很多麻烦！）Redis 利用队列技术将并发拜访变为串行拜访

1. 绝大部分申请是纯正的内存操作（十分疾速）
2. 采纳单线程, 防止了不必要的上下文切换和竞争条件

3. 非阻塞 IO 长处：

   • 速度快，因为数据存在内存中，相似于 HashMap，HashMap 的劣势就是查找和操作的工夫复杂度都是 O(1)
   • 反对丰盛数据类型，反对 string，list，set，sorted set，hash
   • 反对事务，操作都是原子性，所谓的原子性就是对数据的更改要么全副执行，要么全副不执行
   • 丰盛的个性：可用于缓存，音讯，按 key 设置过期工夫，过期后将会主动删除如何解决 redis 的并发竞争 key 问题

同时有多个子系统去 set 一个 key。这个时候要留神什么呢？

不举荐应用 redis 的事务机制。因为咱们的生产环境，根本都是 redis 集群环境，做了数据分片操作。你一个事务中有波及到多个 key 操作的时候，这多个 key 不肯定都存储在同一个 redis-server 上。因而，redis 的事务机制，非常鸡肋。

(1)如果对这个 key 操作，不要求程序：筹备一个分布式锁，大家去抢锁，抢到锁就做 set 操作即可

(2)如果对这个 key 操作，要求程序：分布式锁 + 工夫戳。假如这会零碎 B 先抢到锁，将 key1 设置为{valueB 3:05}。接下来零碎 A 抢到锁，发现自己的 valueA 的工夫戳早于缓存中的工夫戳，那就不做 set 操作了。以此类推。

(3) 利用队列，将 set 办法变成串行拜访也能够 redis 遇到高并发，如果保障读写 key 的一致性

对 redis 的操作都是具备原子性的, 是线程平安的操作, 你不必思考并发问题,redis 外部曾经帮你解决好并发的问题了。

Redis 集群计划应该怎么做？都有哪些计划？

1.twemproxy，大略概念是，它相似于一个代理形式，应用时在本须要连贯 redis 的中央改为连贯 twemproxy，它会以一个代理的身份接管申请并应用一致性 hash 算法，将申请转接到具体 redis，将后果再返回 twemproxy。
毛病：twemproxy 本身单端口实例的压力，应用一致性 hash 后，对 redis 节点数量扭转时候的计算值的扭转，数据无奈主动挪动到新的节点。

2.codis，目前用的最多的集群计划，根本和 twemproxy 统一的成果，但它反对在 节点数量扭转状况下，旧节点数据可复原到新 hash 节点

3.redis cluster3.0 自带的集群，特点在于他的分布式算法不是一致性 hash，而是 hash 槽的概念，以及本身反对节点设置从节点。具体看官网文档介绍。

有没有尝试进行多机 redis 的部署？如何保证数据统一的？

主从复制，读写拆散

一类是主数据库（master）一类是从数据库（slave），主数据库能够进行读写操作，当产生写操作的时候主动将数据同步到从数据库，而从数据库个别是只读的，并接管主数据库同步过去的数据，一个主数据库能够有多个从数据库，而一个从数据库只能有一个主数据库。

对于大量的申请怎么样解决

redis 是一个单线程程序，也就说同一时刻它只能解决一个客户端申请；
redis 是通过 IO 多路复用（select，epoll, kqueue，根据不同的平台，采取不同的实现）来解决多个客户端申请的

Redis 常见性能问题和解决方案？

(1) Master 最好不要做任何长久化工作，如 RDB 内存快照和 AOF 日志文件

(2) 如果数据比拟重要，某个 Slave 开启 AOF 备份数据，策略设置为每秒同步一次

(3) 为了主从复制的速度和连贯的稳定性，Master 和 Slave 最好在同一个局域网内

(4) 尽量避免在压力很大的主库上减少从库

(5) 主从复制不要用图状构造，用单向链表构造更为稳固，即：

Master <- Slave1 <- Slave2 <-Slave3…

解说下 Redis 线程模型

文件事件处理器包含别离是套接字、I/O 多路复用程序、文件事件分派器（dispatcher）、以及事件处理器。应用 I/O 多路复用程序来同时监听多个套接字，并依据套接字目前执行的工作来为套接字关联不同的事件处理器。当被监听的套接字筹备好执行连贯应答（accept）、读取（read）、写入（write）、敞开（close）等操作时，与操作绝对应的文件事件就会产生，这时文件事件处理器就会调用套接字之前关联好的事件处理器来解决这些事件。
I/O 多路复用程序负责监听多个套接字，并向文件事件分派器传送那些产生了事件的套接字。

工作原理：
1)I/O 多路复用程序负责监听多个套接字，并向文件事件分派器传送那些产生了事件的套接字。只管多个文件事件可能会并发地呈现，但 I/O 多路复用程序总是会将所有产生事件的套接字都入队到一个队列外面，而后通过这个队列，以有序（sequentially）、同步（synchronously）、每次一个套接字的形式向文件事件分派器传送套接字：当上一个套接字产生的事件被处理完毕之后（该套接字为事件所关联的事件处理器执行结束），I/O 多路复用程序才会持续向文件事件分派器传送下一个套接字。如果一个套接字又可读又可写的话，那么服务器将先读套接字，后写套接字.

为什么 Redis 的操作是原子性的，怎么保障原子性的？

对于 Redis 而言，命令的原子性指的是：一个操作的不能够再分，操作要么执行，要么不执行。

Redis 的操作之所以是原子性的，是因为 Redis 是单线程的。

Redis 自身提供的所有 API 都是原子操作，Redis 中的事务其实是要保障批量操作的原子性。

多个命令在并发中也是原子性的吗？

不肯定，将 get 和 set 改成单命令操作，incr。应用 Redis 的事务，或者应用 Redis+Lua== 的形式实现.

Redis 事务

Redis 事务性能 是通过 MULTI、EXEC、DISCARD 和 WATCH 四个原语实现的
Redis 会将一个事务中的所有命令序列化，而后按程序执行。

1.redis 不反对回滚“Redis 在事务失败时不进行回滚，而是继续执行余下的命令”，所以 Redis 的外部能够放弃简略且疾速。

2. 如果在一个事务中的命令呈现谬误，那么所有的命令都不会执行；

3. 如果在一个事务中呈现运行谬误，那么正确的命令会被执行。

注：redis 的 discard 只是完结本次事务, 正确命令造成的影响依然存在.

1）MULTI 命令用于开启一个事务，它总是返回 OK。MULTI 执行之后，客户端能够持续向服务器发送任意多条命令，这些命令不会立刻被执行，而是被放到一个队列中，当 EXEC 命令被调用时，所有队列中的命令才会被执行。

2）EXEC：执行所有事务块内的命令。返回事务块内所有命令的返回值，按命令执行的先后顺序排列。当操作被打断时，返回空值 nil。

3）通过调用 DISCARD，客户端能够清空事务队列，并放弃执行事务，并且客户端会从事务状态中退出。

4）WATCH 命令能够为 Redis 事务提供 check-and-set（CAS）行为。能够监控一个或多个键，一旦其中有一个键被批改（或删除），之后的事务就不会执行，监控始终继续到 EXEC 命令。

Redis 实现分布式锁

Redis 为单过程单线程模式，采纳队列模式将并发拜访变成串行拜访，且多客户端对 Redis 的连贯并不存在竞争关系 Redis 中能够应用 SETNX 命令实现分布式锁。
将 key 的值设为 value，当且仅当 key 不存在。若给定的 key 曾经存在，则 SETNX 不做任何动作

解锁：应用 del key 命令就能开释锁

解决死锁：
1）通过 Redis 中 expire()给锁设定最大持有工夫，如果超过，则 Redis 来帮咱们开释锁。

2）应用 setnx key“以后零碎工夫 + 锁持有的工夫”和 getset key“以后零碎工夫 + 锁持有的工夫”组合的命令就能够实现。