高可用
哨兵模式
基于主从模式（一主多从），主服务器提供写服务，从服务器同步主服务器，从服务器可提供读服务，哨兵(可多个节点实现高可用)监控所有服务，实现故障时自动主从切换
缺点： 只提供高可用并没有提高redis的读写能力，存在主从切换时瞬断问题
高可用集群模式
redis单机支持10万并发， Redis集群水平扩展能突破这个并发数
各个集群模式数据独立， Jedis(Redis官方推荐的Java连接开发工具)通过算法计算缓存key落在哪个集群，再由这个集群提供服务，算法参考 java面试宝典 redis篇 一致性hash算法， 假如集群主服务器挂了，对应的服务唯一码也会在列表中去掉，请求也就不会往故障集群发送，这就解决了主从切换瞬断的问题
持久化
RDB
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘
三种触发模式
- save触发方式
该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到持久化过程完成为止， 这种方式显然不可取。 - bgsave触发方式
执行该save命令时，Redis会在后台异步进行快照操作, 默认采用这种方式 - 自动触发
自动触发是由我们的配置文件来完成的。在redis.conf配置文件中，我们可以去设置
优点：
（1）RDB快照是一次全量备份，存储的是内存数据的二进制序列化形式，存储上非常紧凑，非常适合用于进行备份和灾难恢复。
（2）RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
缺点：
备份是用子线程备份， 父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。
AOF
redis会将每一个收到的写命令都通过write函数追加到文件中。通俗的理解就是日志记录。
由于持久化文件会变的越来越大， redis会会fork出一条新进程来将文件重写， 重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
二种触发模式
- 同步触发，数据可靠，但是会有延迟
- 异步触发，没有延迟，可能有数据丢失
优点：
AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据
缺点：
（1）对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大
（2）以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。
更多demo请关注
springboot demo实战项目
java 脑洞
java 面试宝典
开源工具
公众号
五分钟了解前沿技术，大数据，微服务，区域链，提供java前沿技术干货，独立游戏制作技术分享
如果这篇文章对你有帮助请给个star
