Redis哨兵,Redis哨兵核心功能如何一个云服务器完成6个节点的搭建-docker什么是docker是否可以把六个容器,都写到同一个ym配置中,一次都启动,不就直接保证互通问题了吗?

本文涉及的产品
云数据库 Redis 版,社区版 2GB
推荐场景:
搭建游戏排行榜
云服务器 ECS,每月免费额度200元 3个月
云服务器ECS,u1 2核4GB 1个月
简介: Redis哨兵,Redis哨兵核心功能如何一个云服务器完成6个节点的搭建-docker什么是docker是否可以把六个容器,都写到同一个ym配置中,一次都启动,不就直接保证互通问题了吗?

引言

主节点:代表一个独立的redis-server进程

从节点:一个独立的redis-server进程

实际开发中,对于服务器后端开发,监控程序,是十分重要的,服务器7*24小时运行

长期运行,总会有意外,什么时候坏,说不好,也不能全靠人盯着。

于是大佬想了一个办法,用一个程序来盯着服务器运行状态-监控程序+报警程序(发现服务器运行出现状态异常,给程序员报警,说这个服务器程序挂了,出现问题了)

如何解救:

1.先看主节点能不能抢救,好不好抢救

2.主节点这边什么原因挂的,不好定位,或者原因知道,但是短时间难以解决,就需要挑一个节点,设置为新的主节点

a.把选中的从节点通过slaveof no one,自立山头

b.把其他的从节点,修改slaveof的主节点ip port,连上新的主节点

c.告知客户端(修改客户端的配置),让客户端能够连接新的主节点,用来完成修改数据的操作

当之前的主节点修好之后,可以作为新的从节点,挂到这组机器中~

但是人工干预,不说是繁琐,但是也很烦人。程序员恢复操作也不是很快。

哨兵的初心

1.借助上述的监控机制,就可以及时发现某个主机是否挂了。此时,一个哨兵节点发现主节点挂了,还不够,需要多个哨兵节点来共同认同这件事情,主要是防止出现误判

2.主节点确实挂了,哨兵节点中推出一个leader,由这个leader复制从现有的从节点中,挑选一个作为新的主节点

3.挑选出新的主节点之后,哨兵节点,就会自动控制该被选中的节点,执行slaveof no one 并且控制其他从节点,修改slaveof到新的主节点上~

4.哨兵节点会自动通知客户端程序,告诉新的主节点是谁,后续就针对这个新的主节点进行操作。


Redis哨兵核心功能

1.监控

2.自动的故障转移

3.通知

1.注意redis哨兵节点,有1个也是可以的,但是一个不如多个(最好奇数个,方便后续选举),哨兵节点有一个,它自身也是容易出现问题的,万一这个哨兵挂了,不久无法自动的进行恢复过程了

2.出现误判的概率比较高,只有一个哨兵节点,出现上述问题之后,影响就比较大~

基本的原则:在分布式系统中,应该避免使用单点     ->冗余

如何节点的搭建-docker是没意义的,但是没钱

前言:把上述节点放到一个服务器上是没意义的,但是没钱

类似于最开始进行主从结构配置的方式,比较繁琐,也会和在不同主机上部署,存在较大差异。

什么是docker

虚拟机通过软件,在电脑上模拟出另外一些硬件(构造了另一个虚拟的电脑,虚拟机的问题就是比较吃配置,对于云服务器来说,亚历山大) docker可以认为是更轻量级的虚拟机(起到了虚拟机这样的隔离还击,但是又没有吃很多硬件资源),即使配置比较辣椒的,也能构造出这样的虚拟环境

1.先去安装docker和docker-compose

2.停止之前的redis服务器

3.使用docker获取到redis镜像

像和容器-类似于可执行程序和进程的关系

镜像可以自己构建,也可以拿别人已经构造好的

docker pull redis:5.0.9

如同git pull使用git中央仓库拉取代码,docker pull使用docker从中央仓库(默认是docker hub)来拉取镜像

拉去到的镜像,里面包含一个精简的Linux系统,并且上面安装了redis,只要直接给予这个镜像创建一个容器跑起来,此时redis服务器就搭建好了。

查看docker内部的镜像

基于docker来搭建redis哨兵环境了

docker-compose来进行容器的编排->此处涉及到多个redis server也有多个redis哨兵节点~,每一个redis server或者每一个redis哨兵节点都是作为一个单独容器了

