redis的四个问题： 

1.Redis是基于内存存储,服务重启可能会丢失数据;
2.并发能力问题：单节点Redis能力虽然不错,但也无法满足如618这种高并发的场景(618并发
数量达到数十万甚至上百万);
3.如果reids宕机,服务不可用,则需要一种自动的故障恢复手段;
4.存储能力问题： Redis是基于内存,单节点存储的数据难以满足海量数量需求;

重要：
数据丢失：利用持久化，将数据写入磁盘，数据一但落盘数据就安全了;
并发能力问题：做负载均衡的集群，reids内部就有一种主从集群，其中从节点可以有很多个,彼此之前是负
载均衡的,主从节点之间可以实现读写分离(读写互斥并发能力会更强);高可用：主节点宕机了，从节点还能
顶上使用；
故障恢复问题：虽然主从模式具有高可用，但是如果一直挂掉不恢复还是会有问题(全部宕机);这时候就要
依赖哨兵机制:去监测主从节点的健康状况，一但发现有宕机的机器立马自动启动恢复机制;这样就实现了
高可用、高并发；
存储能力问题：由于数据的上限还是单个节点的上限;使用分片集群，利用插槽机制实现动态扩容;（理论
上是没有上限的）

1. Redis持久化 

  ​​​​​​​

save：不推荐  主进程执行RDB,并且通过消耗大量io将数据存储到磁盘中(耗时比较久).影响redis
对外提供服务；

bsave:推荐  

演示：Redis停机时会执行一次RDB 

1.启动Redis

 再一次启动客户端,数据就会恢复 

 如何定时触发RDB: 

演示： 

redis.conf 
save  5  1 
dbfilename  test.rdb

 RDB的问题：比如设置30秒钟,30秒中发生宕机就会有 数据丢失

 20:04-   RDB的底层原理

 

 2. AOF持久化

演示：

redis.conf
save  "" #禁用RGB
appendonly  yes  #开启AOF功能

 

aof文件已经产生(接着存储就接着记录): 

 

 

 

如何解决对同一个key的多次写操作： 

用最少得命令达到相同的效果,减少AOF 文件的体积

什么时候重写AOF文件？

如果同时启动了RDB和AOF,AOF优先级更高点(因为AOF的数据更完整) 

一般会结合使用：RDB(做数据备份,异地容灾) 、AOF(宕机后数据恢复)