Redis的持久化机制
因为Redis是内存数据库，它将自己的数据库状态存储在内存里，所以如果不想办法将存储在内存中的数据库状态保存到磁盘里面，那么一旦服务器进程退出，服务器中的数据库状态也会消失不见。
为了解决这一问题，Redis提出了两种持久化机制，分别是RDB和AOP。
##RDB持久化
RDB持久化既可以手动执行，也可以根据服务器配置选项定期执行，该功能可以将某个时间点上的数据库状态保存到一个RDB文件中。
RDB文件的创建与载入
两个Redis命令可以用于生成RDB文件，一个是SAVE，另一个是BGSAVE
SAVE命令会阻塞Redis服务器的进程，直到RDB文件创建完毕位置，在服务器进程阻塞期间，服务器不能处理任何命令请求。
而BGSAVE命令会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程继续处理命令请求。
RDB文件的载入工作是在服务器启动时自动执行的。
RDB文件载入时的服务器状态
Redis允许用户通过设置服务器配置的save选项，让服务器每隔一段时间自动执行一次BGSAVE命令。
如果向服务器提供如下配置：
save 900 1
save 300 10
save 60 10000
那么只要满足以下三个条件中的任意一个，BGSAVE命令就会被执行：
服务器在900秒之内，对数据库进行了至少1次修改。
服务器在300秒之内，对数据库进行了至少10次修改。
服务器在60秒之内，对数据库进行了至少10000此修改。
除了save选项可以控制RDB的写入之外，服务器状态还维持着一个dirty计数器，以及一个lastsave属性：
dirty计数器记录距离上一次成功执行SAVE命令或者BGSAVE命令之后，服务器对数据库状态进行了多少次修改。
lastsave属性是一个UNIX时间戳，记录了服务器上一次成功执行SAVE命令或者BGSAVE命令的时间。
AOF持服务器托管网久化
AOF持久化功能的实现可以分为命令追加、文件写入、文件同步三个步骤。
命令追加
当AOF被打开时，服务器在执行完一个写命令后，会将该操作追加到AOF缓冲区中。
AOF文件的写入与同步
写命令首先会被保存在AOF缓冲区中（即内存），而这些在内存中的数据是否被写入磁盘，取决于flushAppendOnlyFile函数被调用时所进行的判断。
flushAppendOnlyFile函数的行为由服务器配置的appendfsync选项的值来决定，各个不同值产生的行为如表11-1所示。
| appendfsync选项的值 | flushAppendOnlyFile函数的行为 |
|---|---|
| always | 将AOF缓冲区所有内容写入并同步到AOF文件 |
| everysec | 将AOF缓冲区所有内容写入，每隔一秒就将AOF缓冲区中内容同步到AOF文件 |
| no | 将AOF缓冲区所有内容写入，何时同步至AOF文件由操作系统决定 |
注意：写入与同步不同，写入是指用户调用write函数，此时数据还在内存中，只有当进行同步操作时，数据才真正保存到磁盘中。
AOF文件的载入与数据还原
Redis通过创建一个伪客户端的方法将AOF文件中的数据载入至内存中。AOF文件是一条又一条的增删改操作。
AOF重写
AOF会记录用户对数据的所有操作，大量的操作实际被后续操作覆盖了，没有实际价值。这会导致AOF文件迅速膨胀。为了解决AOF文件体积膨胀的问题，Redis提供了AOF文件重写（rewrite）功能。
AOF重写通常直接保留内存中的数据的创建和插入语句，其中没有删除语句。
AOF重写通常是由子程序执行，这样既可以不阻塞主服务器又可以在不使用锁的情况下完成重写。
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
来OB这么久还没有接触啥金融的SQL，只能发点其他行业的数据库SQL优化案例。 今天拿到手的这个案例SQL传统行业的，很奇葩的SQL，表设计三范式都没弄好。 什么医疗，交通，能源这些传统行业的业务设计，SQL语句最奇葩了，也挺好玩的，有挑战性。 慢SQL： S…
