没错，很老生畅谈的问题啦
reids快照
1、将内存数据库快照保存在名字为 dump.rdb 的二进制文件
2、设置配置文件save s num设置多少秒多少个
3、或命令 save (同步)/ bgsave ：主fork子进程来共享内存数据生成dump新文件覆盖旧的
写时复制cow
1、fork子进程读取主进程内存数据，写入rdb文件
2、读不影响
3、写：被写的数据复制，bgsave小子将副本写入rdb文件(耗内存)，主线修改原数据
4、机器挂了丢失没来及和快照 合二为一的数据（多可惜 没来得及加入快照这一温暖的大家庭）
aof
aof就比较细心了，本着可以百分百负责的态度将每一条指令记录到appendonly.aof文件中
1、先到os cache，隔一段时间fsync到磁盘（隔一段注意哦是隔一段 这世界哪有什么全心全意）
2、重启时将执行aof文件中指令来达到重建数据集伟大帝国的这一目的
3、可是aof里面命令太多怎么办呢（愁死👶了）欸咱们redis这么聪明，会定期根据内存最新数据生成aof文件，将重复的命令合并，自动的方式如下，手动那就是执行bgrewriteaof命令了，注意啦 重写时fork子去做(参考bgsave的)，"脏活累活"怎么能主子去做呢？没有🐮🐎觉悟可不行！
# appendonly yes开启
1 # auto‐aof‐rewrite‐min‐size 64mb //aof至少要达到64M才自动重写，太小恢复速度本来就
很快，意义不大
2 # auto‐aof‐rewrite‐percentage 100 //aof自上一次重写后文件大小增长了100%则再次触发重写
优先aof，因为他数据全，当然这世间没有完美的事情，执行起来就比较慢，"婆婆妈妈"的，当然不想被唠叨，那你就选redis4.0混合双打，不是redis4.0混合持久化！铛铛铛～
4.0混合
首先混合潜规则就有aof那就要开启aof啦，当然开启aof并不意味着开启了混合双打，所以需要#aof‐use‐rdb‐preamble yes开启！
1、aof重写时，重写这一刻之前的内存做rdb快照，并且一并和增量的aof修改内存数据的命令放在新的aof文件中
2、等重写完新的aof文件，才覆盖旧的aof，不能弄一半就着急"招摇过市" 万事求一个稳妥、靠谱
3、so 亲爱的redis在重启时，先加载rdb(他快)再重放增量的aof日志，日志这个词多好，不宣兵夺主，在甄嬛传中活到第三集妥妥的
持久化差不多说完了皮毛，大家看得也不容易，最后附赠一个
数据备份策略
首先不讲大前提都是刷流氓，咱们简简单单就reids ，别整那🈶️的没的中间价抬杠
1、写corn定时脚本，自己定多久copy rdb/aof到**中去，保留个48h到备份差不多（场景很重要，自己想 自己套）
2、每天呢保留当日的数据到****目录，这个保守写，可以多存些时日，就当过冬储粮（量）了
3、不过也别留太多，那没用的 太久的 该删就删 舍不得👶怎么套🐺，是不是
4、如果这数据还是担心丢，那就机器之前互备，大家伙互相照应些，老板多花点钱，让咱们工人们借助聪明才智将机器a的数据备份到机器人b，万一a坏了还有个垫底的，有问题一起扛
