reids的主从复制(Master/Slave)读写分离

1、什么是主从复制？

主机数据更新后根据配置和策略，自动同步更新到备机的master/salve机制，master以写为主，Salve以读为主。

2、主要作用？

为了满足数据的高可用性。

• 读写分离。当我们有多台redis服务器的时候，肯定有一台主服务器，和多台从服务器，一般来说主机负责写，从机负责读。
• 容灾恢复，有了主从复制，如果遇到突发状况，主机的服务器炸了，那么我们从机中的数据并不会丢失。

3、怎么使用？

3、1 配置

1、配置：配从(从机)不配主（主机）
2、从机配置：使用 slaveof 主机ip主机端口号，每次master断开之后，都需要重新使用这个命令连接，除非已经配置进redis.conf文件。
3、我们可以创建不同的主机，为了演示方便，我们在同一台虚拟机上进行演示。

• 拷贝多个redis.conf文件
  
• 开启deamonize yes
• PID文件名字
• 指定端口号
• Log文件名字
  
• Dump.rdb名字
  

这样我们就模拟了多台虚拟机。

3、2 常用的三个情况

3、2、1 一主二仆

我们配置好之后，进入redis，使用info replcation可以查看默认信息。

此时我们使用命令 SLAVEOF 127.0.0.1 6379，让从机挂载在主机上

几个问题

• 切入点问题？slave1、slave2是从头开始复制还是从切入点开始复制?比如从k4进来，那之前的123是否也可以复制
  我们实验得知，从机挂载到主机上后，会先全局复制主机的数据，也就是第一次就直接获取到了主机的所有数据，在之后就是增量复制，主机新增的数据，也会同步复制到从机
• 从机是否可以写？set可否？
  不可以，我们可以发现，如果从机使用写操作，会报错
• 主机shutdown后情况如何？从机是上位还是原地待命
  
• 主机又回来了后，主机新增记录，从机还能否顺利复制？
  
• 其中一台从机down后情况如何？依照原有它能跟上大部队吗？

从机down后，重新连接，它就变为主机了，如果我们在配置文件中写死，那么重新连接仍然可以是指定主机的从机。否则我们只能使用命令重新连接。

3、2、2 薪火相传

上一个slave可以是下一个slave的Master，slave同样可以接收其他slaves的连接和同步请求，那么该slave作为链条中下一个的master，可以有效的减轻master的写压力

我们将80端口挂载在79上，然后81挂载在80上，这样就形成了一个链条。由图可以知道，slave可以有slave，但是slave永远只能是slave，不会因为有了自己的slave就可以有写操作(即使主机挂掉，仍然处于等待状态，不会自动转为主机)。
注意点：
中途变更转向：会清除之前的数据，重新拷贝最新的数据。

3、2、3 反客为主

我们可以使用slaveof no one 停止当前从机和主机的主从关系，然后本机就从slave的身份转为master

4、 复制的原理

• Slave启动成功连接到master后会发送一个sync指令
• master接到命令启动后台的存盘集成，同时收集所有接收到的用于修改数据集的命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，以完成一次完全同步
• 全量复制：而slave服务在接收到数据库文件的数据后，将其存盘并加载到内存中
• 增量复制：Master继续将新的所有收集到的修改指令依次传给slave，完成同步，但是只要是重新连接master，一次同步(全量复制)将被自动执行。

5、哨兵模式

5、1 什么是哨兵模式?

是反客为主的自动版，如果我们的主机发生故障，段时间内不能恢复，而我们又需要写的操作，那么我们就可以使用一个机制，能够自动监控主机是否出现故障，如果故障了，我们可以根据投票数，自动把从机转换为主机。

5、 2 怎么用？

我们继续按照我们之前的配置来进行

• 调整结构，6379 主机，80、81都跟着79
• 自定义的/myredis目录下新建的sentinel.conf文件，名字不能错
• 配置哨兵，填写配置
  • sentinel monitor 被监控数据库的名字(自己起个名字) 127.0.0.1 6379 1
    
  • 最后的1代表主机挂掉后slave投票看看让谁当主机，得票数高于多少成为主机
• 启动哨兵，redis-sentinel /myredis/sentine.conf（这个目录按照自己的写，并非写死的），出现下图表示启动成功
  
• 正常的主从演示
• 原有的master挂了，使用info replication查看信息
  
  

问题探究
如果原老大重新回归，新老大会让位？还是当光杆司令？
都不是，实践后发现很残酷，原老大回来也只能当新老大的小弟。

6、复制的缺点

复制延时：由于所有的写操作都是子啊master上操作的，然后同步跟新到slave上，所以master同步到slave机器上有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，slave机器数量的增加也会让这个问题更加严重。