由redis持久化AOF重写想到Excel保存过程

redis的持久机制有两种，一种是snapshot，另一种是AOF重写。第一种机制是按事先定制的策略，周期性地异步或同步将数据从内存同步至磁盘，在客户端的操作是由SAVE或BGSAVE命令执行。而AOF重写则是记录写操作至指定的文件尾部实现持久化。AOF重写过程如下：
（1）redis主进程通过fork创建子进程
（2）子进程根据当前redis内存中的数据生成数据库重建命令序列到临时文件中
（3）父进程继承client的新请求，把请求中的写操作继续追加至原来的AOF文件(而不是直接写入临 时文件，避免写操作失败带来的问题)；额外地，这些新的写请求还会被放置于一个缓冲队列中
（4）子进程重写完成，会通知父进程，父进程把缓冲中的命令写到临时文件中
（5）父进程将临时文件替换掉旧的AOF文件

AOF重写使我想到了Excel的保存过程：

编辑test.xlsx,

（1）创建临时文件xxxx.tmp,把Excel缓冲内容写到xxxx.tmp中
（2）把原来的test.xlsx文件重命名为另一个临时文件yyyy.tmp
（3）把xxxx.tmp重命名为test.xlsx
Excel保存过程明显是更复杂的，复杂的设计往往伴随着更多出问题的概率，所以微软的老用户或多或少经历过保存文件时发生保存失败的问题:




与Excel保存机制不同的是，AOF重写并没有将原来的AOF文件重命名为另一个文件后再替换掉旧AOF文件，那么AOF重写这种机制的可靠性会差吗？其实不会，即使是AOF重写过程最后替换旧文件过程错误损坏旧文件同时不行临时文件也损坏，内存中依然存有数据和缓冲过的操作。

（注：Excel保存过程参考林沛满大神的《wireshark网络分析就是这么简单》一书）