Redis持久化主从哨兵分片集群

2024-06-21 02:28
文章标签 集群 redis 哨兵 持久 主从 分片

本文主要是介绍Redis持久化主从哨兵分片集群，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

文章目录

    • 1. 单点Redis的问题
      • 数据丢失问题
      • 并发能力问题
      • 故障恢复问题
      • 存储能力问题
    • 2. Redis持久化 -> 数据丢失问题
      • RDB持久化
        • linux单机安装Redis步骤
        • RDB持久化与恢复示例
        • RDB机制
        • RDB配置示例
        • RDB的fork原理
        • 总结
      • AOF持久化
        • AOF配置示例
        • AOF文件重写
        • RDB与AOF对比
    • 3. Redis主从 -> 并发能力问题
      • 主从架构
        • 搭建主从架构示例
          • 集群架构
          • 准备实例和配置
          • 启动
          • 开启主从关系
          • 测试
      • 主从数据同步原理
        • 主从的全量同步原理
          • 简述全量同步的流程
        • 主从的增量同步原理
          • 主从数据同步优化点
        • 总结
    • 4. Redis哨兵 -> 故障恢复问题
    • 5. Redis分片集群 -> 存储能力问题

【redis学习篇】主从&哨兵&集群架构详解

1. 单点Redis的问题

在这里插入图片描述

数据丢失问题

Redis是内存存储，服务重启可能会丢失数据

并发能力问题

单节点Redis并发能力虽然不错，但也无法满足如618这样的高并发场景

故障恢复问题

如果Redis宕机，则服务不可用，需要一种自动的故障恢复手段

存储能力问题

Redis基于内存，单节点能存储的数据量难以满足海量数据需求

2. Redis持久化 -> 数据丢失问题

RDB持久化

RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。

快照文件称为RDB文件，默认是保存在当前运行目录。

在这里插入图片描述

save命令：由于redis是单线程执行的，使用此save命令时，主进程会阻塞其它的命令，而将数据持久化到磁盘的耗时比较久，等到save命令结束，主进程才能执行其它命令。不推荐使用此命令，它通常用在Redis停机时使用。

bgsave命令：后台异步执行，它会开启子进程执行RDB，避免主进程收到影响，推荐使用该命令作RDB。

Redis停机时会自动执行一次RDB（通过redis-cli连接上redis服务之后，输入shutdown命令即可让redis服务停止或者在redis未开启以守护模式运行时通过ctrl+c停止运行时，会自动执行一次RDB）。

linux单机安装Redis步骤

首先需要安装Redis所需要的依赖：

yum install -y gcc tcl

然后将课前资料提供的Redis安装包上传到虚拟机的任意目录：

在这里插入图片描述

例如，我放到了/tmp目录：

在这里插入图片描述

解压缩：

tar -xvf redis-6.2.4.tar.gz

解压后：

在这里插入图片描述

进入redis目录：

cd redis-6.2.4

运行编译命令：

make && make install

如果没有出错，应该就安装成功了（redis的默认安装位置是/usr/local/bin，在此/usr/local/bin目录下有：redis-server、redis-cli、redis-benchmark、redis-sentinel等可执行文件；同时在redis-6.2.4目录下有redis.conf和sentinel.conf配置文件；同时在redis-6.2.4目录下的是src目录中也有redis-server、redis-cli、redis-benchmark、redis-sentinel等可执行文件）。

然后修改redis.conf文件中的一些配置：

# 绑定地址，默认是127.0.0.1，会导致只能在本地访问。修改为0.0.0.0则可以在任意IP访问
bind 0.0.0.0# 数据库数量，设置为1
databases 1

启动Redis：

redis-server redis.conf # 使用redis-server命令启动redis, 并指定配置文件; 其中redis-server命令可在任意目录下执行

停止redis服务：

redis-cli shutdown # 其中redis-cli命令可在任意目录下执行
RDB持久化与恢复示例

