Redis 持久化

RDB持久化方式会在一个特定的间隔保存那个时间点的一个数据快照。
AOF持久化方式则会记录每一个服务器收到的写操作。在服务启动时，这些记录的操作会逐条执行从而重建出原来的数据。写操作命令记录的格式跟Redis协议一致，以追加的方式进行保存

RDB（redis database）快照
	Redis调用fork()，产生一个子进程。子进程把数据写到一个临时的RDB文件。当子进程写完新的RDB文件后，把旧的RDB文件替换掉，
	父进程继续处理client请求，子进程把内存数据写到一个临时的RDB文件。由于os的写时复制机制（copy on write)父子进程会共享相同
	的物理页面，当父进程处理写请求时os会为父进程要修改的页面创建副本，而不是写共享的页面。所以子进程的地址空间内的数据是
	fork时刻整个数据库的一个快照。
	
	优点：
		备份可恢复到不同版本
		性能好，数据量比较大的情况下启动快
	缺点：
		数据容易丢失，取决于备份的时间间隔
		fork()产生子进程进行数据的持久化，如果数据比较大的话可能就会花费点时间，造成Redis[停止服务几毫秒](https://www.cnblogs.com/yjf512/archive/2012/03/06/2382733.html)。
		
	
	
AOF（Append Only File）追加式
	优点：
		比RDB可靠，默认是每秒fsync一次。这意味着你最多丢失一秒钟的数据。
		AOF日志文件是一个纯追加的文件。容易定位，简单易懂的格式，很容易导出来用于恢复数据。例如我们不小心用FLUSHALL命令
把所有数据刷掉了，只要文件没有被重写，就能删掉FLUSHALL然后恢复
	缺点：
		文件相对大
		速度慢
		过去曾经发现一些很罕见的BUG导致使用AOF重建的数据跟原数据不一致的问题

AOF

fsync是把内存中的写操作写入aof文件中
rewrite是将写操作合并，比如set aa 1; set aa 2;两个操作应该写成一个操作set aa 2;

redis单线程指的是网络请求模块使用了一个线程（所以不需考虑并发安全性），即一个线程处理所有网络请求，其他模块仍用了多个线程。