好看的ui网站页面设计做网站的费用

58主从复制之一主二仆

主机端口6379 从机端口6380，6381

配置文件固定写死后的主从问题：

1. 从机可以执行写命令吗? 否
2. 从机切入点问题

        slave是从头开始复制还是从切点开始复制?
        master启动,写到k3
        slave1跟着master同时启动,跟着写到k3

        slave2写到k3后才启动,那之前的是否也可以复制? 是的,首次一锅端,后续跟随,master写,slave跟

3.主机shutdown后,从机会上位吗?

        不会，连接的还是主机，只是显示连接断了。
4. 主机shutdown后,重启后主从关系还在吗?从机还能否顺利复制?

        主机重启之后，主从关系还在，从机照旧复制。
5. 某台从机down后,master继续,从机重启后它能跟上大部队吗?

        可以跟上大部队，会将之前的数据全部复制过来。

命令操作手动指定的主从问题：

在从机停机去掉配置文件中的配置项,重新启动配置文件。则3台目前都是主机状态,各不从属

预设的从机上执行命令

        slaveof 新主库IP新 主库端口  指定新连接的主机

        若命令使用后,2台从机重启后,关系还在吗?不在了。这是临时命令，仅单次生效，重启后就没了。

配置VS命令的区别：

• 配置,持久稳定
• 命令,当次生效

59 redis主从复制之薪火相传

上一个slave可以是下一个slave的master【但依然不能实现写操作】,slave同样可以接收其他slaves的连接和同步请求,那么该slave作为了链条中下一个的master,可以有效减轻主master的写压力
中途变更转向:会清除之前的数据,重新建立拷贝最新的slaveof 新主库IP新主库端口

60 redis主从复制之反客为主

从机执行SLAVEOF no one使当前数据库变为主机,但之前复制的数据还在

61 redis主从复制之工作流程总结【面试】

slave启动,同步初请

slave启动成功连接到master后会发送一个sync命令
slave首次全新连接master,一次完全同步(全量复制)将被自动执行,slave自身原有数据会被master数据覆盖清除

首次连接,全量复制

master节点收到sync命令后会开始在后台保存快照(即RDB持久化,主从复制时会触发RDB),同时收集所有接收到的用于修改数据集命令缓存起来,master节点执行RDB持久化完后,master将rdb快照文件和所有缓存的命令发送到所有slave,以完成一次完全同步
而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中,从而完成复制初始化

心跳持续,保持通信

master发出PING包的周期,默认是10秒。检测从节点的存活状态

进入平稳,增量复制

Master继续将新的所有收集到的修改命令自动依次传给slave,完成同步

从机下线,重连续传

若从机down了，主机不会因为从机宕机而停止处理命令，它会继续接收客户端请求并写入数据。master会检查backlog里面的offset,master和slave都会保存一个复制的offset还有一个masterId，offset是保存在backlog中的。Master只会把已经复制的offset后面的数据复制给Slave,类似断点续传

当从节点（slave）宕机后，主节点（master）仍会继续处理写操作，并将命令日志保存在 replication backlog 中。

主从复制使用一个 复制偏移量（offset） 来记录数据同步位置。
主节点会保留一份写操作的历史数据，供从节点在恢复后进行“断点续传”。
如果从节点重新上线时，它携带自己的 offset 和上次连接的 masterId 发起同步请求，主节点会根据 offset 判断是否可以进行 部分重同步（PSYNC）。

若主节点的 backlog 中仍包含从节点缺失的数据，主节点将仅发送缺失部分，避免全量同步，极大提升性能。

62 redis主从复制之痛点和改进需求

复制延时,信号衰减：由于所有的写操作都是先在Master上操作,然后同步更新到Slave上,所以从Master同步到Slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave机器数量的增加也会使这个问题更加严重。

master挂了如何办?从机原地待命默认情况下,不会在slave节点中自动重选一个master
        那每次都要人工干预? 是的，从剩余的从机中选择新的msater