什么叫容器编排:通过一个配置文件,把具体要创建哪些容器,每个容器运行的各种参数,描述清楚,后面通过一个简单的命令,就能够批量的启动/停止这些容器了。

使用yml格式作为配置文件。

1.创建三个容器,作为redis的数据节点(一个主,两个从) yml

2.创建三个容器,作为redis的哨兵节点 yml

其实也可以用一个yml,直接启动6个容器,如果6个同时启动,可能哨兵先启动,数据节点后完成,哨兵就会可能认为数据节点挂了,虽然对大局不影响,但是会影响观察执行日志的过程~

配置名字是固定的

进行内部的配置

services的名字是我们自己设定的

image:当前容器是根据哪个镜像进行创建的

version: '3.7'
services:
  master:
    image: 'redis:5.0.9'
    container_name: redis-master
    restart: always
    command: redis-server --appendonly yes
    ports:
      - 6379:6379
  slave1:
    image: 'redis:5.0.9'
    container_name: redis-slave1
    restart: always
    command: redis-server --appendonly yes --slaveof redis-master 6379
    ports:
      - 6380:6379
  slave2:
    image: 'redis:5.0.9'
    container_name: redis-slave2
    restart: always
    command: redis-server --appendonly yes --slaveof redis-master 6379
    ports:
      -  6381:6379
 
 
~                                                                                              
~                                                                                              
~                                                                                              
~                                                                                              
~                                                                                              
~                                                                                              
~                                                                                              
~                                                                                              
~                                                                                              
~                                                                                              
~                                                                                              
~                                                                                              
~                                                                                              
~                                                                                              
~                                                                                              
"docker-compose.yml" 25L, 572C                                               18,11         All

docker容器可以理解成是一个轻量的虚拟机,在这个容器,端口号和外面宿主端口号是两个体系,如果容器外使用了5050端口,内部仍可以使用5050,二者没有冲突

三个容器,容器内部的端口号都是自成一派,容器1和2的6379没有冲突,容器外想去访问容器内部的端口则需要进行端口映射,后续访问宿主机这个端口,就相当于访问对应容器的对应端口了,站在宿主的角度,访问上述几个端口,也不知道是宿主机上的服务还是容器内部的服务,只需要正常去用即可。

上面这块不必写主节点ip,直接写主节点的容器名,容器启动之后,被分配的ip是啥也不知道(有办法配置静态IP)容器名类似于域名,docker自动进行域名解析,就得到对应的ip

配置之后使用这个命令docker-compose up -d

配置哨兵节点

docker的核心功能,能够进行端口的映射,容器内使用啥端口,映射出去后,还是要确保端口不能重复的

version: '3.7'
services:
  sentinel1:
    image: 'redis:5.0.9'
    container_name: redis-sentinel-1
    restart: always
    command: redis-sentinel1 /etc/redis/sentinel.conf
    volumes:
      - ./sentinel1.conf:/etc/redis/sentinel.conf
    ports:
      - 26379:26379
  sentinel2:
    image: 'redis:5.0.9'
    container_name: redis-sentinel-2
    restart: always
    command: redis-sentinel /etc/redis/sentinel.conf
    volumes:
      - ./sentinel2.conf:/etc/redis/sentinel.conf
    ports:
      - 26380:26379
  sentinel3:
    image: 'redis:5.0.9'
    container_name: redis-sentinel-3
    restart: always
    command:  redis-sentinel /etc/redis/sentinel.conf
    volumes:
       - ./sentinel3.conf:/etc/redis/sentinel.conf
    ports:
       - 26381:26379
~                                                                                              
~                                                                                              
~                                                                                              
~                                                                                              
~                                                                                              
~                                                                                              
~                                                                                              
~                                                                                              
~                                                                                              
~                                                                                              
~                                                                                              
"docker-compose.yml" 29L, 757C                                               23,35         All


redis哨兵节点是单独的redis服务器进程

redis-master :告诉哨兵节点,让他监视哪一个redis服务器

6379:这里其实是ip,但是使用docker,docker自动进行域名解析

2:法定票数

down-after-milliseconds:心跳包的超时时间

bind 0.0.0.0
port 26379
sentinel monitor redis-master redis-master 6379 2
sentinel down-after-milliseconds redis-master 1000

启动后,我们查看docker的日志,牛魔的一堆错误

此处,这个哨兵节点,不认识redis-master,redis-master相当于一个域名,docker会进行域名解析,docker-compose一下启动了N个容器,此时N个容器都处在同一个局域网中,可以使这N个容器之间可以相互访问,三个redis-server节点,是一个局域网,三个哨兵节点,是另一个局域网

