Redis高可用
最近离职后还没开始找工作,在找工作前去学习一下Redis高可用方案。
目录
- Redis高可用
- 高可用的概念
- 实现方式
- 持久化
- 主从复制
- 简单结构
- 优化结构
- 优缺点
- 哨兵模式(Sentinel)
- 哨兵进程的作用
- 自动故障迁移(Automatic failover)
- 优缺点
- 集群
- 优缺点
Redis高可用
高可用的概念
通过尽量缩短日常维护操作和突发的系统崩溃所导致的停机时间,以提高系统和应用的可用性。
实现方式
Redis高可用的实现方式有:
- 持久化
- 主从复制
- 哨兵
- Cluster集群
持久化
通过AOF和RDB实现持久化,服务器宕机后可以快速找回之前的数据,防止大量请求打入数据库,防止服务或系统宕机导致数据丢失。
具体看Redis入门(二)——持久化
主从复制
将一台Redis作为主节点(Master),将上面的数据复制到其他Redis,其他的Redis就是从节点(Slave)。
Master节点提供数据的事务性操作(增删改),Slave只提供读操作。
简单结构
将Slave都挂在Master节点上
优点:
Slave节点与master节点的数据延迟较小
缺点:
Slave节点较多时,Master同步一次数据较久
优化结构
为了提高Master同步数据的效率,只在Master下挂一个Slave节点,其他节点挂载到这个Slave节点上。
通过传递完成数据同步,减少Master性能消耗
优缺点
优点
- 实现读写分离,降低Master的读数据压力,提高系统性能
- 配置简单,容易搭建
缺点
- Master宕机时,无法选择哪台Slave作为新的Master节点,保证不了高可用
- 写压力都集中到Master节点上
哨兵模式(Sentinel)
基于主从复制,解决Master宕机时不知道选择哪台Slave作为新的Master节点。
对每个节点进行监控,Master宕机时通过投票机制选择新的Master节点,并将其他Slave节点连接到新的Master节点。
哨兵进程的作用
监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。
提醒(Notification):当被监控的某个Redis节点出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移(Automatic failover)
当一个Master不能正常工作时,哨兵(sentinel) 会开始一次自动故障迁移操作:
- 将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master;
- Client试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用现在的Master替换失效Master
优缺点
优点
- 保证高可用
缺点
- 中心化集群实现方式,基于主从模式,切换节点时,会发生数据的丢失。
- 集群里所有节点保存的都是全量数据,浪费内存空间,没有真正实现分布式存储。数据量过大时,主从同步严重影响master的性能。
- 数据写的操作都集中在master上,仍然没有解决master写数据的压力。
集群
哨兵实现了高可用,但是每个节点存储的都是相同的内容,浪费内存。同时也没有解决master写数据的压力。
集群模式,能自动将数据进行分片,实现分布式储存,每个节点存储不同的数据。
架构如下:
优缺点
优点
- 无中心架构;
- 数据按照 slot 存储分布在多个节点,节点间数据共享,可动态调整数据分布;
- 可扩展性:可线性扩展到 1000 多个节点,节点可动态添加或删除;
- 高可用性:部分节点不可用时,集群仍可用。通过增加 Slave 做 standby 数据副本,能够实现故障自动 failover,节点之间通过 gossip 协议交换状态信息,用投票机制完成 Slave 到 Master 的角色提升;
- 降低运维成本,提高系统的扩展性和可用性。
缺点
- 节点会因为某些原因发生阻塞(阻塞时间大于 cluster-node-timeout),被判断下线,这种failover是没有必要的
- 数据通过异步复制,不能保证数据一致性
- 多个业务使用同一个集群时,无法根据统计区分冷热数据,资源隔离性较差,容易出现相互影响的情况
- 不支持多数据库空间,单机时可以选择16个数据库,集群只能选择一个数据库,即db0
- key批量操作限制,如mget、mset,目前只支持相同slot值的key执行批量操作,不同的slot不支持跨slot查询