Linux系统下Redis3.2集群

本节主要学习reids主从复制的概念,作用,缺点,流程,搭建,验证,reids哨兵模式的概念,作用,缺点,结构,搭建,验证等。


文章目录

一、redis主从复制

1.概念

2.作用

3.缺点

4.流程

5.搭建

1.主服务器

2.从服务器

6.验证

二、redis哨兵模式

1.概念

2.作用

3.缺点

4.结构

5.搭建

6.验证

三、redis集群

1.概述

2.原理

3.架构细节

4.选举过程

5.搭建

              mkdir /etc/redis

              mv /etc/redis.conf  /etc/redis/6379.conf

              cd /etc/redis

              for i in {0..4};do cp ./6379.conf ./638${i}.conf;done

              for i in {0..4};do sed -i "s/port 6379/port 638${i}/" ./638${i}.conf;done

              sed -i "s/dir \/var\/lib\/redis/dir \/var\/lib\/redis\/6379/" ./6379.conf

             for i in {0..4};do sed -i "s/dir \"\/var\/lib\/redis\/6379\"/dir \"\/var\/lib\/redis\/638${i}\"/"

             ./638${i}.conf;done

              cd /var/lib/redis

              mkdir 6379 638{0..4}

分别修改配置文件中

 启动服务

 构建集群

将其他节点加入集群

分配slot

 建立主从关系

​编辑 3.2redis分布式部署

 3.2.1安装redis

 3.2.2配置文件

 3.2.3将其他节点加入集群

3.2.4分配slot

3.2.5 建立主从关系

3.2.6查看状态

 查看命令

重置集群命令


一、redis主从复制

1.概念

              是指将一台Redis服务器的数据,复制到其他的Redis服务器。前者称为主节点(Master),后者称为从节点(Slave);数据的复制是单向的,只能由主节点到从节点。

2.作用

数据冗余 主从复制实现了数据的热备份,是持久化之外的一种数据冗余方式。
故障恢复 当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复;实际上是一种服务的冗余。
负载均衡 在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务(即写Redis数据时应用连接主节点,读Redis数据时应用连接从节点),分担服务器负载;尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大大提高Redis服务器的并发量。
高可用 除了上述作用以外,主从复制还是哨兵和集群能够实施的基础,因此说主从复制是Redis高可用的基础。

3.缺点

              故障恢复无法自动化;

              写操作无法负载均衡;

              存储能力受到单机的限制。

4.流程

第一步 若启动一个Slave机器进程,则它会向Master机器发送一个“sync command”命令,请求同步连接。
第二步 无论是第一次连接还是重新连接,Master机器都会启动一个后台进程,将数据快照保存到数据文件中(执行rdb操作),同时Master还会记录修改数据的所有命令并缓存在数据文件中。 
第三步 后台进程完成缓存操作之后,Maste机器就会向Slave机器发送数据文件,Slave端机器将数据文件保存到硬盘上,然后将其加载到内存中,接着Master机器就会将修改数据的所有操作一并发送给Slave端机器。若Slave出现故障导致宕机,则恢复正常后会自动重新连接。
第四步 Master机器收到Slave端机器的连接后,将其完整的数据文件发送给Slave端机器,如果Mater同时收到多个Slave发来的同步请求,则Master会在后台启动一个进程以保存数据文件,然后将其发送给所有的Slave端机器,确保所有的Slave端机器都正常。

5.搭建

1.主服务器

 修改配置文件

                  bind  0.0.0.0


                  port  6379

Linux系统下Redis3.2集群_第1张图片
                  protected-mode = no


                  daemonize = yes

 Linux系统下Redis3.2集群_第2张图片

2.从服务器

修改配置文件

bind  0.0.0.0
port  6380
protected-mode = no
daemonize = yes

slaveof 192.168.254.1 6379 —主的服务器的地址及端口

复制/etc/redis.conf 到/opt/ redis-server-6380.conf

改变端口号

 Linux系统下Redis3.2集群_第3张图片

 修改主从

Linux系统下Redis3.2集群_第4张图片

6.验证

               使用redis-cli命令行登录redis服务器,输入role指令查看状态

               在master节点上,录入数据,在slave节点上查看到对应数据即可

服务器

Linux系统下Redis3.2集群_第5张图片

 从服务器查看

Linux系统下Redis3.2集群_第6张图片

二、redis哨兵模式

1.概念

             是一个分布式系统,用于对主从结构中的每台服务器进行监控,当出现故障时通过投票机制选择新的 Master 并将所有 Slave 连接到新的 Master。所以整个运行哨兵的集群的数量不得少于3个节点。
            依托于主从模式

2.作用

