Redis主从架构
本文我们重点探讨一下Redis的主从架构，假设我们Redis只有一个节点，那么它会为我们的数据库起到一个屏障的作用，如果我们现在有很多的请求，并发请求到Redis，我们想一想会有什么样的问题呢？
一般情况下，单机单节点的Redis并发的话基本是在上万吧，如果服务器硬件配置包括运维人员优化做到非常高的话，那么达到个十几万二十几万应该也是没有问题的，但是它肯定是有一个瓶颈的。
随着我们的业务复杂度不断的增长，Redis能够支持的并发量肯定是有上限的，那在这个时候我们应该想到能不能为我们的Redis做一个扩展呢？
所以我们来和大家探讨一下Redis的主从架构。
所谓主从架构就是我们对原来的Redis作为我们的主节点（master），然后我们额外扩展了几台Redis，这样扩展的Redis就是从节点（slave）。
其实主从架构就是它最简单的扩展模式，我们也可以理解为水平扩展，主从架构我们也可以称为“读写分离架构”。
正常情况下对于我们绝大多数的请求，基本都是读操作，还有少部分请求是写操作，所以我们可以把读的请求交给slave，写的请求交给master，那么当请求来的时候master其实就是起到一个分发请求的作用，把请求分发给slave去处理，这样的话整体的性能就能倍速提升了，所以我们又可以把这种方式称之为水平扩展的一种方式，通过增加服务器来提升性能。
主从复制原理
首先我们先会有一个Master节点，然后我们再有一个Slave，Slave就是专门处理读请求的，我们先会启动Master，然后再对Slave做一些配置，当我们配置并启动完成后，Slave会发送一个ping包给Master，就是告诉Master已经启动成功了，然后Master会把一些数据提交给Slave，交给Slave去处理，那么这个过程就是一个数据复制，并且是一个全量的数据复制，这个数据其实就是一个RDB文件，通过它内网的网络传输，传输给Slave，Slave拿到RDB以后它并不是直接读到内存里面去的，而是先对RDB进行下载，下载到自己的硬盘以后，随后才会把RDB加载到Slave的内存里面去，这样的话就是完成了复制的过程，这个过程也是它的第一个过程，其实就是一个init，初始化的过程，再随后如果再来一些相应的写请求进来，只要是写操作，他就会把相应的命令同步给Slave，那么这样Slave就会修改它自己的内存中的数据，这样他们直接就能做到数据同步了，另外他的数据同步的过程其实是不会影响或者阻塞Master的写操作，也不会阻塞Slave的读操作的，这主要是因为他们使用旧的数据提供服务，如果数据同步完成以后，那么就会替换掉旧的数据，使用新的数据提供服务。
那么在我们的主从架构里面有一个注意点，就是Master必须要开启持久化，如果不开启持久化的话，一旦Master停掉，这时候因为Slave是仍然正常在提供服务的，如果Master再次重启，因为没有开启持久化，那么Master是没有数据的，当再次进行数据同步的时候，是会把Slave的数据给清空的，这一点一定要注意。
主从模式
我们再来看一下主从实现的模式：
这样的方式其实就是一主一从，他们的读写就相对比较平均。
再来看下面一种方式：
这种方式就是一主二从，这种方式也是我们实际项目中使用最多的一种复制的模式，就是扩展了我们读的请求，这样的话读请求就可以支持原来的两倍，但是我们并不会构建太多，比如一主多从，构建个十几台甚至几十台Slave，我们是不会这样去做的，因为在内网里面，我们的Master还要做一个主从复制，要给数据同步给其他的Slave，这个过程其实就是一个上传和下载，一点我们的客户端Slave比较多了，这样在使用的过程中他们就会一直占用我们的内网网络的带宽，这样很显然就不是太好，所以我们一般就使用一主二从就可以了，就像你娶老婆一样，娶一个两个还能忙的过来，但如果娶的太多了，就可能忙不过来了。
下面我们再来看一下另外一种树状的模式：
这样的话我们就可以看成是两个主从，一个是Master主节点和Slave1与Slave2从节点组成，另一部分是Slave2主和Slave2-1与Slave2-2从。
这样做的目的是因为我们第一部分的主从有一部分同步的压力，这样就可以交给我们第二部分的主从做一个相应的分担，但是这种模式用的也不是很多，简单做个了解就可以了，最常见的还是我们的一主二从模式。