浅谈Redis哨兵模式高可用解决方案

目录
  • 一、序言
    • 1、目标与收获
    • 2、端口规划
  • 二、单机模拟
    • (一)服务规划
      • 1、Redis实例
      • 2、哨兵服务
    • (二)服务配置
      • 1、Redis实例
      • 2、哨兵服务
    • (三)服务管理
      • 1、Redis实例
      • 2、哨兵服务
  • 三、客户端整合
    • (一)基础整合
      • 1、全局配置文件
      • 2、集成配置
    • (二)读写分离

一、序言

Redis高可用有两种模式:哨兵模式集群模式,本文基于哨兵模式搭建一主两从三哨兵Redis高可用服务。

1、目标与收获

一主两从三哨兵Redis服务,基本能够满足中小型项目的高可用要求,使用Supervisor监控并管理Redis实例。通过本文将完成如下目标:

  • 哨兵模式服务规划与搭建

哨兵模式服务相比于单机版服务更加可靠,适合读写分离、数据量不是很大、要求可靠稳定性的场景。

  • 客户端整合与读写分离

通过Spring框架对哨兵模式进行连接,完成生产环境的常见操作。

2、端口规划

端口规划是完成本方案的第一步。

二、单机模拟

单机模拟是指在单台物理机或者虚拟机上模拟操作,最大化还原本方案中间过程,适用于学习或者开发阶段使用。

为了简化操作,Redis服务做如下约定:数据不持久化到磁盘;服务实例以前台进程方式运行;节点的配置文件以默认配置文件为模版;无密码验证。

(一)服务规划

1、Redis实例

服务在第一次启动时明确知道第几个节点是master节点,当服务在长期运行并发生主从切换时,无法显示知道第几个节点是master节点,需要通过命令行间接查询。

节点 主机 端口 角色 额外配置
node01 127.0.0.1 6380 第一次启动时作为master服务  
node02 127.0.0.1 6381 第一次启动时作为slave服务 replicaof 127.0.0.1 6380
node03 127.0.0.1 6382 第一次启动时作为slave服务 replicaof 127.0.0.1 6380

额外配置指第一次启动Redis服务实例时,节点配置文件中新增配置。

2、哨兵服务

哨兵服务节点之间没有主从的区别,所有节点处于平等地位。当主服务异常时,哨兵服务之间会唤醒投票策略,从Redis实例从节点选择主服务的候选人。

节点 主机 端口 额外配置
node01 127.0.0.1 26380 sentinel monitor mymaster 127.0.0.1 6380 2
node02 127.0.0.1 26381 sentinel monitor mymaster 127.0.0.1 6380 2
node03 127.0.0.1 26382 sentinel monitor mymaster 127.0.0.1 6380 2

(二)服务配置

1、Redis实例

节点的初始配置文件以默认配置文件为模版。

node01、node02初始化配置文件之后,显示指明节点间的主从关系,增加如下配置:

replicaof 127.0.0.1 6380

2、哨兵服务

节点的初始配置文件以默认配置文件为模版。

node01、node02、node03初始化配置文件后,增加如下配置:

sentinel monitor mymaster 127.0.0.1 6381 2

(三)服务管理

测试或者学习时,建议采用前台进程管理服务,便于模拟单点故障、查看日志观察主从切换。

生产条件下建议使用Supervisor管理服务,不仅易于管理而且能够实现服务异常终止后自动重启。高可用场景下使用的是三台物理机。

1、Redis实例

/usr/local/redis/bin/redis-server /usr/local/redis/conf/ms/redis80.conf --port 6380 --save '' --daemonize no
/usr/local/redis/bin/redis-server /usr/local/redis/conf/ms/redis81.conf --port 6381 --save '' --daemonize no
/usr/local/redis/bin/redis-server /usr/local/redis/conf/ms/redis82.conf --port 6382 --save '' --daemonize no

2、哨兵服务

/usr/local/redis/bin/redis-sentinel /usr/local/redis/conf/ms/sentinel280.conf --port 26380 --daemonize no
/usr/local/redis/bin/redis-sentinel /usr/local/redis/conf/ms/sentinel281.conf --port 26381 --daemonize no
/usr/local/redis/bin/redis-sentinel /usr/local/redis/conf/ms/sentinel282.conf --port 26382 --daemonize no

三、客户端整合

客户端实现是指基于SpringBoot的整合分为两步实现:一是完成作为基础的整合;二是结合生产需要补充新特性。

(一)基础整合

基础整合的内容是以Java客户端连接高可用哨兵模式Redis服务,实现单节点故障服务正常运行的要求。

1、全局配置文件

全局配置文件添加的配置信息有:master参数为哨兵服务名,此处为默认值;nodes参数为哨兵服务列表(不是Redis实例服务列表);database参数为数据库。

spring:
  redis:
    database: 0
    sentinel:
      nodes: 192.168.181.171:26380,192.168.181.171:26381,192.168.181.171:26382
      master: mymaster

2、集成配置

