python技术面试题(四)
1.redis持久化
众所周知，redis是内存型的存储数据库。效率高的同时，也有一个弊端不可忽视，那就是数据安全问题。此处安全指的是数据丢失，并非其他。我们将数据都存储在内存中，如果发生宕机等意外情况导致redis重启，那么内存中的数据会全部丢失，多么可怕的一件事。那么我们怎么解决呢？答案就是数据的持久化。
数据的持久化有两种方式：RDB和AOF两种方式。一开始你会觉得两个名字很难记，其实了解过你就会发现其实这两种方式都是以相关数据存储文件的后缀名命名的。
1.1RDB
首先说一下RDB方式。RDB是将内存中所有的数据都持久化到硬盘中，这个过程还有一个名词，那就是『快照』。Redis默认将我们的数据保存在当前进程目录的 dump.rdb文件中，看一下后缀名，再看一下这个方式名，是不是发现了什么呢？了解完之后，要关注的就是怎么实现的问题的了。
redis启动的时候是会自动读取RDB快照文件的，这也 就是为什么RDB可以解决数据的持久化。
方式一：SAVE和BGSAVE命令
这种方式是让我们手动的进行快照操作。他俩的区别就是SAVE命令快照，会阻塞后来客户端的请求；而BGSAVE命令则是异步的方式进行快照的。区别显而易见，SAVE命令会打断正在进行的操作，如果数据超多，这是一种损失，所以必须减少其使用，如果必须使用，那么可以选在访问量极少的时间段。BGSAVE则可以一边接受客户端请求，一边快照，不会对网站造成什么损失。
方式二：自己配置快照条件
# 900的单位是s，1是被更改的键的个数。这句命令的意思就是，900s内被更改的键的个数大于1的时候，自动进行快照操作。 save 900 1 # 指定快照文件的文件名，这个就不要写其他的了 dbfilename dump.rdb # 指定快照文件存储路径 dir ./
配置文件在redis.conf这个文件中。
方式三：执行flushall命令
这个命令进行快照操作有一个前提，那就是我们像方式二中配置了快照的设置。当我们使用了 flushall这个命令，Redis会清除数据库中所有的数据，而且会执行一次快照操作。
如果没有设置save，是不会进行快照操作的！！！！
1.1.1快照过程
在redis执行快照的时候，其实先使用了 fork函数。这个函数执行的时候有个特点，就是我们我们备份数据的时候，如果又有数据写入，后面的数据是不会备份的。意思就是我们执行快照的时候，其实保存的是执行 fork函数那一刻的所有数据。然后父进程继续处理客户端的相关请求，子进程将要保存的数据写入硬盘的临时文件，只有在子进程将所有的数据写完之后，才会将这个文件替换旧的RDB文件。这样就完成了一次快照操作。
1.2AOF
简单的说一下AOF方式，它不会像RDB方式全量的将数据持久化至硬盘，而是只保存执行过的命令。下次启动的时候，其实就是将所有的命令再执行一遍。下面仍然是最关心的如何实现的问题。
我们需要在配置文件中将 appendonly设置为 yes 。开启之后Redis每执行一条写操作（注意是写入的命令），就会将这个命令记录到 appendonly.aof文件中，看这个名字，是不是同样很熟悉，像不像本小节的标题呢？
在AOF中有一个概念，叫做文件重写。当我们多次设置同一个value的时候，redis中只会有最后一次的设置结果，那么前几次的操作，就完全没有必要记录下来再次执行了，会严重影响效率，所以就涉及到了AOF重写。重写就是将没用的命令删除的一个过程。
我们可以让Redis自动进行重写操作，那就是现在配置文件中进行如下设置：
# 目前的AOF文件的大小超过上一次重写时的AOF文件的百分之多少时再次进行重写，如果之前没有重写过，则以启动时AOF文件大小为依据。 auto-aof-rewrite-percentage 100 # 当AOF文件的大小大于64MB时才进行重写，因为如果AOF文件本来就很小时，有几个无效的命令也是无伤大雅的事情。 auto-aof-rewrite-min-size 64mb
所有的东西都介绍完了，我们当然要讲一下如何将数据同步到硬盘中。
AOF文件我们可以设置同步到硬盘的时间，以减少数据的丢失。
# 实时的写入硬盘 appendfsync always # 每秒写入一次 appendfsync everysec # 不主动写入 appendfsync no
1.3重要
重启服务的时候一定要加上配置参数：
redis-server <redis.conf文件的路径>
参考文献：
