Redis常问的知识点

什么是Redis？

Redis是一个高性能的key-value数据库，它是完全开源免费的，而且Redis是一个NOSQL类型数据库，是为了解决高并发、高扩展，大数据存储等一系列的问题而产生的数据库解决方案，是一个非关系型的数据库。

Redis的特点？

Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作，所以Redis的性能非常出色，每秒可以处理超过10万次读写操作，是已知性能最快的Key-Value型DB。
Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存多种数据结构，此外单个value的最大限制是1GB，不像memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能，比方说用它的List来做FIFO双向链表，实现一个轻量级的高性能消息队列服务，用它的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置EXPIRE时间，因此也可以被当作一个功能加强版的memcached来用。
Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。

Redis的高并发和快速原因？

1. Redis是基于内存的，内存的读写速度非常快；
2. Redis是单线程的，省去了很多上下文切换线程的时间；
3. Redis使用了多路复用技术，可以处理并发的连接。非阻塞IO，内部实现采用epoll，采用了epoll+自己实现的简单的事件框架。epoll中的读、写、关闭以及连接都转化成了事件，然后利用epoll的多路复用特性，绝不在IO上浪费一点时间。

为什么Redis是单线程的？

1. 官方答案
   因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了。
2. 性能指标
   关于redis的性能，官方网站也有，普通笔记本轻松处理每秒几十万的请求。
3. 详细原因
   a）不需要各种锁的性能消耗，Redis的数据结构并不全是简单的key-value，还有list、hash等复杂的结构，这些结构有可能会进行很细粒度的操作，比如在很长的列表后面添加一个元素，在hash当中添加或者删除一个对象，这些操作可能就需要加非常多的锁，导致的结果是同步开销大大增加。总之，在单线程的情况下，就不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗。
   b）单线程多进程集群方案，单线程的威力实际上非常强大，每核心效率也非常高，多线程自然是可以比单线程有更高的性能上限，但是在今天的计算环境中，即使是单机多线程的上限也往往不能满足需要了，需要进一步摸索的是多服务器集群化的方案，这些方案中多线程的技术照样是用不上的。所以单线程、多进程的集群不失为一个时髦的解决方案。
   c）CPU消耗，采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗CPU。但是如果CPU成为Redis瓶颈，或者不想让服务器其他CUP核闲置，那怎么办？这时我们可以考虑多起几个Redis进程，Redis是key-value数据库，不是关系数据库，数据之间没有约束，只要客户端分清哪些key放在哪个Redis进程上就可以了。

Redis单线程的优劣势？

1. 单进程单线程优势
   a）代码更清晰，处理逻辑更简单；
   b）不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；
   c）不存在多进程或者多线程导致的切换而消耗CPU。
2. 单进程单线程弊端
   无法发挥多核CPU性能，不过可以通过在单机开多个Redis实例来完善。

Redis高并发总结？

1. Redis是纯内存数据库，一般都是简单的存取操作，线程占用的时间很多，时间的花费主要集中在IO上，所以读取速度快；
2. Redis使用的是非阻塞IO，IO多路复用，使用了单线程来轮询描述符，将数据库的开、关、读、写都转换成了事件，减少了线程切换时上下文的切换和竞争；
3. Redis采用了单线程的模型，保证了每个操作的原子性，也减少了线程的上下文切换和竞争；
4. Redis全程使用hash结构，读取速度快，还有一些特殊的数据结构，对数据存储进行了优化，如压缩表，对短数据进行压缩存储，再如跳表，使用有序的数据结构加快读取的速度；
5. Redis采用自己实现的事件分离器，效率比较高，内部采用非阻塞的执行方式，吞吐能力比较大。

IO多路复用技术？

Redis采用网络IO多路复用技术来保证在多连接的时候系统的高吞吐量。
“多路”指的是多个socket连接（网络连接），“复用”指的是复用一个线程。多路复用主要有三种技术：select、poll、epoll。其中epoll是最新的也是目前最好的多路复用技术。
采用多路I/O复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络IO的时间消耗），且Redis在内存中操作数据的速度非常快（内存内的操作不会成为这里的性能瓶颈），主要以上两点造就了Redis具有很高的吞吐量。、

如何设置有效时间？

可以对一个已经带有有效时间的key执行EXPIRE命令，新指定的生存时间会取代旧的生存时间。过期时间的精度已经被控制在1ms之内，主键失效的时间复杂度是O(1)。
EXPIRE和TTL命令搭配使用，TTL可以查看key的当前生存时间。EXPIRE设置成功返回1，当key不存在或者不能为key设置生存时间时返回0。
最大缓存配置在Redis中，允许用户设置的最大使用内存大小（server.maxmemory）默认值为0，没有指定最大缓存，如果有新的数据添加，超过最大内存时会使Redis崩溃，所以一定要设置。
Redis内存数据集大小上升到一定大小的时候，就会实行数据淘汰策略。