集成进SpringBoot体系,最核心的是创建LettuceConnectionFactory连接工厂,通过Redis连接工厂,能够顺利继承进Spring体系下其他框架。

@Configuration
public class RedisSentinelConfig {
    @Autowired
    private RedisProperties redisProperties;

    @Bean
    public RedisConnectionFactory lettuceConnectionFactory() {
        RedisProperties.Sentinel sentinel = redisProperties.getSentinel();
        HashSet<String> nodes = new HashSet<>(sentinel.getNodes());
        String master = sentinel.getMaster();
        RedisSentinelConfiguration config = new RedisSentinelConfiguration(master, nodes);
        config.setDatabase(redisProperties.getDatabase());
        return new LettuceConnectionFactory(config);
    }
}

(二)读写分离

基础整合仅仅是实现了高可用Redis服务的流程,生产环境下仍需要增加其他配置:修改自定义连接数据库序号;授权连接;连接池配置;读写分离。

在高可用前提下,衍生出读写分离的特性,主库完成写请求;从库完成读请求(从库不允许写)。

@Bean
public LettuceClientConfigurationBuilderCustomizer lettuceClientCustomizer() {
    // 配置读写分离
    return builder -> builder.readFrom(ReadFrom.REPLICA);
}

到此这篇关于浅谈Redis哨兵模式高可用解决方案的文章就介绍到这了,更多相关Redis哨兵模式高可用内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • 5分钟教你实现用docker搭建Redis集群模式和哨兵模式

    如果让你为开发.测试环境分别搭一套哨兵和集群模式的redis,你最快需要多久,或许你需要一天?2小时?事实是可以更短. 是的,你已经猜到了,用docker部署,真的只需要十几分钟. 一.准备工作 拉取redis镜像 运行如下命令: docker pull redis 该命令拉取的镜像是官方镜像,当然你可以搜索其他的镜像,这里不做深入 查看镜像情况: 二.部署redis哨兵主从模式 什么是哨兵模式?--请自行百度 1.什么是docker compose? Docker Compose 可以理解为将

  • Redis Sentinel实现哨兵模式搭建小结

    Redis哨兵模式,用现在流行的话可以说就是一个"哨兵机器人",给"哨兵机器人"进行相应的配置之后,这个"机器人"可以7*24小时工作,它能能够自动帮助你做一些事情,如监控,提醒,自动处理故障等. Redis-sentinel简介 Redis-sentinel是Redis的作者antirez,因为Redis集群的被各大公司使用,每个公司要写自己的集群管理工具,于是antirez花了几个星期写出了Redis-sentinel. Redis 的 Se

  • Redis哨兵模式介绍

    哨兵简介 主机"宕机" 将宕机的 master 下线 找一个 slave 作为 master 通知所有的 slave 连接新的 master 启动新的 master 和 slave 全量复制 *N+ 部分复制*N 存在的问题: 谁来确认 master 宕机了 重新找一个新的 master ,怎么找法? 修改配置后,原来的 master 恢复了怎么办? 哨兵 哨兵(sentinal)是一个分布式系统,用于对主从结构中的每台服务器进行监控,当出现故障时通过投票机制选择新的 master 并

  • 浅谈Redis哨兵模式的使用

    概述 主从切换技术的方法是:当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工 干预,费事费力,还会造成一段时间内服务不可用.这不是一种推荐的方式,更多时候,我们优先考虑 哨兵模式.Redis从2.8开始正式提供了Sentinel(哨兵) 架构来解决这个问题. 谋朝篡位的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库. 哨兵模式是一种特殊的模式,首先Redis提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独 立运行.其原理是哨兵通过发送命令,

  • 浅谈Redis哨兵模式高可用解决方案

    目录 一.序言 1.目标与收获 2.端口规划 二.单机模拟 (一)服务规划 1.Redis实例 2.哨兵服务 (二)服务配置 1.Redis实例 2.哨兵服务 (三)服务管理 1.Redis实例 2.哨兵服务 三.客户端整合 (一)基础整合 1.全局配置文件 2.集成配置 (二)读写分离 一.序言 Redis高可用有两种模式:哨兵模式和集群模式,本文基于哨兵模式搭建一主两从三哨兵Redis高可用服务. 1.目标与收获 一主两从三哨兵Redis服务,基本能够满足中小型项目的高可用要求,使用Supe

  • 浅谈Redis缓存雪崩解决方案

    目录 1.保持缓存层的高可用 2.限流降级组件 3.缓存不过期 4.优化缓存过期时间 5.使用互斥锁重建缓存 6.异步重建缓存 缓存层承载着大量的请求,有效保护了存储层.但是如果由于大量缓存失效或者缓存整体不能提供服务,导致大量的请求到达存储层,会使存储层负载增加(大量的请求查询数据库) .这就是缓存雪崩的场景; 解决缓存雪崩可以从下面的几点着手: 1.保持缓存层的高可用 使用Redis哨兵模式或者Redis集群部署方式,即是个别Redis节点下线,整个缓存层依然可以使用.除此之外还可以在多个机

  • 浅谈Redis 缓存的三大问题及其解决方案

    目录 一.缓存穿透 1. 常见解决方案 2. 布隆过滤器 3. 缓存空数据与布隆过滤器的比较 二.缓存击穿 解决方案 三.缓存雪崩 解决方案 Redis 经常用于系统中的缓存,这样可以解决目前 IO 设备无法满足互联网应用海量的读写请求的问题. 一.缓存穿透 缓存穿透是指缓存和数据库中都没有的数据,而用户不断发起请求,如发起 id 为-1 的数据或者特别大的不存在的数据.有可能是黑客利用漏洞攻击从而去压垮应用的数据库. 1. 常见解决方案 对于缓存穿透问题,常见的解决方案有以下三种: 验证拦截:

  • 浅谈Redis跟MySQL的双写问题解决方案

    目录 写在前面 三种读写缓存策略 Cache-AsidePattern(旁路缓存模式) Read-Through/Write-Through(读写穿透) WriteBehindPattern(异步缓存写入) 旁路缓存模式解析 CacheAsidePattern的一些疑问 CacheAsidePattern的缺陷 项目中有遇到这个问题,跟MySQL中的数据不一致,研究一番发现这里面细节并不简单,特此记录一下. 写在前面 严格意义上任何非原子操作都不可能保证一致性,除非用阻塞读写实现强一致性,所以缓

  • 浅谈Redis缓存击穿、缓存穿透、缓存雪崩的解决方案

    目录 前言 Redis缓存使用场景 Redis缓存穿透 解决方案 1.对空值缓存 2.添加参数校验 3.采用布隆过滤器 Redis缓存雪崩 解决方案 1.大量热点数据同时失效带来的缓存雪崩问题 2. 服务降级 3. Redis 缓存实例发生故障宕机带来的缓存雪崩问题 Redis缓存击穿 解决方案 1. 热key不过期 2. 分布式锁 总结 缓存击穿 缓存穿透 缓存雪崩 前言 在日常的项目中,缓存的使用场景是比较多的.缓存是分布式系统中的重要组件,主要解决在高并发.大数据场景下,热点数据访问的性能

  • 浅谈Redis高并发缓存架构性能优化实战

    目录 场景1: 中小型公司Redis缓存架构以及线上问题实战 场景2: 大厂线上大规模商品缓存数据冷热分离实战 场景3: 基于DCL机制解决热点缓存并发重建问题实战 场景4: 突发性热点缓存重建导致系统压力暴增 场景5: 解决大规模缓存击穿导致线上数据库压力暴增 场景6: 黑客工资导致缓存穿透线上数据库宕机 场景7: 大V直播带货导致线上商品系统崩溃原因分析 场景8: Redis分布式锁解决缓存与数据库双写不一致问题实战 场景9: 大促压力暴增导致分布式锁串行争用问题优化 场景10: 利用多级缓

  • redis哨兵模式说明与搭建详解

    哨兵模式是redis高可用的一种解决方案. 哨兵必须用三个实例取保证自己的高可用,但是哨兵+主从模式是不能保证消息不丢失的. 为什么用三个来保证呢? 假设现在有两个服务器,第一台有redis主节点M1,和哨兵S1,第二台有redis从节点S2,哨兵S2. 如果M1宕机,S1和S2中只要有1个哨兵认为master宕机就可以还行切换,此时哨兵大多数(我理解的大多数的过半)还在运行,那么S1,S2能通过选举,拿出来一个哨兵进行故障转移. 如果第一个服务器整个宕机,M1,S1都已经死掉了,此时S2发现M

  • 浅谈Redis主从复制以及主从复制原理

    面临问题 1. 机器故障.我们部署到一台 Redis 服务器,当发生机器故障时,需要迁移到另外一台服务器并且要保证数据是同步的.而数据是最重要的,如果你不在乎,基本上也就不会使用 Redis 了. 2. 容量瓶颈.当我们有需求需要扩容 Redis 内存时,从 16G 的内存升到 64G,单机肯定是满足不了.当然,你可以重新买个 128G 的新机器. 解决办法 要实现分布式数据库的更大的存储容量和承受高并发访问量,我们会将原来集中式数据库的数据分别存储到其他多个网络节点上.Redis 为了解决这个

  • 浅谈Redis 中的过期删除策略和内存淘汰机制

    目录 前言 Redis 中 key 的过期删除策略 1.定时删除 2.惰性删除 3.定期删除 Redis 中过期删除策略 从库是否会脏读主库创建的过期键 内存淘汰机制 内存淘汰触发的最大内存 有哪些内存淘汰策略 内存淘汰算法 LRU LFU 为什么数据删除后内存占用还是很高 内存碎片如何产生 碎片率的意义 如何清理内存碎片 总结 参考 前言 Redis 中的 key 设置一个过期时间,在过期时间到的时候,Redis 是如何清除这个 key 的呢? 这来分析下 Redis 中的过期删除策略和内存淘

随机推荐