按照【单机安装Redis步骤】中的步骤安装好redis后：

  • 在/usr/local/bin目录下有redis-server、redis-cli、redis-benchmark、redis-sentinel等可执行文件，并且
  • 在/usr/local/redis6/redis6.2.4/src目录下也有这些可执行文件；
  • 在/usr/local/redis6/redis6.2.4/src下有redis.conf和sentinel.conf配置文件。

（这里主要是说明安装情况）

在如上安装好redis之后，这里演示下在关闭redis服务时，redis会自动执行RDB的案例

现在切换/usr/local/redis6/redis-6.2.4目录下（不是必须在这个目录，在其它目录也可以执行redis-server命令）

在这里插入图片描述

使用redis-server ./redis.conf 命令，来指定对应的配置文件启动redis服务，redis开始接收连接

在这里插入图片描述

现在开启另外1个窗口，使用set num 123来保存1条数据到redis内存中，然后发出shutdown的命令，让redis关闭服务，此时redis服务会自动做1次RDB操作，将内存中的数据持久化到dump.rdb文件中（此dump.rdb文件默认会生成在运行redis-server命令时所在的目录中，这里在/usr/local/redis6/redis-6.2.4目录下）

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

现在/usr/local/redis6/redis-6.2.4目录下，继续在重新启动redis服务，查看前面通过RDB持久化的文件是否恢复到内存当中（这里就没有指定redis.conf了，也可以指定对应的配置文件）

在这里插入图片描述

在另外1个窗口，使用redis-cli连接上redis服务，查看数据，发现数据没有丢失，说明redis能够从持久化的文件恢复到内存中

在这里插入图片描述

RDB机制

上面案例演示了在redis服务关闭时，会自动执行RDB命令，将内存中的数据持久化到磁盘中。但是，假设redis运行过程中，突然宕机了，此时还没持久化到磁盘中，那么在存储在redis内存中的数据将会全部丢失，所以redis应该要有一套自动持久化的机制。

Redis内部有触发RDB的机制，可以在redis.conf文件中找到（这3个配置默认是被注释的，默认情况下RDB是开启的），格式如下：

在这里插入图片描述

RDB的其它配置也可以在redis.conf文件中设置：

在这里插入图片描述

（配置的含义就是 在指定的一段时间内，有指定数量的key被修改了，那么就执行1次RDB操作，将内存中的数据持久化到指定的目录下的指定的文件中。当然，redis启动时，也会从这个指定的目录下查找这个指定的文件加载到内存中。）

当有了RDB后，即使不关闭redis服务，也能通过配置将redis内存中的数据持久化到磁盘上，但是它会每隔一段时间，才会执行RDB操作。如果在某段时间内，尚未执行RDB时，此时宕机了，那么这段时间内的数据就丢失了。所以，可能会想着把间隔时间设置的尽可能短，但如果间隔时间很短，执行RDB的操作就太频繁了，影响redis的性能。所以使用默认的就好了。

RDB配置示例

说明：5s内，如果有1个key发生变化，那么持久化内存钟的数据到指定的文件中。其中，修改redis.conf文件部分如下：

# 5s内，如果有1个key发生变化, 则触发1次RDB持久化（如果需要禁用RDB, 则配置: save "" 即可）
save 5 1# 指定持久化文件的名字
dbfilename test.data  # 指定RDB持久化文件的所在目录
dir ./my_data_dir

在/usr/local/redis6/redis-6.2.4下创建rdb_test目录，并在此rdb_test目录下创建my_data_dir文件夹用于存放持久化文件。修改号redis.conf配置文件后，使用该配置文件启动redis。

在这里插入图片描述

redis启动后，使用redis-cli连接上redis服务，并向redis中存储2条数据，然后观察redis服务的控制台上观察输出，看到了redis执行持久化的日志，关闭redis后，查看my_data_dir文件夹，看到了test.data数据持久化文件

在这里插入图片描述
在这里插入图片描述

再次使用指定的配置文件，启动redis，使用redis-cli再次查询数据，发现数据已恢复

在这里插入图片描述

在这里插入图片描述

RDB的fork原理

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。（bgsave是异步执行持久化的，对主进程几乎零阻塞，零阻塞的原因在于主进程在执行fork得到子进程时，此fork操作会阻塞，此时无法处理客户端请求）