Redis提供了6种数据淘汰策略：

1. volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰；
2. volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰；
3. volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰；
4. allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰；
5. allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰；
6. no-enviction（驱逐）：禁止驱逐数据。
   注意这里的6种机制，volatile和allkeys规定了是对已设置过期时间的数据集淘汰数据还是从全部数据集淘汰数据，后面的lru、ttl以及random是三种不同的淘汰策略，再加上一种no-enviction永不回收的策略。

使用策略规则：
如果数据呈现幂律分布，也就是一部分数据访问频率高，一部分数据访问频率低，则使用allkeys-lru；如果数据呈现平等分布，也就是所有的数据访问频率都相同，则使用allkeys-random。

三种数据淘汰策略：
ttl和random比较容易理解，实现也会比较简单。主要是lru最近最少使用淘汰策略，设计上会对key按有效时间排序，然后取最先失效的key进行淘汰。

为什么Redis需要把所有数据放到内存中?

Redis为了达到最快的读写速度将数据都读到内存中，并通过异步的方式将数据写入磁盘。所以Redis具有快速和数据持久化的特征。如果不将数据放在内存中，磁盘I/O速度会严重影响Redis的性能。在内存越来越便宜的今天，Redis将会越来越受欢迎。
如果设置了最大使用的内存，则数据已有记录数达到内存限值后不能继续插入新值。

假如Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如果将它们全部找出来？

使用keys指令可以扫出指定模式的key列表。
如果这个Redis正在给线上的业务提供服务，那使用keys指令会有什么问题？
Redis是单线程的，keys指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。这个时候可以使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用keys指令长。

如果有大量的key需要设置同一时间过期，一般需要注意什么？

如果大量的key过期时间设置的过于集中，到过期的那个时间点，Redis可能会出现短暂的卡顿现象。一般需要在时间上加一个随机值，使得过期时间分散一些。

Redis如何做持久化？

BGSAVE做镜像全量持久化，AOF做增量持久化。因为BGSAVE会耗费较长时间，不够实时，在停机的时候会导致大量丢失数据，所以需要AOF来配合使用。在Redis实例重启时，会使用BGSAVE持久化文件重新构建内存，再使用AOF重放近期的操作指令来实现完整恢复重启之前的状态。
机器突然断电时取决于AOF日志的sync属性配置，如果不要求性能，在每条写指令时都sync一下磁盘，就不会丢失数据。但是在高性能的要求下每次都sync是不现实的，一般都使用定时sync，比如1s/1次，这个时候最多就会丢失1s的数据。
BGSAVE的原理是fork和cow，fork是指Redis通过创建子进程来进行BGSAVE操作，cow指的是"copy on write"，子进程创建后，父子进程共享数据段，父进程继续提供读写服务，写脏的页面数据会逐渐和子进程分离开来。

Pipeline有什么好处，为什么要用pipeline？

可以将多次IO往返的时间缩减为一次，前提是pipeline执行的指令之间没有因果相关性。使用redis-benchmark进行压测的时候可以发现影响Redis的QPS峰值的一个重要因素是pipeline批次指令的数目。

Redis的同步机制了解么？

Redis可以使用主从同步、从从同步。第一次同步时，主节点做一次BGSAVE，并同时将后续修改操作记录到内存buffer，待完成后将rdb文件全量同步到复制节点，复制节点接受完成后将rdb镜像加载到内存。加载完成后，再通知主节点将期间修改的操作记录同步到复制节点进行重放就完成了同步过程。

Lua脚本

Redis从2.6版本开始引入使用Lua编程语言进行的服务器端脚本编程功能，这个功能可以让用户直接在Redis内部执行各种操作，从而达到简化代码并提高性能的作用。
通过使用Lua对Redis进行脚本编程，我们可以避免一些减慢开发速度或者导致性能下降的常见陷阱。
SCRIPT LOAD：可以将脚本载入Redis，这个命令接受一个字符串格式的Lua脚本为参数，它会把脚本存储起来等待之后使用，然后返回被存储脚本的SHA1校验和；
EVALSHA：可以调用之前存储的脚本，这个命令接收脚本的SHA1校验和以及脚本所需的全部参数；
EVAL：可以直接执行指定的脚本，这个命令接收脚本字符串以及脚本所需的全部参数。这个命令除了会执行脚本之外，还会将被执行的脚本缓存到Redis服务器里面。
Lua脚本跟单个Redis命令以及MULTI/EXEC事务一样，都是原子操作，已经对结构进行了修改的Lua脚本将无法被中断：
不执行任何写命令的只读脚本：可以在脚本的运行时间超过"lua-time-limit"选项指定的时间之后，执行SCRIPT KILL命令杀死正在运行的脚本;
有写命令的脚本：杀死脚本将导致Redis存储的数据进入一种不一致的状态。

