不想弹好吉他的撸铁狗，都不是好的程序猿
尽管说单机的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统一
为了让大家更加清晰的意识到这个过程，咱们通过图再来理解一下。
????????，那如果同步完了之后slave又挂了咋办？slave重启之后很可能就又跟maste不统一了？
确实是这样，这就波及到一个名词叫断点续传了。下面探讨的是slave第一次连贯到master，会执行全量复制，而针对下面这种状况，Redis新老版本解决形式不一样。
Redis2.8之前，当主从实现了同步之后，slave如果断线重连，向master发送sync命令，master会将全量的数据再次同给slave。
然而咱们会发现一个问题，就是大部分数据都是有序的，再次全量同步显得没有必要。而在 Redis2.8之后，为了解决这个问题，便应用了psync命令来代替sync。
简略来说psync命令就是将slave断线期间master接管到的写命令全副发送给slave，slave重放之后状态便与master统一了。
呵呵，就这？那你晓得psync具体怎么实现的吗？还是说就只会用用？
psync的实现依赖于主从单方独特保护的offset偏移量。
每次master向slave进行命令流传，流传了多少个字节的数据，就将本人的offset加上流传的字节数。而slave每次收到多少字节的数据，也会同样的更新本人的offset。
基于offset，只须要简略的比对就晓得以后主从的状态是否是统一的了，而后基于offset，将对应偏移量所对应的指令流传给slave重放即可。所以即便同步的时候slave挂掉了，基于offset，也能达到断点续传的成果。
不是吧不是吧，那master也挂了呢？你slave重新启动之后master的数据也更新了，依照你的说法，这两永远不可能达到数据统一了
这个问题Redis确实也有想到，实际上除了offset之外，slave断线重连之后还会带上上一个master的实例的runid，每个服务实例都有本人的惟一的runid，只有Redis服务重启，其runid就会产生扭转。
master收到这个runid之后会判断是否与本人以后的runid统一，如果统一阐明断线之前还是与本人建设的连贯，而如果不统一就阐明slave断线期间，master也产生了宕机，此时就须要将数据全量同步给slave了。
就算你能解决这个问题，然而你就保护了一个偏移量，偏移量对应的命令从哪儿来？天上掉下来吗？我哪儿晓得这些命令是啥？
确实，咱们须要通过这个offset去拿到真正须要的数据—也就是指令，而Redis是通过复制积压缓冲区来实现的。
名字高大上，实际上就是一队列。就跟什么递归、轮询、透传一样，听着高大上，实际上简略的一匹。言归正传，复制积压缓冲区的默认大小为1M，Redis在进行命令流传时，除了将写命令发送给slave，还会将命令写到复制积压缓冲区内，并和以后的offset关联起来。这样一来就可能通过offset获取到对应的指令了。
然而因为缓冲区的大小无限，如果slave的断线工夫太久，复制积压缓冲区内早些时候的指令就曾经被新的指令笼罩掉了，此处能够了解为一个队列，早些时候入队的元素曾经被出队了。
因为没有绝对应的offset了，也就无奈获取指令数据，此时Redis就会进行全量同步。当然，如果offset还存在于复制积压缓冲区中，则依照对应的offset进行局部同步。
基于以上的全量、增量的主从复制，可能在master呈现故障的状况下，进行主从的切换，保障服务的失常运行。除此之外还能解决异常情况下数据失落的问题。基于读写拆散的策略还可能进步整个Redis服务的并发量。
可别吹了，你说的这个什么主从复制就没啥毛病吗？
其实是有的，例如刚刚提到的主从的切换，如果不必现成的HA框架，这个过程须要程序员本人手动的实现，同时告诉服务调用方Redis的IP产生了变动，这个过程能够说是非常的简单，甚至还可能波及到代码配置的改变。而且之前的slave复制的可都是挂掉的master，还得去slave上更改其复制的主库，就更加简单了。
除此之外，尽管实现了读写拆散，然而因为是一主多从的架构，集群的读申请能够扩大，然而写申请的并发是有下限的，那就是master可能扛住的下限，这个没有方法扩大。
好了，本期的分享就到此结束了，咱们下期再见。
如果你感觉这篇文章对你有帮忙，还麻烦点个赞，关个注，分个享，留个言
也能够微信搜寻公众号【SH的全栈笔记】，关注公众号提前浏览其余的文章
往期文章
- Redis根底—分析根底数据结构及其用法
- Redis根底—理解Redis是如何做数据长久化的
- 简略理解一下K8S，并搭建本人的集群
- WebAssembly齐全入门——理解wasm的前世今生
- 浅谈JVM与垃圾回收