Redis持久化方案RDB和AOF（理论）
redis和memcache的区别是什么？简单来说，如果没有持久化的redis，就和memcache一样了，相当于一个缓存数据库。
redis是如何解决数据持久化的？
redis有两种持久化方案：RDB（Redis DataBases）和AOF(AppendOnly File)
RDB持久化（详细分析：http://blog.51cto.com/13690439/2118462）
RDB是snapshot快照存储，是默认的持久化方式。
RDB会按照一定的策略，周期性的将数据保存到磁盘。（下个周期为到来时故障，会丢数据）
借助fork命令的copy on write机制，在快照生成时，将当前进程fork出一个子进程，
然后再子进程中循环所有数据，将数据写成RDB文件。
AOF持久化（详细分析：http://blog.51cto.com/13690439/2118465）
AOF比RDB方式有更好的持久性。
redis会将每一个收到的写命令都通过write函数追加到文件最后，类似msyql的binlog。
当redis重启时，会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。
简单来说:
RDB：是按照策略周期性的进行持久化数据；
AOF：是不断的去记录修改操作；
持久化方式的选择：
RDB和AOF操作都是顺序IO操作，性能都很高。
而同时在通过RDB文件或者AOF日志进行数据库恢复的时候，也是顺序的读取数据加载到内存中。
所以也不会造成磁盘的随机读。
通常，如果你要想提供很高的数据保障性，那么建议你同时使用两种持久化方式。
如果你可以接受灾难带来的几分钟的数据丢失，那么你可以仅使用RDB。
在数据恢复方面：
RDB的启动时间会更短，原因有两个：
1、RDB文件中每一条数据只有一条记录，不会像AOF日志那样可能有一条数据的多次操作记录。
所以每条数据只需要写一次就行了。
2、RDB文件的存储格式和Redis数据在内存中的编码格式是一致的，不需要再进行数据编码工作，
所以在CPU消耗上要远小于AOF日志的加载。
市场常见架构：
目前，通常的设计思路是利用Replication机制来弥补aof、snapshot性能上的不足，达到了数据可持久化。
即Master上Snapshot和AOF都不做，来保证Master的读写性能，
而Slave上则同时开启Snapshot和AOF来进行持久化，保证数据的安全性。
页:
[1]