fork采用的是copy-on-write技术：

  • 当主进程执行读操作时，访问共享内存；
  • 当主进程执行写操作时，则会拷贝一份数据，执行写操作（当此时针对很多key写操作时，就相当于要拷贝大量数据作为副本，此时就需要事先考虑给redis预留足够的空间）

在这里插入图片描述

总结

RDB方式bgsave的基本流程？

  • fork主进程得到一个子进程，共享内存空间
  • 子进程读取内存数据并异步写入新的RDB文件
  • 用新RDB文件替换旧的RDB文件。

RDB会在什么时候执行？save 60 1000代表什么含义？

  • 默认是服务停止时。
  • 代表60秒内至少执行1000次修改则触发RDB

RDB的缺点？

  • RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险
  • fork子进程、压缩、写出RDB文件都比较耗时

AOF持久化

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

在这里插入图片描述

AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF：

在这里插入图片描述

AOF的命令记录的频率也可以通过redis.conf文件来配：

在这里插入图片描述

配置项刷盘时机优点缺点
Always同步刷盘（redis接收到命令后，使用命令操作完内存后，把此命令写到AOF文件磁盘中，此时主进程是阻塞的，等到写完AOF才返回给用户，主进程再处理其它请求）可靠性高，几乎不丢数据性能影响大
everysec每秒刷盘（redis接收到命令后，使用命令操作完内存后，把此命令写到内存缓冲区中，写完缓冲区后，主进程立即返回。1s后再通过异步的方式将缓冲区中的数据写到AOF文件磁盘中，因为主进程是面对内存缓冲区中的读写，所以效率高，但是如果在写入的过程中宕机了，那么就会丢失这1s内的所有操作。它是默认方案。）性能适中最多丢失1秒数据
no操作系统控制（由操作系统决定，可能频率会比较低）性能最好可靠性较差，可能丢失大量数据
AOF配置示例

说明：AOF会记录每条执行的redis命令到aof文件中，这里关闭了rdb机制，开启了aof机制

# 关闭RDB机制
save ""# aof文件将会保存在此目录, 启动时会读取该目录下的aof文件（与RDB持久化文件所保存的目录相同）
dir ./aof_data_dir# 开启aof
appendonly yes# aof文件名
appendfilename "my_aof.data"# aof刷盘策略, 默认就是everysec, 不需要修改
appendfsync everysec

在/usr/local/redis6/redis-6.2.4下创建aof_test目录，并在此aof_test目录下创建aof_data_dir文件夹用于存放aof文件。修改好redis.conf配置文件后，使用该配置文件启动redis。

在这里插入图片描述

使用redis-cli客户端连接上redis服务，并且保存1条数据，然后退出redis-cli客户端，就可以在指定的目录下看到保存的aof文件了，并且这里看到了aof文件的内容，aof文件确实记录了每条redis命令

在这里插入图片描述

关闭redis时，redis也会执行1次aof

在这里插入图片描述

重新启动redis服务，会自动加载aof文件，然后使用redis-cli客户端连接上redis服务，查询redis服务关闭之前所保存的数据，能够查询到，说明aof文件被加载了

在这里插入图片描述

在这里插入图片描述

AOF文件重写

因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果（此命令为异步执行，他会让aof文件变小，并对内容作编码处理）。

在这里插入图片描述

Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：

在这里插入图片描述

RDB与AOF对比

RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。

特点RDBAOF
持久化方式定时对整个内存做快照记录每一次执行的命令
数据完整性不完整，两次备份之间会丢失相对完整，取决于刷盘策略
文件大小会有压缩，文件体积小记录命令，文件体积很大
宕机恢复速度很快慢
数据恢复优先级低，因为数据完整性不如AOF高，因为数据完整性更高
系统资源占用高，大量CPU和内存消耗低，主要是磁盘IO资源但AOF重写时会占用大量CPU和内存资源
使用场景可以容忍数分钟的数据丢失，追求更快的启动速度对数据安全性要求较高常见

  • RDB与AOF数据恢复优先级：当目录下同时存在AOF与RDB文件时，会优先使用AOF文件来恢复数据，因为AOF文件数据更加完整，而RDB会丢失从上次备份的数据后到发生故障时这段时间内的数据。所以RDB更适合作为一种数据备份的手段。

  • AOF操作是异步的

