Redis 读写分离/主从复制介绍
背景实现项目开展的过程中，我们的数据是非常重要的；假如我们存储在redis中的数据，redis服务这时候宕机了，在不影响客户的使用体验时，我们就需要有多个备用机器，其实真实的业务场景也是这样。不能是redis的一台机器挂掉后，就不能提供服务，为了防止上诉情况的出现，这时候我们就是使用到了redis的另外一项技术，reids的读写分离和主从复制的知识。
什么是主从复制读写分离？其实就是我们上面说到的，我们可以给redis部署多个服务，即使有一台redis的服务挂掉但是我们的项目依旧不受其影响，照样还是可以正常的使用redis的服务。首先我们可以是有一台作为redis的主机，然后分配多个从机；为了保证数据的统一性主机最主要的功能就是写操作，而从机备份主机的数据，这样一样如果说我们的主机意外的挂掉，但是从机依旧能提供服务，数据都还是相同的。
下面就介绍几个常用的读写分离/主从复制的案例
下面几个实验我们就准备三台redis服务器（实则为一台机器上，起了三个不同的服务），然后就通过不同的方式来演示，redis怎么去实现数据的读写分离，主从复制备份的。
一、传统方式（一主多从中心化提供服务）
多台redis服务器的创建；首先我们可以新建一个文件夹，专门来存放这些启动的文件；我们复制原始的redis.conf文件，复制两份，文件名分别为redis6380.conf，redis6381.conf作区分，最后通过更改配置文件，分别启动三个不同的redis服务。
我这里在redis的安装目录下，建了一个myredis文件夹，在myredis文件夹分别复制了两份redis.conf文件，复制完成后接下来就是修改配置文件；配置文件主要更改的信息有：
1.开启daemonize yes 守护进程开启；
2.指定pid的名字；
3. 指定端口；
4. 修改log文件名；
5. 修改dump.rdb文件名；
三个文件都按照各自的配置文件信息，更改。
接下来分别启动三个服务，一定要使用不同的配置文件启动，这里不能使用默认的启动方式，默认的启动方式都是找的默认的redis.conf配置文件启动的。启动命令：redis-server myredis/redis.conf ....如果启动80端口，redis-server myredis/redids6380.conf 后面6381一样，启动完成后，连接客户端测试是否成功；命令：redis-cli -p 端口号。一定是指定的端口号，默认的也是找的6379；
分别启动三台服务，并测试连接：
三台log信息同时打印出来；
三个服务同时启动后，现在各个服务之间是没有任何联系的；这里准备将80，81数据库作为从库。
在redis中设置主从有两种方式：
1.在reids.conf配置文件中设置slaveof；
语法：slaveof <masterip> <masterport>
配置文件中默认的是注释掉的；
2.在使用redis-cli客户端连接时直接写连接的信息
语法：slaveof <masterip> <masterport>
第一种是配置在配置文件中，每次启动时不用重新再配置，而第二种在服务被关闭或者宕机后就不会再有连接信息需要重新连接；这里我主要使用第二种，方便后面不同方式的演示，当然我们在生产环境上，防止出现宕机连接信息抹掉的问题，可以直接配置在配置文件中。
我们首先打印一下现在每台服务器的角色；通过命令：info replication
连接主库；
再打印看看主库的信息；
获取主库的信息；
上诉步骤就实现了简单的主从复制，读写分离的案例，这里会涉及到一个弊端就是如果主机挂掉后，连个从机该如何获取信息？
我们来测试一下；如果主机挂掉，两个从机的角色是变成master还是继续保持slave；
通过上面的测试能看到，虽然主机已经挂掉，但是数据我们已经同步下来，即使他挂了我们依旧可以获取数据，在真实的场景中就不怕因为主机的服务挂掉，而就不能提供服务；
主机虽然是挂掉了，正常情况下肯定要尽快的修复，因为两个从机会一直维持他们slave角色，不会有写的操作，这时候我们将主机服务重启后，会是什么样的现象？从机与他之间的联系还在吗？还能继续同步主机写入的数据吗?接着测试
这里是主机挂了，如果从机挂的话，就需要重新连接主机，如果不连接就是我们开头说的直接在配置文件中，修改配置信息；从机连接完成后，第一步肯定就是全量的同步信息，后面的同步新写入的值就是增量同步这个概念；
二、去中心化的实现方式
这里所说的区中心化，就是没有绝对的核心，上面的一主多仆的实现方式就是，围绕这主机来同步数据，有一个弊端就是主机挂掉后，从机只能保存到之前主机没有挂之前的数据，等到主机修复后才能正常的工作。
去中心化的概念，可以想象是他们之间的信息时相互传递的，线性的，不存在多台从机连接到一个主机上，简单的说就是假如我连接的是主机，我现在的角色是slave，后面连接的是通过连接我来获取数据，我相对于他来说就是（master），真实的情况是不是这样，是的角色还是slave；
这时可以测试一下，81取到的数据和80取的的数据是相同的；通过这种方式也能实现主从复制，读写分离；当然这里提到的读写分离可以通过配置文件修改；命令：slave-read-only no 默认的是no，可以修改为yes，但是这里不建议，实现主从复制的目的就是在主服务写数据，而从数据库只用来同部数据读数据；如果从数据库也有写的权限，不方便维护，主数据库还要同步从库数据？所以不建议；
假如这个时候，有10台都是像这种链式的连接方式，主机这时候遇到了不能修复的情况，服务关闭后，后面的是否还能同步到主机的数据？
答案肯定是不能的，这时候我们该如何操作？
这时候我们可以重新命一台从机为主机，将从机的就是从slave变成master；新的主机继续继承“退休”主机的工作；
怎么将从机角色更改，通过命令：slaveof no one；简单的测试一下
可以通上面的方式，来将从机变成主机，继续提供服务；如果这个时候，原来的6379主机经过一番修复又能使用了，这时候，6380主机会继续“俯首称臣”吗？
答案是不会，他们之间是没有任何关系了，即使修复了，但是没有任何关联；我们发现这种方式也不是特别稳妥的，如果在没人的时候主机的服务宕机了，redis也不会自己将从机更改成主机，继续服务；有没有一种好的，更加智能的方式来实现呢？答案肯定是有的，并且一般得互联网公司都会采用这种方式，更加智能；下面就通过实际的案例介绍一下，更加智能化的实现形式。
三、（sentinel）哨兵模式
顾名思义；大概能猜出来个一二，哨兵模式就是通过后台的自动检测，如果后台的主机出现了问题，不能正常的提供服务后，会从从机里通过“投票”的方式，选出新的主机。继续继承主机的工作，提供服务。
下面就演示一下哨兵模式是怎么工作的；
首先我们需要在配置文件夹下建立一个新的文件，sentinel.conf，然后再文件中填写需要监控的主机（配置文件可以同时监控对台主机）；配置如下
#语法 sentinel monitor 监控reids主机名 -h（host） - p（port） 1（投票数量）
配置文件填写完成后，保存。在安装目录下有通过sentinel启动方式，使用命令：redis-sentinel sentinel.conf(配置文件位置)
启动完成后，分别将79，80，81服务启动，其中79为主机；
我们将主机这时候关闭；让其公平选举出下一位“继承者”；
通过打印信息，这时候81已经成为了主机；而在刚才sentinel启动的log信息中，也可以追溯到这一过程；
选择了新的主机；整个过程就相当于我们前面说的，第二种方式，从机将自己改变成主机（slaveof no one），而哨兵模式是在监控下，自动完成这一工作。使用哨兵模式，减少了我们自己的工作量；也是更加智能稳妥的方式去实现主从复制，和读写分离。
复制的原理（过程）
我们知道了，复制的几种方式，好像是会操作了，那究竟是一个怎么样的过程？
首先在slave启动成功后，会主动根据配置信息连接到主机，会向master发送sync命令，master接到命令后，启动后台存盘进程，同时收集所有接收到的用于修改数据集命令，在后台执行完毕后，master将传送整个数据到slave，完成一次全量复制，后续的更改master会收集所有的命令一次传给slave，完成同步操作。