本文主要是介绍【大厂必备】Redis之主从、持久化、哨兵，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

上篇文章写了Redis的基础，算是开胃小菜，后面我就要开始放大招了，是真正的大招啊！哈哈哈……

想想这些干货，本来你要花点银子别人才会告诉你的，但是在我这里完全可以白嫖，是真正白嫖的那种哈！

​

唉，谁叫大叔如此爱你呐，咳咳

我们知道Redis是基于内存的单进程单线程模型的工作模式，单机可以轻松达到10w+QPS，因为是基于内存操作的，所以极快，标准的秒男，哈哈哈……

主从复制

但是光快也不行啊，因为随着业务的发展，一个机器是完全不足以支持业务发展的，毕竟，没有老板会希望自己的产品永远只用单机，要规模化，标准化，大量的。

咱们是要在大厂搬砖的人，当然是要搞上万台机器的那种啦。

所以，这时候就需要用到Redis集群了，也就是Redis Cluster模式，通过主从同步，读写分离，将大量的机器组织起来，从而为更多的用户提供服务。

我们可以部署一台主服务器，多台从服务器，主服务器只处理写请求，从服务器通过复制功能同步主服务器的数据，只处理读请求，以此提升Redis的服务能力。

但是机器一多，就像公司里的员工一样，多了就不好管理了，所以，就需要有一套很好的协作机制，来让它们配合工作，从而发挥更大的能量。

这套协作机制就是数据同步，具体工作过程如下：

当你启动一台Slave的时候，它会发送一个psync命令给Master，这时候master就会启动一个线程，生成RDB快照，同时把新的写请求缓存在内存中，当RDB文件生成后，master会将这个RDB文件发送给slave，slave拿到之后首先写进磁盘，然后加载到内存，然后master就会把内存里面缓存的那些命令发给slave，这样就完成了数据的同步。

但是人有旦夕祸福，天有不测风云，万一同步数据的过程中突然断电断网了怎么办？

不用担心，Redis这个猛男还是很顾家的，他会自动重连，然后把少的数据补上，嗯，真是个好男人！

持久化

我们知道Redis是一个内存数据库，作为经常使用电脑的网虫，我们知道，当机器重启之后内存中的数据就会丢失，所以，持久化很重要啦！

就像很多妹子嘴上说着不喜欢渣男，但是渣男带来的刺激和新鲜感还是让人欲罢不能，嘴里说着不要，身体却很诚实，哈哈哈……

但Redis人家可是一个标准的好男人，你的锅他都给你接……

Redis主要有两种持久化方式，一种是RDB方式，另一种是AOF方式。

RDB会保存某一个时间点之前的数据；

AOF会保存Redis执行的每一条命令；

虽然两种方式都可以把数据持久化到磁盘上，但就像两个渣男一样，终究还是有对比的。

RDB

优点

就是其保存的是一个时间点的数据，如果出现了故障，丢失的只是从最后一次RDB执行时间点到故障发生的时间间隔之内的数据。这个优点就特别适合用来做冷备，一般运维都会设置一个定时任务，将数据定时同步到其它机器上，比如将杭州的数据备份到上海，将西安的数据备份到石家庄。万一那个地方的机器挂了，你想恢复任何时间点之前的数据，只需拷贝一份就好了。

而且它恢复的速度很快，同时对性能的影响也很小。

缺点

就是如果数据量很大，QPS很高，那么执行一次RDB需要的时间会相应增加。

AOF

优点

就是他会把服务端执行的每一条命令都保存在文件中，理论上可以做到发生故障时只丢失一条命令。也就是说它的数据安全性更高了。

缺点

就是如果Redis有大量的修改操作，RDB中一个数据的最终态可能会需要大量的命令才能达到，这会造成AOF文件过大并且加载时速度过慢。

而且AOF文件的加载需要先创建一个伪客户端，然后把命令一条条发送给Redis服务端，服务端再完整执行一遍相应的命令，想想就很抓头了！

这个时候该如何选择呢？

就像妹子既喜欢渣男带来的刺激，又想找个老实人过日子，该如何抉择呢？那就只能选我这种既渣又骚又顾家的男人了，哈哈哈……

同理，Redis也是这样一个既骚又成熟的男人，推荐使用RDB和AOF混合持久化方案，这样，在进行AOF重写时子进程将当前时间点的数据快照保存为RDB文件格式，而后将父进程累积命令保存为AOF，这样就能既快有完整了。

哨兵

哨兵，顾名思义就是放哨、观察敌情的，保证大家安全的人。

而Redis的哨兵机制，就是保障Redis的高可用，可以在Redis Master发生故障时自动选择一个Redis Slave切换为Master，继续对外提供服务。

相当于大当家的不幸身亡了，总不能群龙无首吧，这时候大家要再选择一个比较有威望的兄弟当老大了。

这就是大名鼎鼎的sentinel部署方案：

图中有一个Redis Master，该Master下有两个Slave。3个哨兵同时与Master和Slave建立连接，并且哨兵之间也互相建立了连接。

哨兵通过与Master和Slave的通信，能够清楚每个Redis服务的健康状态

而且实际中至少会部署三个以上哨兵，并且哨兵数量最好是奇数个。这是因为如果首先Redis sentinel是为了保障系统高可用，保障不出现单兵作战的困境，所以至少三个，而奇数个是为了保障在选老大的时候不会出现同时选出两个老大的情况。

总结

OK，这期文章可真是精华，几乎是进入大厂的必备板砖之一，写到最后，我都不忍心发出来了，哈哈哈……

不过咱是又渣又成熟的大叔，当然是要让大家白嫖的嘛！

如果你觉得大叔写得还不错，求关注、求点赞、求分享，毕竟大叔熬肝码字也是很幸苦的嘛，当然，如果你是个妹子，也欢迎直接小窗找我哦！

我们下期见！

我是诗远君，一个流浪在互联网江湖的大叔。

这篇关于【大厂必备】Redis之主从、持久化、哨兵的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！