默认情况下,这两个网络并不互通

解决方案:可以使用docker-compose把此处两组服务给放到同一个局域网中,docker network ls列出当前docker中的局域网,docker-compose文件所在的目录名字

此处先启动了三个redis server节点,就相当于创建了第一个局域网,在启动后面三个哨兵节点,就直接让这三个节点加入到上面的局域网中,而不是创建新的局域网!

(这里的关键是必须要是上面那个局域网,即data那个局域网)

此时就没有什么太大的问题了。

通过上述的操作,就完成了此处的配置~

是否可以把六个容器,都写到同一个ym配置中,一次都启动,不就直接保证互通问题了吗?

如果用这种方案,docker-compose启动容器的顺序不确定,无法保证redis-server一定在哨兵之前启动的,分成两组来启动,就可以保证上述顺序。观察到的日志,比较可控。

我们可以观察到有好多东西,都和我们第一次写的时候不一样,哨兵节点启动之后,自动进行修改的

哨兵存在的意义:

能够在redis主从结构出现问题的时候,此时哨兵节点能够自动帮助我们重新选出一个主节点,来代替之前挂了的节点,保证整个redis仍是可用的状态。

手动干掉主节点,(看最后一个Exit那个)主节点挂了,哨兵节点开始工作,前半部分是哨兵刚启动的时候的日志,redis-master挂了

我们来查看此时的日志,sdown主观线下:本哨兵节点,认为该主节点挂了

odown客观下线:好几个哨兵都认为该节点挂了,达成了一致(法定票数,此时主节点挂了这件事就被定下了)

此时就需要哨兵节点选出一个从节点,作为新的主节点,此处就需要选拔出一个新的主节点


此时就能够看到它挂了。

我们可以看到此时的6381是作为主节点了,而6380仍作为从节点

就算我们把原先的主节点恢复,他也会变成从节点,挂到主节点下面

以上就可以保证,原有的节点挂了,可以保证系统仍正常工作

哨兵重新选取主节点的流程

1.主观下线

哨兵通过心跳包,判定redis服务器是否正常工作,如果心跳包没有如约而至,就说明redis服务器挂了,此时还不能排除网络波动的影响,因此就只能单方面认为redis这个节点挂了

2.客观下线

多个哨兵都认为主节点挂了(认为挂了的哨兵节点数目达到了法定票数)哨兵们就认为这个主节点是客观下线(比如出现很严重的网络波动,所有哨兵都联系不上redis主节点,但是这种情况,基本客户端也连接不上redis主节点,此时这个主节点也无法正常工作了

挂了不一定是进程崩了,只要无法正常访问,都可以视为是挂了

3.要让多个哨兵节点,选出一个leader,由这个leader负责选一个从节点作为新的主节点

投票过程看,网络延迟谁更小

4.leader选举完毕,leader就需要挑选一个从节点,作为新的主节点

1)优先级:每个redis数据节点,都会在配置文件中,有一个优先级的设置.slave-priority优先级高的从节点,就会胜出

2)offset 最大,就胜出 offset从节点从主节点这边同步数据的进度,数值越大,说明从节点的数据和主节点越接近

3)随缘

把新的主节点指定好了之后,执行slave no one,成为master,再控制其他节点,执行slave of,让这些其他节点,以新的master作为主节点了。

小结:

使用哨兵注意事项

哨兵节点不能只有一个,否则哨兵节点挂了也会影响系统可用性

哨兵节点最好奇数个,方便选举leader,得票容易超过半数

哨兵节点不负责存储数据,仍然是redis主从节点负责存储

哨兵节点+主从复制解决的问题是"提高可用性",不能解决数据极端情况下写丢失

哨兵+主从复制不能提高数据的存储容量,当我们需要存储的数据接近超过机器的物理内存,这样的结构难以胜任------集群(下一篇)

