redis—相关问题汇总

什么是redis？

Redis 本质上是一个 Key-Value 类型的内存数据库，  整个数据库加载在内存当中进行操做， 按期经过异步操做把数据库数据 flush 到硬盘上进行保存。

由于是纯内存操做， Redis 的性能很是出色， 每秒能够处理超过 10 万次读写操做， 是已知性能
最快的 Key-Value DB。
Redis 的出色之处不只仅是性能， Redis 最大的魅力是支持保存多种数据结构， 此外单个
value 的最大限制是 1GB， 不像 memcached 只能保存 1MB 的数据， 所以 Redis 能够用
来实现不少有用的功能，比方说用他的 List 来作 FIFO 双向链表，实现一个轻量级的高性 能
消息队列服务， 用他的 Set 能够作高性能的 tag 系统等等。

另外 Redis 也能够对存入的Key-Value 设置 expire 时间， 所以也能够被看成一 个功能增强版的 memcached 来用。
Redis 的主要缺点是数据库容量受到物理内存的限制， 不能用做海量数据的高性能读写， 所以 Redis 适合的场景主要局限在较小数据量的高性能操做和运算上

 相比 memcached 有哪些优点？

(1) memcached 全部的值均是简单的字符串， Redis 做为其替代者， 支持更为丰富的数据类型

(2)Redis 的速度比 memcached 快不少
(3) Redis 能够持久化其数据
 

Redis 的全称是什么？

Remote Dictionary Server。

支持哪几种数据类型？

String、 List、 Set、 Sorted Set、 hashes
 

 

Redis 有哪几种数据淘汰策略？

noeviction:返回错误当内存限制达到而且客户端尝试执行会让更多内存被使用的命令（大
部分的写入指令， 但 DEL 和几个例外）
allkeys-lru: 尝试回收最少使用的键（LRU）， 使得新添加的数据有空间存放。
volatile-lru: 尝试回收最少使用的键（LRU）， 但仅限于在过时集合的键,使得新添加的数据
有空间存放。
allkeys-random: 回收随机的键使得新添加的数据有空间存放。
volatile-random: 回收随机的键使得新添加的数据有空间存放，但仅限于在过时集合的键。
volatile-ttl: 回收在过时集合的键， 而且优先回收存活时间（TTL） 较短的键,使得新添加的
数据有空间存放
 

redis为何采用跳表而不是红黑树
在作范围查找的时候，平衡树比skiplist操做要复杂。在平衡树上，咱们找到指定范围的小值以后，还须要以中序遍历的顺序继续寻找其它不超过大值的节点。若是不对平衡树进行必定的改造，这里的中序遍历并不容易实现。而在skiplist上进行范围查找就很是简单，只须要在找到小值以后，对第1层链表进行若干步的遍历就能够实现。
平衡树的插入和删除操做可能引起子树的调整，逻辑复杂，而skiplist的插入和删除只须要修改相邻节点的指针，操做简单又快速。
从内存占用上来讲，skiplist比平衡树更灵活一些。通常来讲，平衡树每一个节点包含2个指针（分别指向左右子树），而skiplist每一个节点包含的指针数目平均为1/(1-p)，具体取决于参数p的大小。若是像Redis里的实现同样，取p=1/4，那么平均每一个节点包含1.33个指针，比平衡树更有优点。
查找单个key，skiplist和平衡树的时间复杂度都为O(log n)，大致至关；而哈希表在保持较低的哈希值冲突几率的前提下，查找时间复杂度接近O(1)，性能更高一些。因此咱们日常使用的各类Map或dictionary结构，大都是基于哈希表实现的。
从算法实现难度上来比较，skiplist比平衡树要简单得多。

介绍一下HyperLogLog？
HyperLogLog 是一种几率数据结构，用来估算数据的基数。数据集能够是网站访客的 IP 地址，E-mail 邮箱或者用户 ID。

基数就是指一个集合中不一样值的数目，好比 a, b, c, d 的基数就是 4，a, b, c, d, a 的基数仍是 4。虽然 a 出现两次，只会被计算一次。

