Redis持久化

redis持久化：

redis支持五种数据类型：string，hash，list，set，sorted set，通常redis将数据存储在内存中，或者配置为使用虚拟内存（虚拟内存，通常被分为多个物理碎片，还有一部分存在外部磁盘储存器上，在有需要的时候进行数据交换），redis可以进行持久化，通过两个方式：RDB快照方式，将内存不断的写入磁盘，或者使用类似于MySql中的AOF日志方式，记录每次更新的日志，前者性能较高，但是容易造成数据的丢失，后者性能较低，但是不容易丢失数据。
RDB：是不断的将内存写入磁盘，实际上就是先fork一个子进程，然后先将数据集快照写入一个临时文件，然后写入成功以后，替换之前的文件，用二进制压缩存储，但是这中间就存在一个问题，如果服务器宕机，那么还没来得及存进去的数据就没了，所以虽然RDB性能高，但是有可能会造成数据的丢失，甚至是大量的。当然，RDB启动效率要比AOF高得多，这一点在数据集很大时体现的很明显，因为我们就需要对一个临时文件进行操作，所以同时我们的灾难恢复选择RDB更好一些。 （灾难恢复，指自然或人为灾害后，重新启用信息系统的数据、硬件及软件设备，恢复正常商业运作的过程。灾难恢复规划是涵盖面更广的业务连续规划的一部分,其核心即对企业或机构的灾难性风险做出评估、防范，特别是对关键性业务数据、流程予以及时记录、备份、保护。）当然，如果数据集十分大的时候，有可能会导致服务器停止服务几百毫秒，甚至1秒。
AOF：记录服务器的所处理的每一个写，删除操作，但不会记录查询操作，以文本的方式记录，可以打开文件后查看到详细的记录，通过该机制，我们可以更安全的持久化，（Redis中提供了3种同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。）同时由于该机制对文件的写入操作是append模式，即在操作的过程中即使出现宕机，也不会影响之前的数据。当然，AOF也存在一些缺点，如同前面说过的，它的效率不如RDB，同时，RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
选择：二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。rdb这个就更有些 eventually consistent的意思了。不过生产环境其实更多都是二者结合使用的。
参考资料：https://www.cnblogs.com/zxs117/p/11242026.html