3. Redis主从 -> 并发能力问题

主从架构

单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群（而不是负载均衡的那种集群），实现读写分离（因为redis查询操作多，增删改比较少，所以需要更多的处理读的压力，实现读写分离，提高读的并发能力）。

在这里插入图片描述

搭建主从架构示例
集群架构

我们搭建的主从集群结构如图：

在这里插入图片描述

共包含三个节点，一个主节点，两个从节点。这里我们会在同一台虚拟机中开启3个redis实例，模拟主从集群，信息如下：

IPPORT角色
172.17.23.2347001master
172.17.23.2347002slave
172.17.23.2347003slave
准备实例和配置

要在同一台虚拟机开启3个实例，必须准备三份不同的配置文件和目录，配置文件所在目录也就是工作目录。

1）创建目录

我们在/usr/local/redis6/redis-6.2.4/master-slave-cluster目录下，创建三个文件夹，名字分别叫redis7001、redis7002、redis7003，和1个最初的redis.conf配置文件（未作任何修改）

在这里插入图片描述

修改redis.conf配置文件：将其中的持久化模式改为默认的RDB模式，AOF保持关闭状态；配置bind允许远程连接；虚拟机本身有多个IP，为了避免将来混乱，我们需要在redis.conf文件中指定每一个实例的绑定ip信息。然后，将此redis.conf分别拷贝到redis7001、redis7002、redis7003中，然后分别修改他们对应的端口为：7001，7002，7003。

# 开启RDB
# save ""
save 3600 1
save 300 100
save 60 10000# 关闭AOF
appendonly no# 允许远程连接（不设置此配置, 会无法同步）
bind 0.0.0.0# 虚拟机本身有多个IP，为了避免将来混乱，我们需要在redis.conf文件中指定每一个实例的绑定ip信息
replica-announce-ip 172.17.23.234# 这个目录在本示例中为了方便就不改了, 但是注意启动的时候, 需要到对应的目录下去启动, 否则rdb生成的文件会在redis-server的运行目录下
dir ./# 端口: redis7001、redis7002、redis7003中，然后分别修改他们对应的端口为：7001，7002，7003
port 7001 # 这里以7001为例
启动

分别在redis7001目录下启动7001，redis7002目录下7002，redis7003目录下7003（注意运行redis-server命令的目录，因为我们的dir配置的是./）

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

开启主从关系

现在三个实例还没有任何关系，要配置主从可以使用replicaof 或者slaveof（5.0以前）命令。

有临时和永久两种模式：

  • 修改配置文件（永久生效）

    • 在redis.conf中添加一行配置：slaveof <masterip> <masterport>

  • 使用redis-cli客户端连接到redis服务，执行slaveof命令（重启后失效）：

    slaveof <masterip> <masterport>

注意：在5.0以后新增命令replicaof，与salveof效果一致。

这里让7002成为7001的slave，即让7002成为7001的从节点，执行该命令后，就会把7001主节点的数据同步过来

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

让7003成为7001的slave，并且从节点只能读取数据，不能够写入数据，只有主节点才能写入数据

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

测试

在主节点中写入数据，再分别从7002、7003从节点中读取到了数据，证明主从数据同步成功了。可以执行info replication查看集群状态。

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

主从数据同步原理

主从的全量同步原理

主从第一次同步是全量复制

在这里插入图片描述

master如何判断slave是不是第一次来同步数据？这里会用到两个很重要的概念：

  • Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid
  • offset：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

因此slave做数据同步，必须向master声明自己的replication id 和offset，master才可以判断到底需要同步哪些数据