使用 Redis 统计集合的基数通常有三种方法，分别是使用 Redis 的 HashMap，BitMap 和 HyperLogLog。前两个数据结构在集合的数量级增加时，所消耗的内存会大大增长，可是 HyperLogLog 则不会。

Redis 的 HyperLogLog 经过牺牲准确率来减小内存空间的消耗，只须要12K内存，在标准偏差0.81%的前提下，可以统计2^64个数据。因此 HyperLogLog 是否适合在好比统计日活月活此类的对精度要不不高的场景。

这是一个很惊人的结果，以如此小的内存来记录如此大数量级的数据基数。

为何 Redis 须要把全部数据放到内存中？

Redis 为了达到最快的读写速度将数据都读到内存中， 并经过异步的方式将数据写入磁盘。
因此 Redis 具备快速和数据持久化的特征。 若是不将数据放在内存中， 磁盘 I/O 速度为严重
影响 Redis 的性能。 在内存愈来愈便宜的今天， Redis 将会愈来愈受欢迎。

 

Redis支持的数据类型？
String字符串：

格式: set key value

string类型是二进制安全的。意思是redis的string能够包含任何数据。好比jpg图片或者序列化的对象 。

string类型是Redis最基本的数据类型，一个键最大能存储512MB。

 

Hash（哈希）

格式: hmset name  key1 value1 key2 value2

Redis hash 是一个键值(key=>value)对集合。

Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。

 

List（列表）

Redis 列表是简单的字符串列表，按照插入顺序排序。你能够添加一个元素到列表的头部（左边）或者尾部（右边）

格式: lpush  name  value

在 key 对应 list 的头部添加字符串元素

格式: rpush  name  value

在 key 对应 list 的尾部添加字符串元素

格式: lrem name  index

key 对应 list 中删除 count 个和 value 相同的元素

格式: llen name  

返回 key 对应 list 的长度

 

Set（集合）

格式: sadd  name  value

Redis的Set是string类型的无序集合。

集合是经过哈希表实现的，因此添加，删除，查找的复杂度都是O(1)。

 

zset(sorted set：有序集合)

格式: zadd  name score value

Redis zset 和 set 同样也是string类型元素的集合,且不容许重复的成员。

不一样的是每一个元素都会关联一个double类型的分数。redis正是经过分数来为集合中的成员进行从小到大的排序。

zset的成员是惟一的,但分数(score)却能够重复。

 

 sds相对c的改进？
  获取长度：c字符串并不记录自身长度，因此获取长度只能遍历一遍字符串，redis直接读取len便可。

    缓冲区安全：c字符串容易形成缓冲区溢出，好比：程序员没有分配足够的空间就执行拼接操做。而redis会先检查sds的空间是否知足所须要求，若是不知足会自动扩充。

    内存分配：因为c不记录字符串长度，对于包含了n个字符的字符串，底层老是一个长度n+1的数组，每一次长度变化，老是要对这个数组进行一次内存从新分配的操做。由于内存分配涉及复杂算法而且可能须要执行系统调用，因此它一般是比较耗时的操做。   
 

redis链表源码？有什么特性？
 

双端、无环、带长度记录、

多态：使用 void* 指针来保存节点值， 能够经过 dup 、 free 、 match 为节点值设置类型特定函数， 能够保存不一样类型的值。

字典是如何实现的？
其实字典这种数据结构也内置在不少高级语言中，可是c语言没有，因此redis本身实现了。

应用也比较普遍，好比redis的数据库就是字典实现的。不只如此，当一个哈希键包含的键值对比较多，或者都是很长的字符串，redis就会用字典做为哈希键的底层实现。

LRU？redis里的具体实现？
LRU全称是Least Recently Used，即最近最久未使用的意思。

LRU算法的设计原则是：若是一个数据在最近一段时间没有被访问到，那么在未来它被访问的可能性也很小。也就是说，当限定的空间已存满数据时，应当把最久没有被访问到的数据淘汰。

