主从复制、主从同步(解决高并发读的问题)

主从同步原理：

1.全量同步

slave（从节点）每次请求数据同步会带两个参数：replid和offset。

        replid：第一次请求同步时，replid和master的replid不一样，这时主节点就知道当前从节点是第一次来。就把自己的版本信息（包括master的replid）发送给从节点，从节点保存主节点的replid，下一次就发这个主节点的replid。就知道当前节点是哪个主节点的从节点。

        注意：如果从节点不是第一次来了，主节点就不会发送RDB文件。而是通过repl_backlog文件去同步数据。

        offset：从节点每次同步信息，就会维护一个偏移量offset。比如说这次从节点保存到了第50条数据，offset就为50。主节点的信息不断再更新。下次再来同步的时候，发现主节点中的offset是80，说明这次我们就需要同步50-80的数据了！

2.增量同步

 哨兵模式(解决高可用)、集群脑裂

哨兵的作用

哨兵如何选择新的主节点

说明：

1.判断主节点和从节点断开时间长短，如果某个从节点断开时间很长，就不会被选为主节点。(断开时间越长，从节点丢失数据越多)

2.slave-priority可以在配置文件中设置

3.offset值越大代表当前从节点越接近主节点的数据。

脑裂问题

例：现在由于网络原因，哨兵监测不到主节点了。就会从剩余从节点中选取一个作为主节点。但是原来的主节点没有宕机，RedisClient连接的还是老的主节点。这样就出现了两个主节点！现在客户端连接的是老的主节点，还会持续往里面写入数据，但是从节点已经同步不了数据了！

现在网络恢复了，哨兵会将老的主节点降级为从节点。并且把新的主节点中的数据同步给它，而它之前的数据会被清空！！！客户端写入的数据就丢失了。

解决方案

配置参数

1.第一个参数min-replicas-to-write表示：当客户端写入数据时，这个主节点至少要有一个从节点。才能接受客户端的数据，否则直接拒绝请求。

2.min-replicas-max-lag：主从数据同步延迟

小结