集群模式redis-cluster
优点
缺点
redis key选择槽的过程
1.通过key映射到一个0-16384的整数
2.计算key字符串对应的映射值，redis采用了crc16函数然后与0x3FFF取低16位的方法。crc16以及md5都是比较常用的根据key均匀的分配的函数，就这样，用户传入的一个key我们就映射到一个槽上，然后经过gossip协议，周期性的和集群中的其他节点交换信息，最终整个集群都会知道key在哪一个槽上。
背景：
部署介绍
Redis Cluster 集群节点最小配置 6 个节点以上(3 主 3 从)，其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。
Redis Cluster 采用虚拟槽分区，所有的键根据哈希函数映射到 0～16383 个整数槽内，每个节点负责维护一部分槽以及槽所印映射的键值数据。
哨兵模式redis Sentinel
优点
Redis Sentinel 集群部署简单; <br>
能够解决 Redis 主从模式下的高可用切换问题;
很方便实现 Redis 数据节点的线形扩展，轻松突破 Redis 自身单线程瓶颈，可极大满足 Redis 大容量或高性能的业务需求; <br>
缺点
1.部署相对 Redis 主从模式要复杂一些，原理理解更繁琐;
2.资源浪费，Redis 数据节点中 slave 节点作为备份节点不提供服务;
3.对于数据节点下线的情况下只做主观下线和客观下线的过程，并不执行故障转移
监控节点下线的过程
主观下线
客观下线
故障转移通过集群选举的方式从slave选出master
主要功能
1.集群监控：负责监控reidis master 和slave 进程是否正常工作；
2.消息通知：如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员；
3.故障转移：如果master node挂掉了，会自动转移到slave node上；
4.配置中心：如果故障转移发生了，通知client 客户端新的master 地址；
核心说明
1.哨兵至少需要3个实例，来保证自己的健壮性；
2.哨兵+redis 主从的部署架构，是不会保证数据0丢失的，只能保证redis 集群的高可用性；
3.对于哨兵+redis主从这种负责的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练；
数据同步&持久化
全同步
部分同步
AOF
相关配置
1.appendonly yes
2.appendfilename "appendonly.aof"
3.# appendfsync always<br><br>appendfsync everysec<br><br># appendfsync no
4.auto-aof-rewrite-percentage 100 <br>
5.auto-aof-rewrite-min-size 64mb
缺点
2.因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。
解决方案
1.AOF重写，写一个新的AOF文件，然后替换旧的AOF文件
Append only File缩写
核心函数
flushAppendOnlyFile定期执行
条件
write
将AOF buffer中的缓存写入AOF文件
save
调用fsync或者fdatasync函数，将AOF文件保存到磁盘中
RDB
相关配置
优点
1.适合大规模的数据恢复
2.如果业务对数据完整性和一致性要求不高，RDB则是很好的选择
缺点
1.无法实现秒级或者实时的数据持久化
2.RDB文件通过fork子进程完成数据备份，数据量比较大的情况下会导致服务端性能降低
AOF和RDB的区别
1.RDB可以备份多次，有多个数据文件，AOF只有一个文件
2.RDB文件存储的是Redis数据，AOF则是一个个指令数据（RESP通讯协议格式）
3.RDB数据恢复比AOF快
4.AOF文件更新频率相对较高
Redis混合持久化
Redis混合持久化是怎么实现的？
Redis4.0支持混合持久化，但是默认关闭
Redis混合持久化之后是一个文件还是多个文件？
一个aof文件
