java面试题整理《redis篇》三

Redis 的持久化机制是什么？各自的优缺点？
Redis是一个基于内存的数据库，当redis服务器重启，获取电脑重启，数据会丢失，我们可以将redis内存中的数据持久化保存到硬盘的文件中。目前Redis支持的存储机制有RDB和AOF。

RDB机制（Redis Database）
RDB是Redis默认的持久化方式，他每隔一段时间会把当前进程数据生成快照保存到硬盘的过程，对应产生的数据文件为dump.rdb。通过配置文件中的save参数来定义快照的周期。

优点：

只有一个文件 dump.rdb，方便持久化。
容灾性好，一个文件可以保存到安全的磁盘，方便备份。
性能最大化，fork 子进程来完成写操作，让主进程继续处理命令，所以是 IO 最大化。使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 redis 的高性能
相对于数据集大时，比 AOF 的启动效率更高。
缺点：

数据安全性低。RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候)
由于RDB是通过fork子进程来协助完成数据化工作的，因此，如果数据集较大，可能导致整个服务器停止服务几百毫秒，甚至1秒钟。
相关操作：
父进程执行fork操作创建子进程
子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原来文件进行原子替换。
进程发送信号给父进程表示完成，父进程更新统计信息。

AOF持久化方式： （Append Only File）
AOF是指所有的命令行记录以 redis 命令请求协议的格式完全持久化存储，保存为 aof 日志文件，重启时重新执行AOF文件中的命令来恢复文件。（aof默认是文件无限追加，大小会不断扩张，如果是文件过大就需要写很久）

开启AOF需要我们设置配置：appendonly yes，默认不打开。文件名通过appendfilename配置设置，默认文件名为appendonly.aof。

优点：

数据安全，aof 持久化可以配置 appendfsync 属性（每秒同步、没修改同步、不同步），比如always：每进行一次命令操作就记录到 aof 文件中一次。
通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题。
AOF 机制的 rewrite 模式。AOF 文件没被 rewrite 之前（文件过大时会对命令 进行合并重写），可以删除其中的某些命令（比如误操作的 flushall）)
缺点：

AOF 文件比 RDB 文件大，且恢复速度慢。
数据集大的时候，比 rdb 启动效率低。
执行流程：
命令写入（append）：所有命令会追加到aof_buf（缓冲区）中。
文件同步（sync）：AOF缓冲区根据对应的策略向硬盘做同步操作。
文件重写（rewrite）：随着文件越来越大，需要定期对AOF文件进行重写，达到压缩目的。
重启加载（load）：重启时，可以加载AOF文件进行数据恢复

一般来说， 会同时使用两种持久化功能。在这种情况下，当 Redis 重启的时候会优先载入AOF文件来恢复原始的数据，AOF文件比RDB更新频率高，保存数据集比较完整，但是文件比较大，性能没有AOF好（快照备份简单、恢复更快）。

Redis持久化数据和缓存怎么做扩容？
如果Redis被当做缓存使用，使用一致性哈希实现动态扩容缩容。如果Redis被当做一个持久化存储使用，必须使用固定的keys-to-nodes映射关系，节点的数量一旦确定不能变化。否则的话，必须使用可以在运行时进行数据再平衡的一套系统，而当前只有Redis集群可以做到这样。

分布式Redis为了防止扩容，一般一开始就会启动较多实例：
一开始就多设置几个Redis实例，例如32或者64个实例，对大多数用户来说这操作起来可能比较麻烦，但是从长久来看做这点牺牲是值得的。这样的话，当你的数据不断增长，需要更多的Redis服务器时，你需要做的就是仅仅将Redis实例从一台服务迁移到另外一台服务器而已。一旦你添加了另一台服务器，你需要将你一半的Redis实例从第一台机器迁移到第二台机器。