持久化选项简介

Redis提供了两种不同的持久化方法来将数据存储到硬盘里面。
RDB(redis database)：快照，可以将某一时刻的所有数据都写入硬盘里面。（保存的是数据本身）
AOF(append only file)：只追加文件，会在执行命令时，将被执行的写命令复制到硬盘里面。（保存的是数据的变更记录）
两种持久化方法既可以同时使用，又可以单独使用，在某些情况下甚至可以两种方法都不使用，具体选择哪种持久化方法需要根据数据以及应用来决定。
将内存中的数据存储到硬盘的一个主要原因是为了在之后重用数据，或者是为了防止系统故障而将数据备份到一个远程位置。另外，存储在Redis里面的数据有可能是经过长时间计算得出的，或者是有程序正在使用Redis存储的数据进行计算，所以用户会希望自己可以将这些数据存储起来以便之后使用，这样就不必再重新计算了。对于一些Redis应用来说，“计算”可能只是简单地将另一个数据库的数据复制到Redis里面，但对于另外一些Redis应用来说，Redis存储的数据可能是根据数十亿行日志进行聚合分析得到的结果。

快照持久化
Redis可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。在创建快照之后，用户可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本，还可以将快照留在原地以便重启服务器时使用。
如果新的快照文件创建完成之前，Redis 、系统或者硬件这三者之中的任意一个崩溃了，那么Redis将丢失最近一次成功创建快照之后写入的所有数据。快照持久化只适用于那些即使丢失一部分数据也不会造成问题的程序，而不接受数据损失的程序可以考虑使用AOF持久化。

创建快照的方法：
1. 客户端可以通过向Redis发送BGSAVE命令来主动创建快照。对于支持BGSAVE命令的平台（除了 Windows 平台）来说，Redis会调用fork来创建一个子进程，然后子进程负责将快照写入硬盘，而父进程则继续处理命令请求；
2. 客户端可以通过向Redis发送SAVE命令来主动创建快照，接到SAVE命令的Redis服务器在快照创建完毕之前不会响应任何命令，SAVE命令并不常用，我们通常只会在没有足够内存去执行BGSAVE命令的情况下，又或者即使等待持久化操作执行完毕也无所谓的情况下，才会使用这个命令；
3. 如果用户设置了save配置选项，比如"save 60 10000" ，那么从Redis最近一次创建快照之后开始算起，当“60秒之内有10000次写入”这个条件被满足时，Redis就会自动触发BGSAVE命令。如果用户设置了多个save配置选项，那么当任意一个save配置选项所设置的条件被满足时，Redis就会触发一次BGSAVE命令；
4. 当Redis通过SHUTDOWN命令接收到关闭服务器的请求时，或者接收到标准TERM信号时，会执行一个SAVE命令，阻塞所有客户端，不再执行客户端发送的任何命令，并在SAVE命令执行完毕之后关闭服务器；
5. 当一个Redis服务器连接另一个Redis服务器，并向对方发送SYNC命令来开始一次复制操作的时候，如果主服务器目前没有在执行BGSAVE操作，或者并非刚刚执行完BGSAVE操作，那么主服务器就会执行BGSAVE命令。

不同场景下的使用:
1. 个人开发：主要考虑尽可能地降低快照持久化带来的资源消耗，如果你打算在生产服务器中使用快照持久化并存储大量数据，那么你的开发服务器最好能够运行在于生产服务器相同或者相似的硬件上面，并在这两个服务器上使用相同的save选项、存储相似的数据集并处理相近的负载量。把开发环境设置得尽量贴近生产环境，有助于判断快照是否生成得过于频繁或者过于稀少（过于频繁会浪费资源，而过于稀少则带有丢失大量数据的隐患）；
2. 对日志进行聚合计算：主要考虑如果Redis因为崩溃而未能成功创建新的快照，那么我们能承受丢失多长时间以内产生的新数据。还需要设计如何恢复被中断的聚合计算，可以记录每次处理的日志文件名及偏移量，恢复时按升序从记录处开始处理;
3. 大数据：当Redis存储的数据量了达到数十个GB 时，执行BGSAVE可能会导致系统长时间地停顿，也可能引发系统大量地使用虚拟内存，从而导致Redis的性能降低至无法使用的程度。 可以考虑手动发送 BGSAVE或者SAVE来进行持久化，避免自动执行而造成停顿。

