天下无难试之Redis面试刁难大全

大全"/>

天下无难试之Redis面试刁难大全

2019独角兽企业重金招聘Python工程师标准>>>

Redis有哪些数据结构？

字符串String、字典Hash、列表List、集合Set、有序集合SortedSet。

如果你是Redis中高级用户，还需要加上下面几种数据结构HyperLogLog、Geo、Pub/Sub。

如果你说还玩过Redis Module，像BloomFilter，RedisSearch，Redis-ML，面试官得眼睛就开始发亮了。

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

    使用keys指令可以扫出指定模式的key列表。但是redis的单线程的，keys指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。

    这个时候可以使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用keys指令长。

使用Redis做队列：

    异步队列：

        一般使用list结构作为队列，rpush生产消息，lpop消费消息。当lpop没有消息的时候，要适当sleep一会再重试。

        list还有个指令叫blpop，在没有消息的时候，它会阻塞住直到消息到来。

    1:N的消息队列：

        使用pub/sub主题订阅者模式实现，但在消费者下线的情况下，生产的消息会丢失，得使用专业的消息队列如rabbitmq等。

    延时队列：

        使用sortedset，拿时间戳作为score，消息内容作为key调用zadd来生产消息，消费者用zrangebyscore指令获取N秒之前的数据轮询进行处理。

持久化：

    bgsave做镜像全量持久化，aof做增量持久化。

    因为bgsave会耗费较长时间，不够实时，在停机的时候会导致大量丢失数据，所以需要aof来配合使用。在redis实例重启时，会使用bgsave持久化文件重新构建内存，再使用aof重放近期的操作指令来实现完整恢复重启之前的状态。

如果突然机器掉电会怎样？

    取决于aof日志sync属性的配置，如果不要求性能，在每条写指令时都sync一下磁盘，就不会丢失数据。但是在高性能的要求下每次都sync是不现实的，一般都使用定时sync，比如1s1次，这个时候最多就会丢失1s的数据。

bgsave的原理是什么？

    fork和cow。fork是指redis通过创建子进程来进行bgsave操作，cow指的是copy on write，子进程创建后，父子进程共享数据段，父进程继续提供读写服务，写脏的页面数据会逐渐和子进程分离开来。

1.redis调用fork,现在有了子进程和父进程。

2. 父进程继续处理client请求，子进程负责将内存内容写入到临时文件。由于os的写时复制机制（copy on write)父子进程会共享相同的物理页面，当父进程处理写请求时os会为父进程要修改的页面创建副本，而不是写共享的页面。所以子进程的地址空间内的数 据是fork时刻整个数据库的一个快照。

3.当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。

aof 的方式也同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用incr test命令100次，文件中必须保存全部的100条命令，其实有99条都是多余的。因为要恢复数据库的状态其实文件中保存一条set test 100就够了。为了压缩aof的持久化文件。redis提供了bgrewriteaof命令。收到此命令redis将使用与快照类似的方式将内存中的数据 以命令的方式保存到临时文件中，最后替换原来的文件。具体过程如下

1. redis调用fork ，现在有父子两个进程
2. 子进程根据内存中的数据库快照，往临时文件中写入重建数据库状态的命令
3.父进程继续处理client请求，除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。
4.当子进程把快照内容写入已命令方式写到临时文件中后，子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。
5.现在父进程可以使用临时文件替换老的aof文件，并重命名，后面收到的写命令也开始往新的aof文件中追加。

需要注意到是重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似。

Redis的同步机制？

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

redis主从复制：

当用户往Master端写入数据时，通过Redis Sync机制将数据文件发送至Slave，Slave也会执行相同的操作确保数据一致；

redis主从复制特点：

1、同一个Master可以拥有多个Slaves。

2、Master下的Slave还可以接受同一架构中其它slave的链接与同步请求，实现数据的级联复制，即Master->Slave->Slave模式；

3、Master以非阻塞的方式同步数据至slave，这将意味着Master会继续处理一个或多个slave的读写请求；

4、Slave端同步数据也可以修改为非阻塞是的方式，当slave在执行新的同步时，它仍可以用旧的数据信息来提供查询；否则，当slave与master失去联系时，slave会返回一个错误给客户端；

5、主从复制具有可扩展性，即多个slave专门提供只读查询与数据的冗余，Master端专门提供写操作；

6、通过配置禁用Master数据持久化机制，将其数据持久化操作交给Slaves完成，避免在Master中要有独立的进程来完成此操作。

redis主从复制原理：

当启动一个Slave进程后，它会向Master发送一个SYNC Command，请求同步连接。

无论是第一次连接还是重新连接，Master都会启动一个后台进程，将数据快照保存到数据文件中，同时Master会记录所有修改数据的命令并缓存在数据文件中。

后台进程完成缓存操作后，Master就发送数据文件给Slave，Slave端将数据文件保存到硬盘上，然后将其在加载到内存中，接着Master就会所有修改数据的操作，将其发送给Slave端。

若Slave出现故障导致宕机，恢复正常后会自动重新连接，Master收到Slave的连接后，将其完整的数据文件发送给Slave，如果Mater同时收到多个Slave发来的同步请求，Master只会在后台启动一个进程保存数据文件，然后将其发送给所有的Slave，确保Slave正常。

redis事物的了解CAS