相关实践学习
借助OSS搭建在线教育视频课程分享网站
本教程介绍如何基于云服务器ECS和对象存储OSS,搭建一个在线教育视频课程分享网站。
7天玩转云服务器
云服务器ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,可降低 IT 成本,提升运维效率。本课程手把手带你了解ECS、掌握基本操作、动手实操快照管理、镜像管理等。了解产品详情: https://www.aliyun.com/product/ecs
相关文章
|
1天前
|
Shell Linux Docker
docker常用命令大全(基础、镜像、容器、数据卷)
这些命令仅仅是 Docker 命令行工具的冰山一角,但对于日常操作来说已经非常全面。通过熟练地使用这些基础命令,用户可以有效地管理 Docker 的镜像、容器、数据卷和网络。随着用户对 Docker 的深入使用,更高级的命令和选项将会变得必需,但上面列出的命令已经为用户提供了一个坚实的起点。对于初学者来说,理解和掌握这些常用命令是深入学习 Docker 的基础。
21 4
docker常用命令大全(基础、镜像、容器、数据卷)
|
3天前
|
Docker Python 容器
容器化技术,特别是Docker,已经成为现代软件开发和部署的重要工具。
容器化技术,特别是Docker,已经成为现代软件开发和部署的重要工具。
|
2天前
|
弹性计算 运维 应用服务中间件
容器的优势,在Docker中运行Tomcat
摘要:了解Docker与虚拟机的区别:虚拟机使用Hypervisor创建完整操作系统,而容器通过namespace和cgroup实现轻量级隔离,共享主机内核。Docker启动快、资源利用率高,适合快速部署和跨平台移植。但安全性相对较低。示例介绍了如何通过Docker搜索、拉取官方Tomcat镜像并运行容器,最后验证Tomcat服务的正常运行。
|
2天前
|
安全 网络协议 云计算
Docker容器网络配置详解
【7月更文挑战第16天】Docker的网络配置是实现容器间以及容器与外部网络通信的基础。通过选择合适的网络模式和配置选项,可以构建高效、安全、可扩展的Docker网络解决方案。
|
2天前
|
Java Scala 流计算
实时计算 Flink版产品使用问题之Docker镜像中的Java路径和容器内的Java路径不一致,是什么导致的
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
3天前
|
运维 Ubuntu Docker
Docker镜像和容器使用
【7月更文挑战第2天】Docker 概要:Docker 镜像是只读模板,包含运行应用的环境和代码,像蓝图一样。构建镜像可通过基于现有镜像(如 Ubuntu)安装软件后提交,或使用 Dockerfile 定义构建过程。Docker 容器是镜像的运行时实例,`docker run` 命令可创建并运行容器。常用容器操作包括启动/停止、状态检查和交互式进入。通过端口映射,容器服务可从主机访问,促进应用部署和管理的便捷性。
|
3天前
|
Kubernetes Cloud Native 持续交付
云原生架构的核心组成部分通常包括容器化(如Docker)、容器编排(如Kubernetes)、微服务架构、服务网格、持续集成/持续部署(CI/CD)、自动化运维(如Prometheus监控和Grafana可视化)等。
云原生架构的核心组成部分通常包括容器化(如Docker)、容器编排(如Kubernetes)、微服务架构、服务网格、持续集成/持续部署(CI/CD)、自动化运维(如Prometheus监控和Grafana可视化)等。
|
1天前
|
弹性计算 Linux 网络安全
使用阿里云服务器迁移中心SMC将其他云平台业务迁移至阿里云教程参考
现在越来越多的个人和企业用户选择将其他云平台或者服务商的业务迁移到阿里云,但是如何快速且安全完成迁移是很多用户比较关注的问题,我们可以选择使用阿里云提供的服务器迁移中心(Server Migration Center,简称SMC),这个产品是阿里云提供给您的迁移平台,专注于提供能力普惠、体验一致、效率至上的迁移服务,满足您在阿里云的迁移需求。本文为大家展示使用阿里云服务器迁移中心SMC将其他云平台业务迁移至阿里云的教程,以供参考。
使用阿里云服务器迁移中心SMC将其他云平台业务迁移至阿里云教程参考
|
3天前
|
运维 安全 数据挖掘
阿里云轻量应用服务器82元和298元与云服务器99元和199元简介
目前阿里云推出了几款价格极为实惠的轻量应用服务器和云服务器产品,轻量应用服务器有2核2G3M 50GB高效云盘,价格为82元1年;2核4G4M 60GB高效云盘,价格为298元1年;经济型e实例2核2G,40G ESSD Entry盘,3M带宽,价格为99元1年;通用算力型u1实例2核4G,80G ESSD Entry盘,5M带宽,价格为199元1年。这几款云服务器究竟如何?本文将为您进行详细分析,以供参考。
阿里云轻量应用服务器82元和298元与云服务器99元和199元简介
|
2天前
|
弹性计算 运维 安全
阿里云ecs使用体验
整了台服务器部署项目上线