RDB 的优点：
1. 非常紧凑；
2. 适合用于灾难恢复；
3. 可以最大化Redis的性能；
4. 恢复大数据集时的速度比AOF的恢复速度要快。

RDB 的缺点：
1. 宕机时丢失数据可能较多；
2. 每次持久化时都要fork()一个子进程，当数据集比较庞大时可能非常耗时。

# 持久化触发条件：seconds秒内至少有changes个键被更改
# save <seconds> <changes> 
# 
# 默认配置以下三个触发持久化的条件
# 【注】注释掉所有save的配置，就不会开启快照持久化
#
# 900 秒(15 分钟)内至少有1个键被更改
# 300 秒（5 分钟）内至少有10个键被更改
# 60 秒（1 分钟）内至少有10000个键被更改
save 900 1
save 300 10
save 60 10000

# 如果快照持久化开启
# yes：后台持久化操作失败时，Redis就会停止接受更新操作（默认 yes）
# no ：后台持久化操作失败时，Redis仍然可以继续正常工作
stop-writes-on-bgsave-error yes

# 在进行镜像备份时，是否进行压缩
# yes：压缩，会有更多cpu消耗，时间会更长（默认 yes）
# no ：不压缩，需要更多磁盘空间
rdbcompression yes

# 数据库文件的文件名
dbfilename dump.rdb

# 工作目录，数据库文件的位置
# AOF（append only file）也会在此目录创建 
dir ./

AOF 持久化
简单来说，AOF持久化会将被执行的写命令写到AOF文件的末尾，以此来记录数据发生的变化。因此，Redis只要从头到尾重新执行一次AOF文件包含的所有写命令，就可以恢复AOF文件所记录的数据集。

重写 AOF 文件：
Redis会不断地将被执行的写命令记录到AOF文件里面，AOF文件会不断增大，可能会用完硬盘的所有可用空间，重启之后还原操作也可能执行很长时间。
为了解决AOF文件不断增大的问题，用户可以向Redis发送BGREWRITEAOF命令，这个命令会通过移除 AOF文件中冗余命令来重写AOF文件，使AOF文件变得尽可能地小。BGREWRITEAOF的工作原理和BGSAVE创建快照的工作原理非常相似：Redis会创建一个子进程， 然后由子进程负责对AOF文件进行重写。
重写AOF文件是从数据集中读取键当前的值，然后用一条命令去记录键值对，代替之前记录该键值对的多个命令，最终生产一个新的AOF文件，这个文件包含重建当前数据集所需的最少命令。

AOF的优点：
1. AOF文件只追加，所以写入时不需要进行seek；
2. AOF文件过大时，后台会自动对AOF文件进行重写；
3. 有序地保存了数据库执行的所有写入操作，易读懂，也能轻松分析文件。

AOF的缺点：
1. 相同数据集时，AOF文件的体积通常大于RDB文件的体积；
2. 根据所使用的fsync策略AOF的速度可能会慢于RDB；
3. 个别命令（例如：BRPOPLPUSH source destination timeout）会导致AOF文件在重新载入时，无法将数据集恢复成保存时的原样。

# AOF 持久化是否开启
# yes：开启AOF持久化，Redis在启动时会载入AOF，而忽略快照持久化文件
# no ：不开启AOF持久化（默认不开启）
appendonly no

# AOF 文件名（默认为 appendonly.aof）
appendfilename "appendonly.aof"

# Redis 支持三种不同的回写模式
# always  ：每次写操作都调用 fsync()，立刻写入AOF文件。非常慢但是很安全。
# everysec：每秒调用一次 fsync()。折衷方案。（默认为 everysec）
# no      ：不调用 fsync()，等待操作系统刷数据。很快。
# appendfsync always
appendfsync everysec
# appendfsync no

# 如果有延迟问题就将该选项设置为yes
# 否则就保持no，这是最安全的方式
no-appendfsync-on-rewrite no

# 自动重写AOF文件，若百分比设置为0，则表示禁用自动重写AOF文件
# 如果当前AOF文件大小以及比上次AOF文件大小大了指定的百分比，则会重写AOF文件
# 同时需要指定AOF文件重写的最小大小，以避免百分比过小而频繁重写AOF文件
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb