主从复制、主从同步(解决高并发读的问题)
主从同步原理:
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:主从数据同步延迟
小结