python不用框架做网站免费logo设计网站推荐
1.AOF
AOF（Append Only File）持久化：以独立日志的方式记录每次写命令，重启时在重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前是已经是Redis持久化的主流方式。
有人就要问了：引入AOF之后，又要写内存，又要写硬盘，还能和之前一样快吗？
实际上影响是不大的，并没有影响到Redis处理请求的速度，原因在于：1.AOF机制并非是直接让工作线程把数据写入到硬盘，而是先写入到一个内存缓冲区，积累到一定的数量后，再统一写入到硬盘（这样大大降低了写硬盘的次数）。
2.硬盘上读写数据，顺序读写是比较快的（但是相对于内存写数据还是比较慢的），随机访问则是比较慢的。AOF每次把新的操作写入到原有文件的末尾，属于顺序读写。
2.AOF的使用
2.1使用AOF
开启AOF功能需要设置配置：appendonly yes，默认不开启。AOF文件名通过appendfilename配置（默认是appendonly.aof）设置。保存目录同RDB持久化方式一致，通过dir配置指定。AOF的工作流程操作：命令写入（append），文件同步（sync），文件重写（rewrite），重启加载（load）。
2.2AOF工作流程
1.所有写入命令会追加到aof_buf（缓冲区）中
2.AOF缓冲区根据对应的策略向硬盘做同步操作
3.随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。
4.当Redis服务器启动时，可以加载AOF文件数据恢复。
2.3命令写入
AOF命令写入的内容直接是文本协议格式，在AOF缓冲区会追加文本内容
Redis选择文本协议的可能原因：文本协议具有较好的兼容性，实现简单，具备可读性。
AOF过程中为什么需要aof_buf这个缓冲区？
AOF文件都直接同步硬盘，性能从内存的读写编程IO读写，必然会下降。先写入到缓冲区可以有效减少IO次数，同时，Redis还可以提供多种缓冲区同步策略，让用户根据自己的需求做出合理的平衡。
2.4文件同步
Redis提供了多种AOF缓冲区同步策略，由参数appendfsync控制。
AOF缓冲区同步文件策略
系统调用write和fsync说明：
write操作会触发延迟写机制（dalatyed write）机制。Linux在内核提供页缓冲区用来提供硬盘IO性能。write操作在写入系统缓冲区立即返回。同步硬盘操作依赖于系统调度机制，例如缓冲区页控件或达到特定时间周期。同步文件之前，如果此时系统故障宕机，缓冲区数据将丢失。
fsync针对单个文件操作，做强制硬盘同步，fsync将阻塞直到数据写入到硬盘中
1.配置为always时候，每次写入都要同步AOF文件，性能很差，在一般的STAT硬盘上，只能支持大约几百TPS写入。除非是非常重要的数据，否则不建议配置。
2.配置为no的时候，由于操作系统不同策略不可控，性能虽然提高了，但是数据丢失风险大增，除非数据重要程度很低，一般不建议配置。
3.配置为everysec（默认配置时），兼顾了数据安全和性能。理论上最多丢失1秒的数据
2.5重写机制
随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入AOF重写机制压缩文件体积。AOF文件重写是把Redis进程内的数据转化为写命令同步到新的AOF文件
重写后的AOF文件为什么会变小？
这是因为AOF文件中有一些内容是冗余的，Redis启动过程中读取AOF文件的内容，记录了中间的过程，实际上Redis在重新启动时只关注最终结果。
冗余的内容：
1.进程内已经超时的数据不在写入到文件。2.旧的AOF中无效的命令，例如del，hdel，srem等重写后将会被删除，只需要保留数据的最终版本。3.多条操作合并为一条，例如lpush list a,lpush list b可以合并为一个lpush list a b 较小的AOF文件一方面减低了硬盘的空间占用，一方面可以提升提升启动Redis时数据恢复的速度。
AOF重写过程可以手动触发也可以自动触发：
手动触发：调用bgrewriteaof命令
自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。 auto-aof-rewrite-min-size：表示触发重写时AOF的最小文件大小，默认为64MB auto-aof-rewrite-percentage：代表当前AOF占用大小相比较上次重写时增加的比例
AOF重写流程
1.执行AOF重写请求（bgrewriteaof）。如果当前进程正在执行AOF重写，请求不执行，直接返回。如果当前进程正在执行bgsave操作（生成RDB快照），重写命令延迟到bgsave完成之后再执行。
2.父进程执行fork创建子进程
3.重写
3.1主进程fork之后，继续响应其他命令。所有修改操作写入AOF缓冲区并根据appendfsync策略同步到硬盘上，保证旧AOF文件机制正确。3.2子进程只有fork之前的所有内存信息，父进程中需要将fork之后的这段时间的修改操作写入AOF的重写缓冲区中。
4.子进程根据内存快照，将命令合并到新的AOF文件中
5.子进程完成重写操作
5.1新文件写入后，子进程发送信号通知父进程 5.2父进程把AOF重写缓冲区临时保存的命令追加到新的AOF文件中。5.3用新的AOF文件代替旧的AOF文件。
2.6重启时数据恢复
当Redis启动时，会根据RDB和AOF文件的内容，进行数据恢复。
Redis根据持久化文件进行数据恢复
当Redis同时存在AOF文件和RDB快照，此时以AOF为主，RDB直接被忽略（这是因为AOF中包含的数据比RDB更全）。
3.Redis持久化回顾
1.Redis提供了两种持久化方案：RDB和AOF
2.RDB视为内存的快照，产生的内容更为紧凑，占用空间小，恢复速度快。但产生RDB的开销比较大，不适合实时持久化，一般用于冷备和主从复制。
3.AOF视为对修改命令的保存，在恢复时需要重放命令。并且有重写机制来定期压缩AOF文件
4.RDB和AOF都使用fork创建子进程，利用Linux子进程用于父进程内存快照的特点进行持久化，尽可能不影响煮即成继续处理后续命令。