　　在Redis中，MULTI/EXEC/DISCARD/WATCH这四个命令是我们实现事务的基石。redis事务的实现特征：
　　　　1). 在事务中的所有命令都将会被串行化的顺序执行，事务执行期间，Redis不会再为其它客户端的请求提供任何服务，从而保证了事物中的所有命令被原子的执行。
　　　　2). 和关系型数据库中的事务相比，在Redis事务中如果有某一条命令执行失败，其后的命令仍然会被继续执行。
　　　　3). 我们可以通过MULTI命令开启一个事务，有关系型数据库开发经验的人可以将其理解为"BEGIN TRANSACTION"语句。在该语句之后执行的命令都将被视为事务之内的操作，最后我们可以通过执行EXEC/DISCARD命令来提交/回滚该事务内的所有操作。这两

　　　　　　个Redis命令可被视为等同于关系型数据库中的COMMIT/ROLLBACK语句。
　　　　4). 在事务开启之前，如果客户端与服务器之间出现通讯故障并导致网络断开，其后所有待执行的语句都将不会被服务器执行。然而如果网络中断事件是发生在客户端执行EXEC命令之后，那么该事务中的所有命令都会被服务器执行。
　　　　5). 当使用Append-Only模式时，Redis会通过调用系统函数write将该事务内的所有写操作在本次调用中全部写入磁盘。然而如果在写入的过程中出现系统崩溃，如电源故障导致的宕机，那么此时也许只有部分数据被写入到磁盘，而另外一部分数据却已经丢失。

　　　　　　Redis服务器会在重新启动时执行一系列必要的一致性检测，一旦发现类似问题，就会立即退出并给出相应的错误提示。此时，我们就要充分利用Redis工具包中提供的redis-check-aof工具，该工具可以帮助我们定位到数据不一致的错误，并将已经写入的部

　　　　　　分数据进行回滚。修复之后我们就可以再次重新启动Redis服务器了。

WATCH命令和基于CAS的乐观锁：　

　　　在Redis的事务中，WATCH命令可用于提供CAS(check-and-set)功能。假设我们通过WATCH命令在事务执行之前监控了多个Keys，倘若在WATCH之后有任何Key的值发生了变化，EXEC命令执行的事务都将被放弃，同时返回Null multi-bulk应答以通知调用者事务

redis持久化的几种方式

1、快照（snapshots）
　　缺省情况情况下，Redis把数据快照存放在磁盘上的二进制文件中，文件名为dump.rdb。你可以配置Redis的持久化策略，例如数据集中每N秒钟有超过M次更新，就将数据写入磁盘；或者你可以手工调用命令SAVE或BGSAVE。
　　工作原理
　　． Redis forks.
　　． 子进程开始将数据写到临时RDB文件中。
　　． 当子进程完成写RDB文件，用新文件替换老文件。
　　． 这种方式可以使Redis使用copy-on-write技术。
2、AOF
　　快照模式并不十分jian壮，当系统停止，或者无意中Redis被kill掉，最后写入Redis的数据就会丢失。这对某些应用也许不是大问题，但对于要求高可靠性的应用来说，
　　Redis就不是一个合适的选择。
　　Append-only文件模式是另一种选择。
　　你可以在配置文件中打开AOF模式
3、虚拟内存方式
　　当你的key很小而value很大时,使用VM的效果会比较好.因为这样节约的内存比较大.
　　当你的key不小时,可以考虑使用一些非常方法将很大的key变成很大的value,比如你可以考虑将key,value组合成一个新的value.
　　vm-max-threads这个参数,可以设置访问swap文件的线程数,设置最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的.可能会造成比较长时间的延迟,但是对数据完整性有很好的保证.

　　自己测试的时候发现用虚拟内存性能也不错。如果数据量很大，可以考虑分布式或者其他数据库

.html

redis 4.0

 Redis 4.0 以前存在的问题：1，节点重启后需要全力拉取数据； 2，发生主从切换后，新的从节点都需要重新与主节点进去全量的数据同步  3，aof数据加载很慢；

           Redis 4.0 引入了两项新的技术来解决了上述问题，Psync2，混合rdb、aof 文件。

           1， Psync 2 ： 解决了从库重启以及发生主从切换之后的全量同步问题。

                之前的版本中，从库重启需要全量同步的原因是从库没有将主节点的runId持久化（runId 是和 节点的nodeId 不同？），所以从节点重启后因为没有了这个runId 所以需要全量同步。新的版本中在RDB文件保存了这个runid，解决了重启节点需要全量同步的问题。

                Redis 4.0 允许多级slave 的存在，即可以有这样的形式   A（主） → B （从） → C（从） → D （从）  （Replication version 2）； 当发生主从切换后，新的主节点可以判断从节点是否满足部分同步的条件： 之前就是从新主节点同步的或者之前和新主节点同步的是同一个master， 其他的条件比如backlog 和offset 的位置和之前的版本一样。                         

          2， Mixed-rdb & aof:  解决aof文件加载慢问题。

                aof相比rdb文件来说恢复数据的速度要慢很多。4.0 以后的aof重写不再是像之前一样将数据以aof 的格式写入到文件中， 而是先写成rdb 的格式 （应该是先做一份全量的rdb，然后存储进文件中去，这样就一定快很多？这个和重写aof 的数据量应该差不多才是）。

redis怎样找到key在内存中的位置

转载于: