跟随杠精的视角一起来了解Redis的主从复制
Posted SH的全栈笔记
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了跟随杠精的视角一起来了解Redis的主从复制相关的知识，希望对你有一定的参考价值。
不想弹好吉他的撸铁狗，都不是好的程序猿
虽然说单机的Redis性能很好，也有完备的持久化机制，那如果你的业务体量真的很大，超过了单机能够承载的上限了怎么办？不做任何处理的话Redis挂了怎么办？带着这个问题开始我们今天的主题-「Redis高可用」，由于篇幅原因，本章就只聊聊主从复制。
为啥要先从主从复制开始聊，是因为「主从复制」可以说是整个Redis高可用实现的基石，你可以先有这么一个概念，至于具体为什么是基石，这个后面聊到Sentinel和Redis集群的时候会说到。
首先我们需要知道，对于我们开发人员来说，为什么需要「主从架构」？一个Redis实例难道不行吗？
其实除了开篇提到的负载超过了Redis单机能够处理的上限，还有一种情况Redis也无法保证自身的高可用性。那就是即便Redis能够扛住所有流量，但是如果这个Redis进程所在的机器挂了呢？请求会直接调转枪口，大量的流量会瞬间把你的DB打挂，然后你就可以背个P0，打包回家了。
而且，假设你对Redis的需求真的超过了单机的容量，你怎么办？搞多台独立的Redis实例吗？那如果用户缓存的数据这一次存在了实例一，下一次如果用户又访问到了实例二，难道又要去走一遍DB吗？除非你能够维护好用户和Redis实例的对应关系（但是通常这样的逻辑比较复杂），否则部署多个Redis实例也就失去了它的意义，没有办法做到横向扩展了。
那换成主从架构就能解决这个问题吗？
我们可以从一个图来直观的了解一下。
在主从同步中，我们将节点的角色划分为master和slave，形成「一主多从」。slave对外提供读操作，而master负责写操作，形成一个读写分离的架构，这样一来就能够承载更多的业务请求。
在多数的业务场景下，对于Redis的「读操作」都要多于「写操作」，所以当读请求量特别大的时候，我们可以通过增加slave节点来使Redis扛住更多的流量。
你这不行啊老弟，你往master写数据，那我要是连接到slave上去了，不就拿不到之前的数据了？
我这个小标题的不是写了吗？「主从复制」，slave会按照某种策略从master同步数据。Redis中我们可以通过slaveof命令让一个Redis实例去复制（replicate）另外一台Redis的状态。被复制的Redis实例就是master节点，而执行slaveof命令的机器就是slave节点。
Redis的主从复制分为两个步骤，分别是「同步」和「命令传播」。
「同步操作」用于将Master节点内存状态复制给Slave节点，而「命令传播」则是在同步时，客户端又执行了一些「写」操作改变了服务器的状态，此时master节点的状态与同步操作执行的时候不一致了，所以需要命令传播来使master和slave状态重新一致。
同步的大致的流程如下：
-
slave节点向master节点发送 sync命令 -
master收到 sync命令之后会执行bgsave命令，Redis会fork出一个子进程在后台生成RDB文件，同时将同步过程中的写命令记录到缓冲区中 -
文件生成后，master会把RDB文件发送给slave，从服务器接收到RDB文件会将其载入内存 -
然后master将记录在缓冲区的所有写命令发送给slave，slave对这些命令进行 「重放」，将其数据库的状态更新至和master一致
为了让大家更加清晰的认识到这个过程，我们通过图再来了解一下。
以上是关于跟随杠精的视角一起来了解Redis的主从复制的主要内容，如果未能解决你的问题，请参考以下文章