监控 哨兵会不断地检查主节点和从节点是否运作正常。
自动故障转移 当主节点不能正常工作时,哨兵会开始自动故障转移操作,它会将失效主节点的其中一个从节点升级为新的主节点,并让其他从节点改为复制新的主节点。
通知(提醒) 哨兵可以将故障转移的结果发送给客户端。

3.缺点

              写操作无法负载均衡
              存储能力受到单机的限制
              哨兵无法对从节点进行自动故障转移,在读写分离场景下,从节点故障会导致读服务不可用,需要对从节点做额外的监控、切换操作。

4.结构

              哨兵节点:哨兵系统由一个或多个哨兵节点组成,哨兵节点是特殊的redis节点,不存储数据。

              数据节点:主节点和从节点都是数据节点。

5.搭建

bind 0.0.0.0
port 26379
daemonize  yes——自己添加或者启动服务时加’ & ‘符号
sentinel monitor mymaster 192.168.115.160 6379 2
启动    redis-sentinel  配置文件路径

 Linux系统下Redis3.2集群_第7张图片

 Linux系统下Redis3.2集群_第8张图片

 

6.验证

停止master后,slave会通过选举产生新的master

哨兵配置文件会自动修改监听的master节点地址为新的master节点地址

Linux系统下Redis3.2集群_第9张图片

三、redis集群

1.概述

               Redis3.0版本以上开始支持cluster,采用的是hashslot(hash槽),可以将多个Redis实例整合在一起,形成一个群集,也就是将数据分散到群集的多台机器上。

2.原理

               Redis Cluster是一个无中心的结构,每个节点都保存数据和整个群集的状态。每个节点都会保存其他节点的信息,知道其他节点所负责的槽,并且会与其他节点定时发送心跳信息,能够及时感知群集中异常的节点。

当客户端向群集中任一节点发送与数据库键有关的命令时,接收命令的节点会计算出命令要处理的数据库键属于哪个槽,并检查这个槽是否指派给了自己。如果键所在的槽正好指派给了当前节点,那么节点直接执行这个命令;如果键所在的槽并没有指派给当前节点,那么节点会向客户端返回一个MOVED错误,指引客户端转向(redirect)正确的节点,并再次发送之前想要执行的命令.
群集角色有Master和Slave.Master之间分配slots,一共16384个slot,Slave向它指定的Master 同步数据,实现备份。当其中的一个Master无法提供服务时,该Master的Slave将提升为Mester,以保证群集间 slot 的完整性,当其中的某一个Master和它的Slave都失效,导致了slot不完整,群集失效,这时就需要人工去处理了。
群集搭建好后,群集中的每个节点都会定期地向其他节点发送PING消息,如果接收PONG消息的节点没有在规定的时间内返回PONG 消息,那么发送PNG消息的节点就会将其标记为疑似下线(probable fail,PFAL)。各个节点会通过互相发送消息的方式来交换群集中各个节点的状态信息。如果在一个群集里面,半数以上的主节点都将某个主节点×报告为疑似下线,那么这个主节点×将被标记为已下线(FAL),同时会向群集广播一条关于主节点×的FAL消息,所有收到这条FAL消息的节点都会立即将主节点×标记为已下线。
当需要减少或者增加群集中的机器时,我们需要将已经指派给某个节点(源节点)的槽改为指派给另一个节点(目标节点),并且将相关槽所属的键值对从源节点移动到目标节点。
Redis群集的重新分片操作是由Redis的群集管理软件redis—trib负责执行的,不支持自动的分片,而且需要自己计算从哪些节点上迁移多少 Slot。在重新分片的过程中,群集不需要下线,并且源节点和目标节点都可以继续处理命令请求。

3.架构细节

(1)所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
(2)节点的失效(fail)在群集中超过半数的主(master)节点检测失效时才生效。
(3)客户端与 redis 节点直连,不需要中间代理(proxy)层,客户端不需要连接群集所有节点,连接群集中任何一个可用节点即可。
(4)redis-cluster 把所有的物理节点映射到【0-16383】slot 上,cluster 负责维护 node<->slot<->key。

4.选举过程

如果群集任意 master挂掉,且当前 master 没有 slave,则群集进入 fail状态,也可以理解成群集的slot映射【0 ~16383】不完整时进入fail状态。
如果群集中超过半数的master挂掉,无论是否有slave,群集都进入 fail状态。
默认情况下,每个群集的节点都使用两个TCP端口.一个是6379,一个是16379;6379服务于客户端的连接,16379 用于群集总线,即使用二进制协议的节点到节点通信通道。节点使用群集总线进行故障检测、配置更新、故障转移授权等。如果开启了防火墙,需要开放这两个端口。

5.搭建

              mkdir /etc/redis
              mv /etc/redis.conf  /etc/redis/6379.conf
              cd /etc/redis
              for i in {0..4};do cp ./6379.conf ./638${i}.conf;done
              for i in {0..4};do sed -i "s/port 6379/port 638${i}/" ./638${i}.conf;done
              sed -i "s/dir \/var\/lib\/redis/dir \/var\/lib\/redis\/6379/" ./6379.conf
             for i in {0..4};do sed -i "s/dir \"\/var\/lib\/redis\/6379\"/dir \"\/var\/lib\/redis\/638${i}\"/"
             ./638${i}.conf;done
              cd /var/lib/redis
              mkdir 6379 638{0..4}

分别修改配置文件中

port
cluster-enabled yes
cluster-config-file nodes-【6379~6384】.conf
cluster-node-timeout 15000

 79号端口Linux系统下Redis3.2集群_第10张图片

或者80

Linux系统下Redis3.2集群_第11张图片

 启动服务

                for((i=6379;i<=6384;i++));do redis-server /etc/redis/${i}.conf;done

 构建集群

将其他节点加入集群

 CLUSTER MEET 192.168.115.128 6380
 CLUSTER MEET 192.168.115.128 6381
 CLUSTER MEET 192.168.115.128 6382
 CLUSTER MEET 192.168.115.128 6383
 CLUSTER MEET 192.168.115.128 6384

分配slot

redis-cli -p 6379 cluster addslots {0..5461}
redis-cli -p 6381 cluster addslots {5462..10922}
redis-cli -p 6383 cluster addslots {10923..16383}

Linux系统下Redis3.2集群_第12张图片

 建立主从关系

redis-cli -p 6380 cluster replicate b356143b3ca4f07cceb30634618339ed107f793c
 redis-cli -p 6382 cluster replicate 5cca472f9816273103769adb32b3a1b562f42655
redis-cli -p 6384 cluster replicate 6d7219fd6db32e6014955edbeda26af6b59b9078

 3.2redis分布式部署

如图所示三台服务器,一个服务器上部署两个redis服务

Linux系统下Redis3.2集群_第13张图片

 3.2.1安装redis

更新eple源,安装redis

yum install -y eple-release

yum install -y redis

Linux系统下Redis3.2集群_第14张图片

Linux系统下Redis3.2集群_第15张图片

 3.2.2配置文件

创建目录/etc/redis

Linux系统下Redis3.2集群_第16张图片

cp两个/etc/redis.conf到/etc/redis

修改配置文件/etc/redis/redis-6380、6379.conf

bind

Linux系统下Redis3.2集群_第17张图片

 port

Linux系统下Redis3.2集群_第18张图片

 dir并且 在/ver/lib/redis/创建 redis1-6379/目录

Linux系统下Redis3.2集群_第19张图片

 Linux系统下Redis3.2集群_第20张图片

 将deamoize字段改为yes

Linux系统下Redis3.2集群_第21张图片

 将以下字段打开

cluster-enabled yes
cluster-config-file nodes-【6379~6384】.conf
cluster-node-timeout 15000

 Linux系统下Redis3.2集群_第22张图片

以上操作重复三遍,三台服务器配置六个redis服务

起服务查看状态(三台都看)

Linux系统下Redis3.2集群_第23张图片

 3.2.3将其他节点加入集群

(在192.168.x.3    6379登录数据库加入其他节点)

CLUSTER MEET 192.168.x.4 6379

CLUSTER MEET 192.168.x.3 6380

CLUSTER MEET 192.168.x.4 6380

CLUSTER MEET 192.168.x.15 6380

CLUSTER MEET 192.168.x.5 6379

Linux系统下Redis3.2集群_第24张图片

Linux系统下Redis3.2集群_第25张图片

3.2.4分配slot

redis-cli -p 6379 cluster addslots {0..5461}
redis-cli -p 6381 cluster addslots {5462..10922}
redis-cli -p 6383 cluster addslots {10923..16383}

Linux系统下Redis3.2集群_第26张图片

3.2.5 建立主从关系

redis-cli -h 192.168.6.4 -p 6379 cluster replicate c47cd6909b43532f4d80acd80e77214d9cee045
redis-cli -h 192.168.6.3 -p 6379 cluster replicate f7ff9e38edd536633c580a9410867ee615618d33
redis-cli -h 192.168.6.5-p 6380 cluster replicate fc2069a00c2ed13628f10d06254378085baeb4d0

3.2.6查看状态

 查看命令

    cluster nodes        查看所有群集节点

    cluster info        查看群集状态

Linux系统下Redis3.2集群_第27张图片

重置集群命令

    cluster reset    数据的key不能相同

你可能感兴趣的:(linux,运维,服务器)