全量同步过程：从节点将自己的replication id发给主节点，主节点判断此replication id是否与自己的replication id是否一致，如果replication id不一致，说明该从节点是第一次来，主节点需要执行bgsave命令来做RDB保存起来，然后将自己的全量数据和offset同步到该从节点；如果replication id一致，说明从节点之前已经来过了，做过了全量同步了，并且从节点将offset也发过来了，因此主节点就可以从offset得知从节点的同步进度，因此主节点就将offset后面的数据发过去给从节点）

简述全量同步的流程

  • 第1步：slave与master建立连接

  • 第2步：slave节点请求增量同步

  • 第3步：master节点判断replid，发现不一致，拒绝增量同步

  • 第4步：master将完整内存数据生成RDB，发送RDB到slave

  • 第5步：slave清空本地数据，加载master的RDB

  • 第6步：master将RDB期间的命令记录在repl_baklog，并持续将log中的命令发送给slave

  • 第7步：slave执行接收到的命令，保持与master之间的同步

主从的增量同步原理

主从第一次同步是全量同步，，但如果slave重启后同步，则执行增量同步。

增量同步过程：从节点重启后，依然需要携带自己的replid和offset向主节点请求同步数据，主节点收到该节点发过来的replid后，与自己的replid比较，发现一致，说明不是第一次来同步的，因此，就查看该节点发过来的offset查看该节点之前的同步进度，然后从repl_baklog中读取大于此offset的命令发送给从节点去同步。如果主节点这边检测到该未同步的数据已经被覆盖了，那么就会要求该节点做全量同步。

在这里插入图片描述

repl_baklog大小有上限，写满后会覆盖最早的数据。如果slave断开时间过久，导致尚未备份的数据被覆盖，则无法基于log做增量同步，此时只能再次全量同步。

主从数据同步优化点

可以从以下几个方面来优化Redis主从就集群：

  • 在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO（需要网络带宽足够大）。

  • Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO

  • 适当提高repl_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步

  • 限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主-从-从链式结构，减少master压力

    在这里插入图片描述

总结

简述全量同步和增量同步区别？

  • 全量同步：master将完整内存数据生成RDB，发送RDB到slave。后续命令则记录在repl_baklog，逐个发送给slave。
  • 增量同步：slave提交自己的offset到master，master获取repl_baklog中从offset之后的命令给slave

什么时候执行全量同步？

  • slave节点第一次连接master节点时
  • slave节点断开时间太久，repl_baklog中的offset已经被覆盖时

什么时候执行增量同步？

  • slave节点断开又恢复，并且在repl_baklog中能找到offset时

4. Redis哨兵 -> 故障恢复问题

5. Redis分片集群 -> 存储能力问题

这篇关于Redis持久化主从哨兵分片集群的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/1079946。

相关文章

服务器集群同步时间手记

服务器集群同步时间手记

1.时间服务器配置（必须root用户） （1）检查ntp是否安装 [root@node1 桌面]# rpm -qa|grep ntpntp-4.2.6p5-10.el6.centos.x86_64fontpackages-filesystem-1.41-1.1.el6.noarchntpdate-4.2.6p5-10.el6.centos.x86_64 （2）修改ntp配置文件 [r
阅读更多...
HDFS—集群扩容及缩容

HDFS—集群扩容及缩容

白名单：表示在白名单的主机IP地址可以，用来存储数据。 配置白名单步骤如下： 1）在NameNode节点的/opt/module/hadoop-3.1.4/etc/hadoop目录下分别创建whitelist 和blacklist文件 （1）创建白名单 [lytfly@hadoop102 hadoop]$ vim whitelist 在whitelist中添加如下主机名称，假如集群正常工作的节
阅读更多...
Hadoop集群数据均衡之磁盘间数据均衡

Hadoop集群数据均衡之磁盘间数据均衡

生产环境，由于硬盘空间不足，往往需要增加一块硬盘。刚加载的硬盘没有数据时，可以执行磁盘数据均衡命令。（Hadoop3.x新特性） plan后面带的节点的名字必须是已经存在的，并且是需要均衡的节点。 如果节点不存在，会报如下错误： 如果节点只有一个硬盘的话，不会创建均衡计划： （1）生成均衡计划 hdfs diskbalancer -plan hadoop102 （2）执行均衡计划 hd
阅读更多...
零基础学习Redis(10) -- zset类型命令使用

