持久化也是区别于memcached的一点， 持久化有两种：一个是RDB，一个是AOF

1、RDB需要定时持久化，风险是可能会丢两次持久之间的数据，量可能很大。
2、AOF每秒fsync一次指令硬盘，如果硬盘IO慢，会阻塞父进程；风险是会丢失1秒多的数据；在Rewrite过程中，主进程把指令存到mem-buffer中，最后写盘时会阻塞主进程。
3、Redis 启动时， 如果 RDB 持久化和 AOF 持久化都被打开了， 那么程序会优先使用 AOF 文件来恢复数据集， 因为 AOF 文件所保存的数据通常是最完整的。

1、对于我们应该选择RDB还是AOF，官方的建议是两个同时使用。这样可以提供更可靠的持久化方案。
2、redis的备份和还原，可以借助第三方的工具[redis-dump请添加链接描述](https://github.com/delano/redis-dump)

AOF持久化： 可以理解为记录的操作日志，增量日志备份的方式，执行set命令，AOF文件都可以看到，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾

命令：BGREWRITEAOF 就是fork子进程，子进程读取现有的aof文件，并将其压缩打包到临时文件，主进程接收到新的写命令一边写入到原有的aof文件，一边累计到内存缓冲区，保证原有的AOF文件的可用性，避免在重写过程中出现意外， 子进程写完之后会给父进程发指令，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中，追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中了

这个是我执行的几个set的命令，AOF文件一一记录。

AOF优点：既然是增量的日志备份，肯定是方便备份，备份的详细，可以基于时间点恢复， AOF缺点：同样的一个备份和恢复，AOF的文件大小和时间都是比较大的，

AOF文件如果损坏了，可以修复的 1.备份被写坏的AOF文件 2.运行redis-check-aof –fix进行修复 3.用diff -u来看下两个文件的差异，确认问题点 4.重启redis，加载修复后的AOF文件

那么多久sync一次到硬盘呢？？？？？？ 推荐的是1s一次

1.每次有新命令追加到 AOF 文件时就执行一次 fsync ：非常慢，也非常安全。 2.每秒 fsync 一次：足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。 3.从不 fsync ：将数据交给操作系统来处理。更快，也更不安全的选择。

RDB 持久化： 可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot），就是冷备份。 如果你对数据的完整性非常敏感，那么RDB方式就不太适合你，因为即使你每5分钟都持久化一次，当redis故障时，仍然会有近5分钟的数据丢失

RDB优点： 1、因为是冷备份，灾难性的恢复比较好， 2、备份比AOF用时和文件提交都要小 RDB缺点： 因为是有时间间隔的备份，所以相比AOF丢失的数据会多

命令：BGSAVE bgsave跟bgreriteaof不能同时执行

参考：https://my.oschina.net/davehe/blog/174662 https://blog.csdn.net/ljheee/article/details/76284082

redis与memcached对比

NoSQL主要用于解决以下几种问题 　　1.少量数据存储，高速读写访问。此类产品通过数据全部in-momery 的方式来保证高速访问，同时提供数据落地的功能，实际这正是Redis最主要的适用场景。 　　2.海量数据存储，分布式系统支持，数据一致性保证，方便的集群节点添加/删除。

单的区别：
1 Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
2 Redis支持数据的备份，即master-slave模式的数据备份。
3 Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用

Redis只会缓存所有的 key的信息， 如果Redis发现内存的使用量超过了某一个阀值，将触发swap的操作，Redis根据“swappability = age*log(size_in_memory)”计 算出哪些key对应的value需swap到磁盘。 然后再将这些key对应的value持久化到磁盘中，同时在内存中清除。这种特性使得Redis可以 保持超过其机器本身内存大小的数据。 同时由于Redis将内存 中的数据swap到磁盘中的时候，提供服务的主线程和进行swap操作的子线程会共享这部分内存，所以如果更新需要swap的数据，Redis将阻塞这个 操作，直到子线程完成swap操作后才可以进行修改。使用Redis特有内存模型前后的情况对比： VM off: 300k keys, 4096 bytes values: 1.3G used VM on: 300k keys, 4096 bytes values: 73M used VM off: 1 million keys, 256 bytes values: 430.12M used VM on: 1 million keys, 256 bytes values: 160.09M used VM on: 1 million keys, values as large as you want, still: 160.09M used

当 从Redis中读取数据的时候，如果读取的key对应的value不在内存中，那么Redis就需要从swap文件中加载相应数据，然后再返回给请求方。 这里就存在一个I/O线程池的问题。在默认的情况下，Redis会出现阻塞，即完成所有的swap文件加载后才会相应。这种策略在客户端的数量较小，进行批量操作的时候比较合适。但是如果将Redis应用在一个大型的网站应用程序中，这显然是无法满足大并发的情况的。所以Redis运行我们设置I/O线程 池的大小，对需要从swap文件中加载相应数据的读取请求进行并发操作，减少阻塞的时间。如果希望在海量数据的环境中使用好Redis，我相信理解Redis的内存设计和阻塞的情况是不可缺少的。

Redis和Memcached整体对比 Redis的作者Salvatore Sanfilippo曾经对这两种基于内存的数据存储系统进行过比较，总体来看还是比较客观的，现总结如下： 1）性能对比：由于Redis只使用单核，而Memcached可以使用多核，所以平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中，Memcached性能要高于Redis，虽然Redis最近也在存储大数据的性能上进行优化，但是比起Memcached，还是稍有逊色。 2）内存使用效率对比：使用简单的key-value存储的话，Memcached的内存利用率更高，而如果Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于Memcached。 3）Redis支持服务器端的数据操作：Redis相比Memcached来说，拥有更多的数据结构和并支持更丰富的数据操作，通常在Memcached里，你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中，这些复杂的操作通常和一般的GET/SET一样高效。所以，如果需要缓存能够支持更复杂的结构和操作，那么Redis会是不错的选择。

链接：https://www.jianshu.com/p/23ea6815eca8 来源：简书