redis：主从复制

redis：主从复制

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

slave以读为主

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qIZ3YNIG-1651919097704)(C:\Users\lcarus，\Documents\笔记\picture\屏幕截图 2022-04-27 140811.png)]

优势：

1、读写分离，分担服务器压力，一个写，另外的其他读

• 读 *** 作：主库、从库都可以接收；

• 写 *** 作：首先到主库执行，然后，主库将写 *** 作同步给从库。

  那么，为什么要采用读写分离的方式呢？

  你可以设想一下，如果在上图中，不管是主库还是从库，都能接收客户端的写 *** 作，那么，一个直接的问题就是：如果客户端对同一个数据（例如k1）前后修改了三次，每一次的修改请求都发送到不同的实例上，在不同的实例上执行，那么，这个数据在这三个实例上的副本就不一致了（分别是v1、v2和v3）。在读取这个数据的时候，就可能读取到旧的值。

  如果我们非要保持这个数据在三个实例上一致，就要涉及到加锁、实例间协商是否完成修改等一系列 *** 作，但这会带来巨额的开销，当然是不太能接受的。

2、容灾的快速恢复，一台从宕机，其他能继续，一主多从

配置：

1、mkdir myredis

2、在myredis中复制一个redis.conf

3、创建其他三个配置文件：一主三从

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-T2xVIjas-1651919097706)(C:\Users\lcarus，\Documents\笔记\picture\12314214.png)]

如果redis配置了密码需要在从库的conf里添加
masterauth 密码 不然配置从库的时候从库显示有主库 主库却看不见从库

4、启动三个redis服务

redis-server redis1.conf redis-server redis2.conf redis-server redis3.conf

ps -ef | grep redis 查看情况

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JrA36L1m-1651919097707)(C:\Users\lcarus，\Documents\笔记\picture\主从3.png)]

启动成功

连接redis-cli -p 6379 redis-cli -p 6380 redis-cli -p 6381

info replication 查看主从情况

配从不配主：

Linux本机ip：192.168.198.129

slaveof 【主机的ip】【主机的port】

数据同步：

主从库间数据第一次同步的三个阶段

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DUdiEv6L-1651919097707)(C:\Users\lcarus，\Documents\笔记\picture\主从数据同步.webp)]

第一阶段是主从库间建立连接、协商同步的过程，主要是为全量复制做准备。

• runID，是每个Redis实例启动时都会自动生成的一个随机ID，用来唯一标记这个实例。当从库和主库第一次复制时，因为不知道主库的runID，所以将runID设为“？”。
• offset，此时设为-1，表示第一次复制。
• 这里有个地方需要注意，FULLRESYNC响应表示第一次复制采用的全量复制，也就是说，主库会把当前所有的数据都复制给从库。

第二阶段，主库将所有数据同步给从库。从库收到数据后，在本地完成数据加载。这个过程依赖于内存快照生成的RDB文件。为了避免之前数据的影响，从库需要先把当前数据库清空。

在主库将数据同步给从库的过程中，主库不会被阻塞，仍然可以正常接收请求。否则，Redis的服务就被中断了。但是，这些请求中的写 *** 作并没有记录到刚刚生成的RDB文件中。为了保证主从库的数据一致性，主库会在内存中用专门的replication buffer，记录RDB文件生成后收到的所有写 *** 作。

最后，也就是第三个阶段，主库会把第二阶段执行过程中新收到的写命令，再发送给从库。具体的 *** 作是，当主库完成RDB文件发送后，就会把此时replication buffer中的修改 *** 作发给从库，从库再重新执行这些 *** 作。这样一来，主从库就实现同步了。

一主多仆：

1：主机上可写可读，从机上只能读

2：主机挂掉，重启就行，从机（不会变成主机） 并且显示主机状态为down 等主机恢复之后 主机就还是主机 从机也还是从机

3：从机重启需重设：slaveof 127.0.0.1 6179，不然从机就会变回主机

4：挂掉之后重新配置回从机时 会把主机数据从头到尾复制连接

当从连接上主服务器之后，从服务器向主服务发送进行数据同步消息

主服务器接到从服务器发送过来的同步消息，把主服务器数据进行持久化，

rdb文件，把rdb文件发送给从服务器，从服务器拿到rdb进行读取

主从库间网络断了怎么办？

在Redis 2.8之前，如果主从库在命令传播时出现了网络闪断，那么，从库就会和主库重新进行一次全量复制，开销非常大。

从Redis 2.8开始，网络断了之后，主从库会采用增量复制的方式继续同步。听名字大概就可以猜到它和全量复制的不同：全量复制是同步所有数据，而增量复制只会把主从库网络断连期间主库收到的命令，同步给从库。

当主从库断连后，主库会把断连期间收到的写 *** 作命令，写入replication buffer，同时也会把这些 *** 作命令也写入repl_backlog_buffer这个缓冲区。

repl_backlog_buffer是一个环形缓冲区，主库会记录自己写到的位置，从库则会记录自己已经读到的位置。

对主库来说，对应的偏移量就是master_repl_offset。主库接收的新写 *** 作越多，这个值就会越大。

同样，从库在复制完写 *** 作命令后，它在缓冲区中的读位置也开始逐步偏移刚才的起始位置，此时，从库已复制的偏移量slave_repl_offset也在不断增加。正常情况下，这两个偏移量基本相等。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SNcTSJiR-1651919097708)(C:\Users\lcarus，\Documents\笔记\picture\offset.webp)]