零基础学习Redis(10) -- zset类型命令使用

zset是有序集合，内部除了存储元素外，还会存储一个score，存储在zset中的元素会按照score的大小升序排列，不同元素的score可以重复，score相同的元素会按照元素的字典序排列。 1. zset常用命令 1.1 zadd  zadd key [NX | XX] [GT | LT]   [CH] [INCR] score member [score member ...]
阅读更多...
搭建Kafka+zookeeper集群调度

搭建Kafka+zookeeper集群调度

前言 硬件环境 172.18.0.5        kafkazk1        Kafka+zookeeper                Kafka Broker集群 172.18.0.6        kafkazk2        Kafka+zookeeper                Kafka Broker集群 172.18.0.7        kafkazk3
阅读更多...
Redis中使用布隆过滤器解决缓存穿透问题

Redis中使用布隆过滤器解决缓存穿透问题

一、缓存穿透(失效)问题 缓存穿透是指查询一个一定不存在的数据，由于缓存中没有命中，会去数据库中查询，而数据库中也没有该数据，并且每次查询都不会命中缓存，从而每次请求都直接打到了数据库上，这会给数据库带来巨大压力。 二、布隆过滤器原理 布隆过滤器（Bloom Filter）是一种空间效率很高的随机数据结构，它利用多个不同的哈希函数将一个元素映射到一个位数组中的多个位置，并将这些位置的值置
阅读更多...
一种改进的red5集群方案的应用、基于Red5服务器集群负载均衡调度算法研究

一种改进的red5集群方案的应用、基于Red5服务器集群负载均衡调度算法研究

转自： 一种改进的red5集群方案的应用： http://wenku.baidu.com/link?url=jYQ1wNwHVBqJ-5XCYq0PRligp6Y5q6BYXyISUsF56My8DP8dc9CZ4pZvpPz1abxJn8fojMrL0IyfmMHStpvkotqC1RWlRMGnzVL1X4IPOa_  基于Red5服务器集群负载均衡调度算法研究 http://ww
阅读更多...
Lua 脚本在 Redis 中执行时的原子性以及与redis的事务的区别

Lua 脚本在 Redis 中执行时的原子性以及与redis的事务的区别

在 Redis 中，Lua 脚本具有原子性是因为 Redis 保证在执行脚本时，脚本中的所有操作都会被当作一个不可分割的整体。具体来说，Redis 使用单线程的执行模型来处理命令，因此当 Lua 脚本在 Redis 中执行时，不会有其他命令打断脚本的执行过程。脚本中的所有操作都将连续执行，直到脚本执行完成后，Redis 才会继续处理其他客户端的请求。 Lua 脚本在 Redis 中原子性的原因
阅读更多...
828华为云征文｜华为云Flexus X实例docker部署rancher并构建k8s集群

828华为云征文｜华为云Flexus X实例docker部署rancher并构建k8s集群

828华为云征文｜华为云Flexus X实例docker部署rancher并构建k8s集群 华为云最近正在举办828 B2B企业节，Flexus X实例的促销力度非常大，特别适合那些对算力性能有高要求的小伙伴。如果你有自建MySQL、Redis、Nginx等服务的需求，一定不要错过这个机会。赶紧去看看吧！ 什么是华为云Flexus X实例 华为云Flexus X实例云服务是新一代开箱即用、体
阅读更多...
kubernetes集群部署Zabbix监控平台

kubernetes集群部署Zabbix监控平台

一、zabbix介绍 1.zabbix简介 Zabbix是一个基于Web界面的分布式系统监控的企业级开源软件。可以监视各种系统与设备的参数，保障服务器及设备的安全运营。 2.zabbix特点 （1）安装与配置简单。 （2）可视化web管理界面。 （3）免费开源。 （4）支持中文。 （5）自动发现。 （6）分布式监控。 （7）实时绘图。 3.zabbix的主要功能
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2