一般而言主从结构都是用来达到高可用的效果,也就是主服务器宕机情况下,马上切换为从服务器来应对.主从结构有很多好处,比如:高可用,读写压力分离; 同时也带来了问题,主从数据可能不一致问题,导致读到脏数据.redis既然支持主从结构,自然也存在这些问题,我们可以看看redis是怎么解决这些问题的.
原理说明:正常主从同步结构,从节点只要执行 replicaof命令即可
说明:其中一台salve掉线或者挂机了(一般来说,主从在一个网段内,掉线可能性不大,很大概率是宕机了),这个
时候master新接受的日志无法发送给这个slave,导致主从同步延时,master会临时将新接受的命令放入
repl_backlog_buffer(环形缓冲区),master_repl_offset会随着请求增多不断增
长,slave_repl_offset记录的是slave同步的位置,等待salve网络恢复,将剩余日志继续同步.
说明:主从结构一般就是为了预防master宕机情况,那么就涉及选择新master,重新同步问题.redis中是利用哨兵来
选举新master,选举过程大概就是先排除网络差的节点,然后根据节点配置的优先级,再判断同步进度,最后就是
找到最早上线的也就是ID最小的.选举完成后,通知slave开始全量数据同步. 这里有个特殊情况,就是master
可能是压力太大假死情况,导致发生脑裂(两个master),数据丢失.
1.对缓存依赖比较高的应用,因为缓存宕机,会引发雪崩,击穿,穿透,而且持久化恢复也需要时间 2.缓存压力比较大的情况,可以做到读写分离,减轻压力 3.数据写量太大,需要考虑分片集群部署.否则主从结构的一些问题会放大,比如脑裂问题,缓行缓冲区写满 导致主从不一致问题,持久化RDB数据量大影响性能等问题
