redis主从、哨兵、集群模式介绍

主从模式 (master-slave)

备份数据、负载均衡，一个Master可以有多个Slaves。
主从模式强调 数据备份，读写分离等

Redis 复制功能的几个重要方面：

1. 一个主服务器可以有多个从服务器。
2. 不仅主服务器可以有从服务器， 从服务器也可以有自己的从服务器， 多个从服务器之间可以构成一个图状结构。
3. 复制功能不会阻塞主服务器： 即使有一个或多个从服务器正在进行初次同步， 主服务器也可以继续处理命令请求。
4. 复制功能也不会阻塞从服务器： 只要在 redis.conf 文件中进行了相应的设置， 即使从服务器正在进行初次同步， 服务器也可以使用旧版本的数据集来处理命令查询。
   不过， 在从服务器删除旧版本数据集并载入新版本数据集的那段时间内， 连接请求会被阻塞。
   你还可以配置从服务器， 让它在与主服务器之间的连接断开时， 向客户端发送一个错误。
5. 复制功能可以单纯地用于数据冗余（data redundancy）， 也可以通过让多个从服务器处理只读命令请求来提升扩展性（scalability）： 比如说， 繁重的 SORT 命令可以交给附属节点去运行。
6. 可以通过复制功能来让主服务器免于执行持久化操作： 只要关闭主服务器的持久化功能， 然后由从服务器去执行持久化操作即可。

哨兵模式 (sentinel)

sentinel发现master挂了后，就会从slave中重新选举一个master。
哨兵模式强调高可用

Sentinel 系统用于管理多个 Redis 服务器（instance）， 该系统执行以下三个任务：

监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

客户端中不会记录redis的地址（某个IP），而是记录sentinel的地址，这样我们可以直接从sentinel获取的redis地址，因为sentinel会对所有的master、slave进行监控，它是知道到底谁才是真正的master的，例如我们故障转移，这时候对于sentinel来说，master是变了的，然后通知客户端。而客户端根本不用关心到底谁才是真正的master，只关心sentinel告知的master。

集群模式 （cluster）

cluster是为了解决单机Redis容量有限的问题，将数据按一定的规则分配到多台机器。

集群模式提高并发量。(Redis 的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台 Redis 服务器都存储相同的数据，很浪费内存，所以在 redis3.0上加入了 Cluster 集群模式，实现了 Redis 的分布式存储，也就是说每台 Redis 节点上存储不同的内容。)

---

Redis持久化

redis支持两种方式的持久化，可以单独使用或者结合起来使用。
1、第一种：RDB方式redis默认的持久化方式（快照）
2、第二种：AOF方式（日志追加）

扫描二维码关注公众号，回复： 12608247 查看本文章

RDB快照模式(snapshot):

save 900 1  //900秒内如果超过1个key被修改，则发起快照保存
save 300 10 //300秒内容如超过10个key被修改，则发起快照保存
save 60 10000  //(这3个选项都屏蔽,则rdb禁用)

stop-writes-on-bgsave-error yes  // 后台备份进程出错时,主进程停不停止写入
rdbcompression yes      // 导出的rdb文件是否压缩
Rdbchecksum   yes       //导入rbd恢复时数据时,要不要检验rdb的完整性
dbfilename dump.rdb     //导出来的rdb文件名
dir /var/lib/redis/     //rdb的放置路径

•  

AOF日志模式:

appendonly yes              //启用aof持久化方式
# appendfsync always        //每收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用
appendfsync everysec        //每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐
# appendfsync no            //完全依赖os，性能最好,持久化没保证（操作系统自身的同步）
no-appendfsync-on-rewrite  yes   //正在导出rdb快照的过程中,要不要停止同步aof
auto-aof-rewrite-percentage 100  //aof文件大小比起上次重写时的大小,增长率100%时,重写
auto-aof-rewrite-min-size 64mb   //aof文件,至少超过64M时,重写

•  

注意：
1、AOF和RDB同时存在的时候，优先使用AOF恢复数据，因为AOF保存的数据集更完整；
2、AOF和RDB恢复的时候，RDB更快，直接拷贝数据，AOF还要执行语句；
3、建议同时使用AOF和RDB

参考资料：

https://jasonhzy.github.io/2017/12/12/redis/ 

https://my.oschina.net/u/3371837/blog/1789790