一般来说,如果你需要提高 Redis 单机的读写性能和容量,可以考虑扩大 Redis 实例的配置(如内存大小),或者升级服务器硬件(如 CPU、内存、硬盘等)。这种方式相对简单,但通常需要停机维护才能进行。
此外,还有一种不需要停机维护的 Redis 扩容方案:Redis 数据拆分。它将原本存放在单个 Redis 实例中的数据拆分成多个部分,分布在不同的 Redis 实例中。这种方式可以通过增加 Redis 实例的数量来提高系统的性能和容量。但是,它需要额外的工作来维护数据的一致性,并且需要更多的网络开销。
总之,Redis 单机扩容的效果取决于具体情况,需要根据实际需求和资源情况来选择适合自己的方案。主从切换技术的方法是:当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用。 这不是一种推荐的方式,更多时候,我们优先考虑 哨兵模式 。
一、哨兵模式概述
哨兵模式是一种特殊的模式,首先Redis提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行。其原理是 哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例。
Redis哨兵
这里的哨兵有两个作用
通过发送命令,让Redis服务器返回监控其运行状态,包括主服务器和从服务器。
当哨兵监测到master宕机,会自动将slave切换成master,然后通过 发布订阅模式 通知其他的从服务器,修改配置文件,让它们切换主机。
然而一个哨兵进程对Redis服务器进行监控,可能会出现问题,为此,我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控,这样就形成了多哨兵模式。
用文字描述一下 故障切换(failover) 的过程。假设主服务器宕机,哨兵1先检测到这个结果,系统并不会马上进行failover过程,仅仅是哨兵1主观的认为主服务器不可用,这个现象成为 主观下线 。当后面的哨兵也检测到主服务器不可用,并且数量达到一定值时,那么哨兵之间就会进行一次投票,投票的结果由一个哨兵发起,进行failover *** 作。切换成功后,就会通过发布订阅模式,让各个哨兵把自己监控的从服务器实现切换主机,这个过程称为 客观下线 。这样对于客户端而言,一切都是透明的。
二、Redis配置哨兵模式
配置3个哨兵和1主2从的Redis服务器来演示这个过程。
服务类型是否是主服务器IP地址端口
Redis是192168111286379
Redis否192168111296379
Redis否192168111306379
Sentinel-1921681112826379
Sentinel-1921681112926379
Sentinel-1921681113026379
多哨兵监控Redis
首先配置Redis的主从服务器,修改redisconf文件如下
上述内容主要是配置Redis服务器,从服务器比主服务器多一个slaveof的配置和密码。
配置3个哨兵,每个哨兵的配置都是一样的。在Redis安装目录下有一个sentinelconf文件,copy一份进行修改
上述关闭了保护模式,便于测试。
有了上述的修改,我们可以进入Redis的安装目录的src目录,通过下面的命令启动服务器和哨兵
注意启动的顺序。 首先是主机(19216811128)的Redis服务进程,然后启动从机的服务进程,最后启动3个哨兵的服务进程。
三、Java中使用哨兵模式
上面是通过Jedis进行使用的,同样也可以使用Spring进行配置RedisTemplate使用。
四、哨兵模式的其他配置项
sentinel down-after-milliseconds配置项只是一个哨兵在超过规定时间依旧没有得到响应后,会自己认为主机不可用。对于其他哨兵而言,并不是这样认为。哨兵会记录这个消息,当拥有认为主观下线的哨兵达到sentinel monitor所配置的数量时,就会发起一次投票,进行failover,此时哨兵会重写Redis的哨兵配置文件,以适应新场景的需要。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)