考虑这么一个问题：虽然redis可以持久化到硬盘中，那要是硬盘坏了呢或者发生火灾？
一般解决方案就是做主库和从库，更保险一点一台在上海一台在北京，还能异地容灾。
1.主从同步
什么是redis的主从同步？有什么好处？
有主库和从库，其中主节点把数据分发给从节点，主节点对数据的修改会同步到从节点。
提供多个副本，实现高可用。
实现读写分离，提高性能（毕竟redis再猛，一台机子能顶住的压力也是有上限的）
什么是全量复制？
一开始创建的从数据库肯定是空的，那就要把主数据库里的全复制过来，从服务器发送SYNC命令，主服务器收到后执行BGSAVE用来生成RDB文件，还会有个缓冲区记录这之后执行的命令，之后也会发给从数据库，从数据库把RDB拿到后载入，再载入缓冲区的命令
什么是增量复制？
主节点会将那些对自己的状态产生修改性影响的指令记录在本地的内存 buffer 中，然后异步将 buffer 中的指令同步到从节点，从节点一边执行同步的指令流来达到和主节点一样的状态，一遍向主节点反馈自己同步到哪里了
2.哨兵模式
什么是哨兵模式？
实现了redis集群的监控、提醒、故障转移。
主从复制的升级版，这次我们需要一主二从，再开启一个哨兵用来监控这三个redis，如果主数据库挂了，免得人来操作，自动就把一个从数据库升级为Master接着用。
为什么至少需要三个？
如果一主一从的话，主服务器挂了，剩下一从就没法故障转移了。
哨兵挂了怎么办？
小事，既然redis都高可用了，搞个哨兵高可用还难了不成，多搞几个哨兵。
哨兵是怎么监控的？
隔一段时间Ping一下，注意这边我们有好多哨兵，有一定的哨兵没Ping到这个Master，就认为他挂了。
3.cluster集群和哈希槽
先来看下上面的主从、哨兵虽然容易扩展，会遇到什么问题
1.如果主数据库挂了，会造成异步同步那一段数据的丢失（主数据库挂的时候还有一段数据没发给从数据库）
1.大家存的都是一样的，浪费内存
2.如果数据太大，一个单的redis都放不下，怎么办？（注意上面两种主从存储的都是全部数据）
cluster集群是怎么解决这些问题的?
这个时候就用到了cluster集群，可以通过算法（CRC-16）将key变成整数，取余之后看一下落在哪个哈希槽里面，就存到哪边的服务器中，注意这个时候也是有master和slave来保证数据的高可用，还能解决内存冗余的问题。
事实上第一个问题也只解决了一部分，因为仍然会有一部分数据丢失，但是肯定比所有数据都存在一个数据库里丢失的少了
缺点在于如果想再加进来一台master会比较麻烦
11.png
对比一致性哈希：
当发生扩容时候，哈希槽采用灵活的可配置映射表，可以随意组织映射到新增server上面的slot数，比一致性hash的算法更灵活方便；同时也给开发人员手工配置更大的简洁性。
其次，在数据迁移时，一致性hash 需要算哪些key是落在新增服务节点的数据，然后迁移这部分数据，哈希槽则直接将一个slot对应的数据全部迁移，算法明确以及实现更简单。