主从库的连接恢复之后，从库首先会给主库发送psync命令，并把自己当前的slave_repl_offset发给主库，主库会判断自己的master_repl_offset和slave_repl_offset之间的差距。

在网络断连阶段，主库可能会收到新的写 *** 作命令，所以，一般来说，master_repl_offset会大于slave_repl_offset。此时，主库只用把master_repl_offset和slave_repl_offset之间的命令 *** 作同步给从库就行。

不过，有一个地方我要强调一下，因为repl_backlog_buffer是一个环形缓冲区，所以在缓冲区写满后，主库会继续写入，此时，就会覆盖掉之前写入的 *** 作。如果从库的读取速度比较慢，就有可能导致从库还未读取的 *** 作被主库新写的 *** 作覆盖了，这会导致主从库间的数据不一致。

如果它配置得过小，在增量复制阶段，可能会导致从库的复制进度赶不上主库，进而导致从库重新进行全量复制。所以，通过调大这个参数，可以减少从库在网络断连时全量复制的风险。

薪火相传：

通过分析主从库间第一次数据同步的过程，你可以看到，一次全量复制中，对于主库来说，需要完成两个耗时的 *** 作：生成RDB文件和传输RDB文件。

如果从库数量很多，而且都要和主库进行全量复制的话，就会导致主库忙于fork子进程生成RDB文件，进行数据全量同步。fork这个 *** 作会阻塞主线程处理正常请求，从而导致主库响应应用程序的请求速度变慢。此外，传输RDB文件也会占用主库的网络带宽，同样会给主库的资源使用带来压力。那么，有没有好的解决方法可以分担主库压力呢？

其实是有的，这就是“主-从-从”模式。

比如6380是6379的从机 slaveof 127.0.0.1 6379
6381是6380的从机 slaveof 127.0.0.1 6380

特点：上一个Slave可以是下一个slave的Master，Slave同样可以接收其他 slaves的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险

优点：减少压力
缺点：其中一个挂了，后面的都没了

反客为主：

这是当主机挂了之后，在从机设计slaveof no one 这个从机 会变成主机

但是变成的只是普通主机 如果是薪火相传的话他的从机还是他的从机

其他和他并列的从机不会变成他的从机

哨兵模式：

哨兵主要负责的就是三个任务：监控、选主（选择主库）和通知。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Kk4N0tjg-1651919097709)(C:\Users\lcarus，\Documents\笔记\picture\哨兵.webp)]

监控是指哨兵进程在运行时，周期性地给所有的主从库发送PING命令，检测它们是否仍然在线运行。如果从库或主库没有在规定时间内响应哨兵的PING命令，哨兵就会把它标记为“下线状态”；

主机的监控：

一旦哨兵判断主库下线了，就会开始选择新主库，并让从库和新主库进行数据同步，这个过程本身就会有开销，例如，哨兵要花时间选出新主库，从库也需要花时间和新主库同步。而在误判的情况下，主库本身根本就不需要进行切换的，所以这个过程的开销是没有价值的。正因为这样，我们需要判断是否有误判，以及减少误判。

那怎么减少误判呢？在日常生活中，当我们要对一些重要的事情做判断的时候，经常会和家人或朋友一起商量一下，然后再做决定。

哨兵机制也是类似的，它通常会采用多实例组成的集群模式进行部署，这也被称为哨兵集群。引入多个哨兵实例一起来判断，就可以避免单个哨兵因为自身网络状况不好，而误判主库下线的情况。同时，多个哨兵的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低。

监控主机是否down，如果是，就将从机选择一个， 选主：

检查从库的当前在线状态，还要判断它之前的网络连接状态，筛出连接不稳定的，过滤掉了不适合做主库的从库，接下来就要给剩余的从库打分了。

第一轮：优先级最高的从库得分高。

用户可以通过slave-priority配置项，给不同的从库设置不同优先级。

第二轮：和旧主库同步程度最接近的从库得分高。

第三轮：ID号小的从库得分高。

以前“并列的从机”以及“以前的主机”变成它的从机。

首先前提是一主二从，二从是并列的而不是薪火相传
下面开始实战测试

1. 在myredis下再建一个配置文件 sentinel.conf

2. 打开 sentinel.conf配置，在里面添加 sentinel monitor mymaster 127.0.0.1 6379 1

   其中mymaster为监控对象起的服务器名称，1 为至少有多少个哨兵同意迁移（只要有一个哨兵同意即可迁移）。

3. 再添加sentinel auth-pass mymaster 1226136238

4. redis-sentinel sentinel.conf 启动哨兵模式

5. 关掉6379端口的主机

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DMv8Wv21-1651919097709)(C:\Users\lcarus，\Documents\笔记\picture\哨兵.png)]

哨兵模式总结

当主服务器down机时，新服务器选举是有策略的
选择条件从上到下依次
1.选择优先级靠前的
优先级在redis.conf中默认：replica-priority 100，值越小优先级越高
2.选择偏移量最大的
偏移量是指获得原主机数据最全的
3.选择runid最小的从服务
每个redis实例启动后都会随机生成一个40位的runid
19097709)]

哨兵模式总结

当主服务器down机时，新服务器选举是有策略的
选择条件从上到下依次
1.选择优先级靠前的
优先级在redis.conf中默认：replica-priority 100，值越小优先级越高
2.选择偏移量最大的
偏移量是指获得原主机数据最全的
3.选择runid最小的从服务
每个redis实例启动后都会随机生成一个40位的runid