3. redis 面试

img

Redis采用的是基于内存的采用的是单进程单线程模型的 KV 数据库，由C语言编写，官方提供的数据是可以达到100000+的QPS（每秒内查询次数）。

  • 完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。它的数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)；

  • 数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的；

  • 采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；

  • 使用多路I/O复用模型，非阻塞IO，将速度优势发挥到最大，也提供了较简单的计算功能 ；

  • 使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；

  • Redis提供了事务的功能，可以保证一串 命令的原子性，中间不会被任何操作打断

Redis虽然是单线程的，但是可以通过开多个Redis实例利用多核机器

3.1. Redis持久化数据和缓存怎么做扩容？

  • 如果Redis被当做缓存使用，使用一致性哈希实现动态扩容缩容。

    shared一致性哈希采用以下方案：

    1. Redis服务器节点划分：将每台服务器节点采用hash算法划分为160个虚拟节点(可以配置划分权重)

    2. 将划分虚拟节点采用TreeMap存储

    3. 对每个Redis服务器的物理连接采用LinkedHashMap存储

    4. 对Key or KeyTag 采用同样的hash算法，然后从TreeMap获取大于等于键hash值得节点，取最邻近节点存储；当key的hash值大于虚拟节点hash值得最大值时，存入第一个虚拟节点

    sharded采用的hash算法：MD5 和 MurmurHash两种；默认采用64位的MurmurHash算法；有兴趣的可以研究下，MurmurHash是一种高效，低碰撞的hash算法；参考地址：

    http://blog.csdn.net/yfkiss/article/details/7337382

    https://sites.google.com/site/murmurhash/

  • 如果Redis被当做一个持久化存储使用，必须使用固定的keys-to-nodes映射关系，节点的数量一旦确定不能变化。否则的话(即Redis节点需要动态变化的情况），必须使用可以在运行时进行数据再平衡的一套系统，而当前只有Redis集群可以做到这样。

3.2. redis的一些其他特点

  • Redis是单进程单线程的 redis利用队列技术将并发访问变为串行访问，消除了传统数据库串行控制的开销

  • 读写分离模型 通过增加Slave DB的数量，读的性能可以线性增长。为了避免Master DB的单点故障，集群一般都会采用两台Master DB做双机热备，所以整个集群的读和写的可用性都非常高。 读写分离架构的缺陷在于，不管是Master还是Slave，每个节点都必须保存完整的数据，如果在数据量很大的情况下，集群的扩展能力还是受限于单个节点的存储能力，而且对于Write-intensive类型的应用，读写分离架构并不适合

  • 数据分片模型 为了解决读写分离模型的缺陷，可以将数据分片模型应用进来。 可以将每个节点看成都是独立的master，然后通过业务实现数据分片。 结合上面两种模型，可以将每个master设计成由一个master和多个slave组成的模型。

  • Redis的回收策略

    • 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（驱逐）：禁止驱逐数据

​ 注意这里的6种机制，volatile和allkeys规定了是对已设置过期时间的数据集淘汰数据还是从全部数据集淘汰数 据，后面的lru、ttl以及random是三种不同的淘汰策略，再加上一种no-enviction永不回收的策略。 ​ 使用策略规则： ​ 如果数据呈现幂律分布，也就是一部分数据访问频率高，一部分数据访问频率低，则使用allkeys-lru ​ 如果数据呈现平等分布，也就是所有的数据访问频率都相同，则使用allkeys-random

Redis虽然是一种内存型数据库，一旦服务器进程退出，数据库的数据就会丢失，为了解决这个问题Redis提供了两种持久化的方案，将内存中的数据保存到磁盘中，避免数据的丢失。

3.3. RDB持久化

redis提供了RDB持久化的功能，这个功能可以将redis在内存中的的状态保存到硬盘中，它可以手动执行，也可以再redis.conf中配置，定期执行。

RDB持久化产生的RDB文件是一个经过压缩的二进制文件，这个文件被保存在硬盘中，redis可以通过这个文件还原数据库当时的状态。

3.3.1. RDB的创建与载入

RDB文件可以通过两个命令来生成：

  • SAVE：阻塞redis的服务器进程，直到RDB文件被创建完毕。

  • BGSAVE：派生(fork)一个子进程来创建新的RDB文件，记录接收到BGSAVE当时的数据库状态，父进程继续处理接收到的命令，子进程完成文件的创建之后，会发送信号给父进程，而与此同时，父进程处理命令的同时，通过轮询来接收子进程的信号。

而RDB文件的载入一般情况是自动的，redis服务器启动的时候，redis服务器再启动的时候如果检测到RDB文件的存在，那么redis会自动载入这个文件。

如果服务器开启了AOF持久化，那么服务器会优先使用AOF文件来还原数据库状态。

RDB是通过保存键值对来记录数据库状态的，采用copy on write的模式，每次都是全量的备份。

3.3.2. 自动保存间隔

BGSAVE可以在不阻塞主进程的情况下完成数据的备份。可以通过redis.conf中设置多个自动保存条件，只要有一个条件被满足，服务器就会执行BGSAVE命令。

# 以下配置表示的条件：
# 服务器在900秒之内被修改了1次
save 900 1
# 服务器在300秒之内被修改了10次
save 300 10
# 服务器在60秒之内被修改了10000次
save 60 10000

3.4. AOF持久化

AOF持久化（Append-Only-File），与RDB持久化不同，AOF持久化是通过保存Redis服务器锁执行的写状态来记录数据库的。

具体来说，RDB持久化相当于备份数据库状态，而AOF持久化是备份数据库接收到的命令，所有被写入AOF的命令都是以redis的协议格式来保存的。

在AOF持久化的文件中，数据库会记录下所有变更数据库状态的命令，除了指定数据库的select命令，其他的命令都是来自client的，这些命令会以追加(append)的形式保存到文件中。

服务器配置中有一项appendfsync，这个配置会影响服务器多久完成一次命令的记录：

  • always：将缓存区的内容总是即时写到AOF文件中。

  • everysec：将缓存区的内容每隔一秒写入AOF文件中。

  • no ：写入AOF文件中的操作由操作系统决定，一般而言为了提高效率，操作系统会等待缓存区被填满，才会开始同步数据到磁盘。

redis默认实用的是everysec。

redis在载入AOF文件的时候，会创建一个虚拟的client，把AOF中每一条命令都执行一遍，最终还原回数据库的状态，它的载入也是自动的。在RDB和AOF备份文件都有的情况下，redis会优先载入AOF备份文件

AOF文件可能会随着服务器运行的时间越来越大，可以利用AOF重写的功能，来控制AOF文件的大小。AOF重写功能会首先读取数据库中现有的键值对状态，然后根据类型使用一条命令来替代前的键值对多条命令。

AOF重写功能有大量写入操作，所以redis才用子进程来处理AOF重写。这里带来一个新的问题，由于处理重新的是子进程，这样意味着如果主线程的数据在此时被修改，备份的数据和主库的数据将会有不一致的情况发生。因此redis还设置了一个AOF重写缓冲区，这个缓冲区在子进程被创建开始之后开始使用，这个期间，所有的命令会被存两份，一份在AOF缓存空间，一份在AOF重写缓冲区，当AOF重写完成之后，子进程发送信号给主进程，通知主进程将AOF重写缓冲区的内容添加到AOF文件中。

3.4.1. 相关配置

#AOF 和 RDB 持久化方式可以同时启动并且无冲突。  
#如果AOF开启，启动redis时会加载aof文件，这些文件能够提供更好的保证。 
appendonly yes

# 只增文件的文件名称。（默认是appendonly.aof）  
# appendfilename appendonly.aof 
#redis支持三种不同的写入方式：  
#  
# no:不调用，之等待操作系统来清空缓冲区当操作系统要输出数据时。很快。  
# always: 每次更新数据都写入仅增日志文件。慢，但是最安全。
# everysec: 每秒调用一次。折中。
appendfsync everysec  

# 设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入.官方文档建议如果你有特殊的情况可以配置为'yes'。但是配置为'no'是最为安全的选择。
no-appendfsync-on-rewrite no  

# 自动重写只增文件。  
# redis可以自动盲从的调用‘BGREWRITEAOF’来重写日志文件，如果日志文件增长了指定的百分比。  
# 当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100  
# 当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
auto-aof-rewrite-min-size 64mb

3.5. 对比

  • AOF更安全，可将数据及时同步到文件中，但需要较多的磁盘IO，AOF文件尺寸较大，文件内容恢复相对较慢， 也更完整。

  • RDB持久化，安全性较差，它是正常时期数据备份及 master-slave数据同步的最佳手段，文件尺寸较小，恢复数度较快。

作者：whthomas 链接：https://www.jianshu.com/p/bedec93e5a7b 来源：简书 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。