redis原始的淘汰算法简单实现：当须要淘汰一个key时，随机选择3个key，淘汰其中间隔时间最长的key。**基本上，咱们随机选择key，淘汰key效果很好。后来随机3个key改为一个配置项"N随机key"。但把默认值提升改为5个后效果大大提升。考虑到它的效果，你根本不用修改他。

redis的持久化？
RDB持久化能够手动执行，也能够配置按期执行，能够把某个时间的数据状态保存到RDB文件中，反之，咱们能够用RDB文件还原数据库状态。

AOF持久化是经过保存服务器执行的命令来记录状态的。还原的时候再执行一遍便可。

 

如何选择合适的持久化方式？

通常来讲， 若是想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久
化功能。 若是你很是关心你的数据， 但仍然能够承受数分钟之内的数据丢失， 那么你能够
只使用 RDB 持久化。
有不少用户都只使用 AOF 持久化， 但并不推荐这种方式： 由于定时生成 RDB 快照
（snapshot） 很是便于进行数据库备份， 而且 RDB 恢复数据集的速度也要比 AOF 恢复
的速度要快， 除此以外， 使用 RDB 还能够避免以前提到的 AOF 程序的 bug。
 

Redis 集群方案应该怎么作？ 都有哪些方案？

1.twemproxy， 大概概念是， 它相似于一个代理方式， 使用方法和普通 Redis 无任何区别，
设 置 好它 下 属 的多 个 Redis 实 例 后， 使 用 时在 本 需 要 链接 Redis 的 地 方改 为 链接
twemproxy， 它会以一个代理的身份接收请求并使用一致性 hash 算法， 将请求转接到具
体 Redis， 将结果再返回 twemproxy。 使用方式简便(相对 Redis 只需修改链接端口)， 对
旧项目扩展的首选。 问题： twemproxy 自身单端口实例的压力， 使用一致性 hash 后， 对
Redis 节点数量改变时候的计算值的改变， 数据没法自动移动到新的节点。
2. codis， 目前用的最多的集群方案， 基本和 twemproxy 一致的效果， 但它支持在 节点
数量改变状况下， 旧节点数据可恢复到新 hash 节点。
3. Redis cluster3.0 自带的集群， 特色在于他的分布式算法不是一致性 hash， 而是 hash
槽的概念， 以及自身支持节点设置从节点。 具体看官方文档介绍。
4.在业务代码层实现， 起几个毫无关联的 Redis 实例， 在代码层， 对 key 进行 hash 计算，
而后去对应的 Redis 实例操做数据。 这种方式对 hash 层代码要求比较高， 考虑部分包括，
节点失效后的替代算法方案， 数据震荡后的自动脚本恢复， 实例的监控， 等等

MySQL 里有 2000w 数据， Redis 中只存 20w 的数据，

如何保证 Redis 中的数据都是热点数据？

Redis 内存数据集大小上升到必定大小的时候， 就会施行数据淘汰策略

Redis 有哪些适合的场景？

（1）、 会话缓存（Session Cache）
最经常使用的一种使用 Redis 的情景是会话缓存（session cache）。 用 Redis 缓存会话比其余
存储（如 Memcached） 的优点在于： Redis 提供持久化。 当维护一个不是严格要求一致性
的缓存时， 若是用户的购物车信息所有丢失， 大部分人都会不高兴的， 如今， 他们还会这样
吗？
幸运的是， 随着 Redis 这些年的改进， 很容易找到怎么恰当的使用 Redis 来缓存会话的文
档。 甚至广为人知的商业平台 Magento 也提供 Redis 的插件。
（2）、 全页缓存（FPC）
除基本的会话 token 以外， Redis 还提供很简便的 FPC 平台。 回到一致性问题， 即便重启
了 Redis 实例， 由于有磁盘的持久化， 用户也不会看到页面加载速度的降低， 这是一个极
大改进， 相似 PHP 本地 FPC。
再次以 Magento 为例， Magento 提供一个插件来使用 Redis 做为全页缓存后端。
此外， 对 WordPress 的用户来讲， Pantheon 有一个很是好的插件 wp-Redis， 这个插件
能帮助你以最快速度加载你曾浏览过的页面。
（3）、 队列
Reids 在内存存储引擎领域的一大优势是提供 list 和 set 操做，这使得 Redis 能做为一个
很好的消息队列平台来使用。 Redis 做为队列使用的操做， 就相似于本地程序语言（如
Python） 对 list 的 push/pop 操做。
若是你快速的在 Google 中搜索“Redis queues”， 你立刻就能找到大量的开源项目， 这些
项目的目的就是利用 Redis 建立很是好的后端工具， 以知足各类队列需求。 例如， Celery
有一个后台就是使用 Redis 做为 broker， 你能够从这里去查看。
（4）、 排行榜/计数器
Redis在内存中对数字进行递增或递减的操做实现的很是好。集合（Set）和有序集合（Sorted
Set） 也使得咱们在执行这些操做的时候变的很是简单， Redis 只是正好提供了这两种数据
结构。 因此， 咱们要从排序集合中获取到排名最靠前的 10 个用户–咱们称之为
“user_scores”， 咱们只须要像下面同样执行便可：
固然， 这是假定你是根据你用户的分数作递增的排序。 若是你想返回用户及用户的分数， 你
须要这样执行：
ZRANGE user_scores 0 10 WITHSCORES
Agora Games 就是一个很好的例子， 用 Ruby 实现的， 它的排行榜就是使用 Redis 来存储
数据的， 你能够在这里看到。
（5）、 发布/订阅
最后 是 Redis 的发布/订阅功能。 发布/订阅的使用场景确实非
常多。 我已看见人们在社交网络链接中使用， 还可做为基于发布/订阅的脚本触发器， 甚至
用 Redis 的发布/订阅功能来创建聊天系统。

说说 Redis 哈希槽的概念？

Redis 集群没有使用一致性 hash,而是引入了哈希槽的概念， Redis 集群有 16384 个哈希槽，
每一个 key 经过 CRC16 校验后对 16384 取模来决定放置哪一个槽， 集群的每一个节点负责一部分
hash 槽

为何Redis集群有16384个槽
(1)若是槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。

如上所述，在消息头中，最占空间的是myslots[CLUSTER_SLOTS/8]。 当槽位为65536时，这块的大小是: 65536÷8÷1024=8kb 由于每秒钟，redis节点须要发送必定数量的ping消息做为心跳包，若是槽位为65536，这个ping消息的消息头太大了，浪费带宽。

(2)redis的集群主节点数量基本不可能超过1000个。

如上所述，集群节点越多，心跳包的消息体内携带的数据越多。若是节点过1000个，也会致使网络拥堵。所以redis做者，不建议redis cluster节点数量超过1000个。 那么，对于节点数在1000之内的redis cluster集群，16384个槽位够用了。没有必要拓展到65536个。

(3)槽位越小，节点少的状况下，压缩比高

Redis主节点的配置信息中，它所负责的哈希槽是经过一张bitmap的形式来保存的，在传输过程当中，会对bitmap进行压缩，可是若是bitmap的填充率slots / N很高的话(N表示节点数)，bitmap的压缩率就很低。 若是节点数不多，而哈希槽数量不少的话，bitmap的压缩率就很低。

Redis 集群会有写操做丢失吗？ 为何？

Redis 并不能保证数据的强一致性， 这意味这在实际中集群在特定的条件下可能会丢失写操
做。
 

Redis 集群方案应该怎么作？都有哪些方案？

1.twemproxy，大概概念是，它相似于一个代理方式， 使用时在本须要链接 redis 的地方改成链接 twemproxy， 它会以一个代理的身份接收请求并使用一致性 hash 算法，将请求转接到具体 redis，将结果再返回 twemproxy。
缺点： twemproxy 自身单端口实例的压力，使用一致性 hash 后，对 redis 节点数量改变时候的计算值的改变，数据没法自动移动到新的节点。

2.codis，目前用的最多的集群方案，基本和 twemproxy 一致的效果，但它支持在 节点数量改变状况下，旧节点数据可恢复到新 hash 节点

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

为何要作 Redis 分区？

分区可让 Redis 管理更大的内存， Redis 将可使用全部机器的内存。 若是没有分区， 你
最多只能使用一台机器的内存。 分区使 Redis 的计算能力经过简单地增长计算机获得成倍提
升,Redis 的网络带宽也会随着计算机和网卡的增长而成倍增加。
 

Redis 分区有什么缺点？

涉及多个 key 的操做一般不会被支持。 例如你不能对两个集合求交集， 由于他们可能被存
储到不一样的 Redis 实例（实际上这种状况也有办法， 可是不能直接使用交集指令）。
同时操做多个 key,则不能使用 Redis 事务.
分区使用的粒度是key，不能使用一个很是长的排序key存储一个数据集（The partitioning
granularity is the key, so it is not possible to shard a dataset with a single huge
key like a very big sorted set） .
当使用分区的时候， 数据处理会很是复杂， 例如为了备份你必须从不一样的 Redis 实例和主
机同时收集 RDB / AOF 文件。
分区时动态扩容或缩容可能很是复杂。 Redis 集群在运行时增长或者删除 Redis 节点， 能
作到最大程度对用户透明地数据再平衡，但其余一些客户端分区或者代理分区方法则不支持
这种特性。 然而， 有一种预分片的技术也能够较好的解决这个问题。

 

Redis 与其余 key-value 存储有什么不一样？

Redis 有着更为复杂的数据结构而且提供对他们的原子性操做，这是一个不一样于其余数据库
的进化路径。 Redis 的数据类型都是基于基本数据结构的同时对程序员透明， 无需进行额外
的抽象。
Redis 运行在内存中可是能够持久化到磁盘，因此在对不一样数据集进行高速读写时须要权衡
内存， 应为数据量不能大于硬件内存。 在内存数据库方面的另外一个优势是， 相比在磁盘上
相同的复杂的数据结构， 在内存中操做起来很是简单， 这样 Redis 能够作不少内部复杂性
很强的事情。 同时， 在磁盘格式方面他们是紧凑的以追加的方式产生的， 由于他们并不需
要进行随机访问

Redis 的内存用完了会发生什么？

若是达到设置的上限， Redis 的写命令会返回错误信息（可是读命令还能够正常返回。） 或
者你能够将 Redis 当缓存来使用配置淘汰机制，当 Redis 达到内存上限时会冲刷掉旧的内容。
 

Redis 是单线程的， 如何提升多核 CPU 的利用率？

能够在同一个服务器部署多个 Redis 的实例， 并把他们看成不一样的服务器来使用， 在某些时
候， 不管如何一个服务器是不够的，
因此， 若是你想使用多个 CPU， 你能够考虑一下分片（shard）。

一个 Redis 实例最多能存放多少的 keys？ List、 Set、Sorted Set 他们最多能存放多少元素？

理论上 Redis 能够处理多达 232 的 keys， 而且在实际中进行了测试， 每一个实例至少存放了 2亿 5 千万的 keys。 咱们正在测试一些较大的值。
任何 list、 set、 和 sorted set 均可以放 232 个元素。
换句话说， Redis 的存储极限是系统中的可用内存值

 

修改配置不重启 Redis 会实时生效吗？

针对运行实例， 有许多配置选项能够经过 CONFIG SET 命令进行修改， 而无需执行任何
形式的重启。 从 Redis 2.2 开始， 能够从 AOF 切换到 RDB 的快照持久性或其余方式
而不须要重启 Redis。 检索 ‘CONFIG GET *’ 命令获取更多信息。
但偶尔从新启动是必须的， 如为升级 Redis 程序到新的版本， 或者当你须要修改某些目前
CONFIG 命令还不支持的配置参数的时候
 

哨兵
Redis sentinel 是一个分布式系统中监控 redis 主从服务器，并在主服务器下线时自动进行故障转移。其中三个特性：

监控（Monitoring）：    Sentinel  会不断地检查你的主服务器和从服务器是否运做正常。

提醒（Notification）： 被监控的某个 Redis 服务器出现问题时， Sentinel 能够经过 API 向管理员或者其余应用程序发送通知。

自动故障迁移（Automatic failover）： 当一个主服务器不能正常工做时， Sentinel 会开始一次自动故障迁移操做。

特色：

一、保证高可用

二、监控各个节点

三、自动故障迁移

缺点：主从模式，切换须要时间丢数据

没有解决 master 写的压力

 

缓存穿透

通常的缓存系统，都是按照key去缓存查询，若是不存在对应的value，就去后端系统查找（好比DB）。

一些恶意的请求会故意查询不存在的key,请求量很大，就会对后端系统形成很大的压力。这就叫作缓存穿透。

 

如何避免？

1：对查询结果为空的状况也进行缓存，这样，再次访问时，缓存层会直接返回空值。缓存时间设置短一点，或者该key对应的数据insert了以后清理缓存。

2：对必定不存在的key进行过滤。具体请看布隆过滤器

 

缓存击穿

是针对缓存中没有但数据库有的数据。

场景是，当Key失效后，假如瞬间忽然涌入大量的请求，来请求同一个Key，这些请求不会命中Redis，都会请求到DB，致使数据库压力过大，甚至扛不住，挂掉。

解决办法

一、设置热点Key，自动检测热点Key，将热点Key的过时时间加大或者设置为永不过时，或者设置为逻辑上永不过时

二、加互斥锁。当发现没有命中Redis，去查数据库的时候，在执行更新缓存的操做上加锁，当一个线程访问时，其它线程等待，这个线程访问事后，缓存中的数据会被重建，这样其余线程就能够从缓存中取值。

 

缓存雪崩

是指大量Key同时失效，对这些Key的请求又会打到DB上，一样会致使数据库压力过大甚至挂掉。

解决办法

1）让Key的失效时间分散开，能够在统一的失效时间上再加一个随机值，或者使用更高级的算法分散失效时间。

2）构建多个redis实例，个别节点挂了还有别的能够用。

3）多级缓存：好比增长本地缓存，减少redis压力。

4）对存储层增长限流措施，当请求超出限制，提供降级服务（通常就是返回错误便可）

 

单线程的redis为何这么快
(一)纯内存操做
(二)单线程操做，避免了频繁的上下文切换
(三)采用了非阻塞I/O多路复用机制

（其实就是历史遗留问题，非要吹的这么好。。。）

 

redis采用的删除策略
 

redis采用的是按期删除+惰性删除策略。

为何不用定时删除策略?

定时删除,用一个定时器来负责监视key,过时则自动删除。虽然内存及时释放，可是十分消耗CPU资源。在大并发请求下，CPU要将时间应用在处理请求，而不是删除key,所以没有采用这一策略.

按期删除+惰性删除是如何工做的呢?

按期删除，redis默认每一个100ms检查，是否有过时的key,有过时key则删除。须要说明的是，redis不是每一个100ms将全部的key检查一次，而是随机抽取进行检查(若是每隔100ms,所有key进行检查，redis岂不是卡死)。所以，若是只采用按期删除策略，会致使不少key到时间没有删除。
因而，惰性删除派上用场。也就是说在你获取某个key的时候，redis会检查一下，这个key若是设置了过时时间那么是否过时了？若是过时了此时就会删除。

 

为何Redis的操做是原子性的，怎么保证原子性的？

对于Redis而言，命令的原子性指的是：一个操做的不能够再分，操做要么执行，要么不执行。
Redis的操做之因此是原子性的，是由于Redis是单线程的。
Redis自己提供的全部API都是原子操做，Redis中的事务实际上是要保证批量操做的原子性。
多个命令在并发中也是原子性的吗？
不必定， 将get和set改为单命令操做，incr 。使用Redis的事务，或者使用Redis+Lua==的方式实现.
 

消息队列
不要使用redis去作消息队列，这不是redis的设计目标。但实在太多人使用redis去作去消息队列，redis的做者看不下去。

kafka才好用原文连接：https://blog.csdn.net/hebtu666/article/details/102580321