要保证Redis不会挂掉,也就是提高Redis的高可用性,可以从这么几个方面考虑。
集群式部署方式Redis单副本:也就是只部署一台Redis,不需要节点之间的数据同步,架构简单,部署方便;但是单台机器毕竟是有风险的,按照题目中【海量数据】的场景,是不能达到高可用要求的。
Redis主从:主从实例可以部署在不同的物理服务器上,充分利用多台服务器的资源,在主库发生故障的时候,可以进行主备切换,从而保证系统的稳定运行,甚至可以做到读写分离,主库专门用作写操作,一台或多台备库进行读操作;但是当主库发生故障的时候(如果没有HA方案的话),是需要手动进行主备切换的。
Redis Sentinel:部署架构分为两部分【Sentinel集群】和【数据集群】;Sentinel集群是由多个Sentinel节点组成的分布式集群,通常是2N+1台服务器,可以实现故障发现和转移、客户端通知等功能;数据集群用于存储数据;它能够解决主从模式下的自动切换问题,并且数据集群是可以横向扩展的;当然这个架构实现和部署起来,也更为复杂一些;并且这个架构不能做到读写分离。
Redis Cluster:Redis 3.0集群,是分布式集群解决方案之一,物理架构中配置2N个节点(主从一一对应),主节点提供读写操作,从节点作为备份;数据分布保存在多个节点上,是一种无中心的架构,如果有部分节点发生故障,能够实现故障自动转移和切换,用投票机制完成备库升级为主库(下文的Redis分片章节,还会介绍到Redis Cluster)。
Redis分片Redis在3.0之前只支持单实例,在此之前,在数据量比较大的情况,通常有几种方案可以做到把数据分片保存到多台服务器上。
客户端分片:分片逻辑被放到了客户端上,由客户端根据路由规则,把数据保存不同的Redis实例中,读取的时候也是根据规则,去对应的实例上读取数据;但是当Redis实例数量发生变化的时候(增加实例或减少实例),需要手动地调整分片的规则程序;并且这种部署方式,也增加了运维的成本。
Redis代理组件:在这种架构中,客户端不再直接访问Redis实例,而是访问代理组件,由它管理路由的规则;客户端不需要关心有几个Redis实例,数据被路由到哪个实例上;但是由于在客户端和Redis之间增加了一层代理,多多少少也会产生一些性能上的损耗。
Redis Cluster:上文中提到的Redis 3.0集群,这里对数据的存储和路由方式,再介绍几句:Redis把所有的Key分成了16384个slot,每个Redis实例负责其中一部分slot;每个Redis都知道每个slot在哪个节点上存储(实例节点定期做数据交换);当客户端访问到一个Redis实例的时候,如果数据不在这个实例上,那么会通过重定向命令引导客户端访问数据所在的实例。
热点数据挑战单节点的极限虽然我们已经把数据分散保存到多台Redis实例上了,但是如果有一个热点数据被频繁访问,超过了单实例的服务器极限,那么该如何解决呢?通常的手段就是做读写分离,部署多台只读节点,对外提供服务。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解,希望能得到你的关注。Copyright © 广州京杭网络科技有限公司 2005-2024 版权所有 粤ICP备16019765号
广州京杭网络科技有限公司 版权所有