Redis 主从:
单节点 redis 服务处理高并发能力有限,可以使用主从集群实现数据读写分离提高 redis 服务高并发处理能力,一般实现一主多从,主节点负责写数据,并将数据同步给从节点,从节点负责读数据
确定主节点与从节点信息:在从节点配置文件中配置 replicaof 主节点ip 主节点端口号
主从数据同步流程:
1. 从节点向主节点发送同步数据请求,并发送主节点的 run id 和 offset 信息
2. 主节点接受到请求信息后,先判断一下 run id(运行Id)是不是自己
2.1 如果不是自己的 run id ,表是当前节点第一次过来同步数据需要全量数据同步,主节点先将自己的 run id、offset 、版本信息等数据发送给从节点 ,从节点保存主节点信息 ,然后主节点执行 bgsave 指令将缓存数据保存到 rdb 文件中,然后将 rdb 文件发送给从节点,从节点接受到文件后清空本地缓存数据,加载 rdb 文件将数据缓存到内存中,在主节点创建 rdb 文件至发送 rdb 文件时间段内,可能会处理新的指令并将新指令写入缓存区中,然后发送给从节点,从节点接受并执行指令,现在主从节点的数据就一致了,后续主节点执行指令后会将指令发送给从节点
2.2 如果是自己 run id , 表示不是第一次同步数据只用增量同步数据,主节根据从节点发送的 offset 信息与自己的 offset 比较,获取未同步的数据发送给从节点,
注意:主节点的 offset 会随着缓存区中数据增多变大,缓存区: replication_backlog_buffer
Redis 哨兵集群:
使用主从集群如果出现主节点宕机,导致数据不能写入问题,需要手动选择一个从节点做为新的主节点,但是这样做不能保证服务高可用,所以使用哨兵机制监测主从节点 自动故障恢复、通知信息
如果主节点服务出现故障,哨兵会自动在从节点中选择一个做新的主节点,并通知客户端更改信息访问新的主节点,等老的主节点重启后会变成从节点同步新的主节点信息
哨兵选举机制:1. 从节点优先级 2. 从节点 offset 值的大小 3. 运行id
注意: 从节点的 offset 值的大小,offset 值越大说明从节点与主节点中的数据越接近数据越完整
哨兵集群脑裂问题:
使用哨兵监测主从节点,可能因为网络抖动出现 脑裂 问题,例如, 一段时间内有超过半数的哨兵节点无法检测到主节点心跳,客观的认为主节点已经故障,在剩下的从节点中选择一个新的主节点,实际上老主节点并没有故障还在处理请求信息,等一段时间老的主节点重新连接上哨兵,会被哨兵强制为 从节点向新的主节点同步数据并将自己的数据清空,导致数据丢失问题,
解决方案:可以在文件中配置从节点最小连接数与数据同步间隔时间,如果不满足配置信息拒绝接受新数据
分片集群:
哨兵加主从群集虽然能满足大量数据下高可用,但是海量数据还是会出现redis 读写数据性能问题,为了解决海量数据 redis 数据读写瓶颈,只能多加几组主从集群提高读写效率,但是在写数据时,会出现数据不知道要存放到那个主节点问题,此时可以使用集群分片解决问题
客户端存数据时,可以根据 key 做分片算法将数据映射到某个主节点保存数据,目前主流做法将整个集群分为 16384 个 hash 槽, 随后把 16384 个hash槽分段给每个主从节点,在存数据时先将 key 进行 hash 计算拿到 hash 值,然后与16384 进行取模再判断当前 key 落到那个区间,可以找到对应的主节点保存数据
分片集群虽然解决了海量数据读写问题,也引出了新的问题,比如再写数据时发现某个主节点故障,导致某一个区间的数据无法保存,这时需要一个监控机制 帮助集群故障恢复,目前主流解决方案,让每个主节点相互监测,当多个主节点发现某个主节点,在一段时间内没有发送心跳信息就将其标注为故障,如果有一半以上的主节点将其标注,客观认为该主机点已经故障,便从故障主从集群中投票选举一个从节点作为新的主节点,同时通知其它机器新主节点的信息