redis数据持久化

到这里为止，其实还是停留在简单学习知识的程度，学会了redis的持久化的原理和操作，但是在企业中，持久化到底是怎么去用得呢？ 企业级的数据备份和各种灾难下的数据恢复，是怎么做得呢？ 1、企业级的持久化的配置策略 在企业中，RDB的生成策略，用默认的也差不多 save 60 10000：如果你希望尽可能确保说，RDB最多丢1分钟的数据，那么尽量就是每隔1分钟都生成一个快照，低峰期，数据量很少，也没必要 10000->生成RDB，1000->RDB，这个根据你自己的应用和业务的数据量，你自己去决定 AOF一定要打开，fsync，everysec auto-aof-rewrite-percentage 100: 就是当前AOF大小膨胀到超过上次100%，上次的两倍 auto-aof-rewrite-min-size 64mb: 根据你的数据量来定，16mb，32mb 2、企业级的数据备份方案 RDB非常适合做冷备，每次生成之后，就不会再有修改了 数据备份方案 （1）写crontab定时调度脚本去做数据备份 （2）每小时都copy一份rdb的备份，到一个目录中去，仅仅保留最近48小时的备份 （3）每天都保留一份当日的rdb的备份，到一个目录中去，仅仅保留最近1个月的备份 （4）每次copy备份的时候，都把太旧的备份给删了 （5）每天晚上将当前服务器上所有的数据备份

redis的持久化，RDB，AOF，区别，各自的特点是什么，适合什么场景 redis的企业级的持久化方案是什么，是用来跟哪些企业级的场景结合起来使用的？？？ redis持久化的意义，在于故障恢复 比如你部署了一个redis，作为cache缓存，当然也可以保存一些较为重要的数据 如果没有持久化的话，redis遇到灾难性故障的时候，就会丢失所有的数据 如果通过持久化将数据搞一份儿在磁盘上去，然后定期比如说同步和备份到一些云存储服务上去，那么就可以保证数据不丢失全部，还是可以恢复一部分数据回来的 内容大纲 1、RDB和AOF两种持久化机制的介绍 2、RDB持久化机制的优点 3、RDB持久化机制的缺点 4、AOF持久化机制的优点 5、AOF持久化机制的缺点 6、RDB和AOF到底该如何选择 写在前面 我们已经知道对于一个企业级的redis架构来说，持久化是不可减少的 企业级redis集群架构：海量数据、高并发、高可用 持久化主要是做灾难恢复，数据恢复，也可以归类到高可用的一个环节里面去 比如你redis整个挂了，然后redis就不可用了，你要做的事情是让redis变得可用，尽快变得可用 重启redis，尽快让它对外提供服务，但是就像上一讲说，如果你没做数据备份，这个时候redis启动了，也不可用啊，数据都没了 很可能说，大量的请求过来，缓存全部无法命中，在redis里根本找不到数据