新手小白学习docker第七弹------安装redis集群大厂面试

时间：2024-11-18 16:59:56

docker目录

  • 0 引言
  • 1 面试题
    • 1.1 哈希取余分区
      • 1.1.1 是什么
      • 1.1.2 优点
      • 1.1.3 缺点
    • 1.2 一致性哈希算法分区
      • 1.2.1 背景
      • 1.2.2 目的
      • 1.2.3 三大步骤
        • （1）算法构建一致性哈希环
        • （2）服务器IP节点映射
        • （3）key落到服务器的落键规则
      • 1.2.4 优点
        • （1）容错性
        • （2）扩展性
      • 1.2.5 缺点
    • 1.3 哈希槽分区
      • 1.3.1 背景
      • 1.3.2 是什么
      • 1.1.3 计算
  • 2）3主3从redis集群配置
    • 关闭防火墙+启动docker后台服务器
    • 新建6个dockers容器redis实例
    • 进入容器redis-node-1并为6台机器构建集群关系
    • 链接进入6381作为切入点，查看集群状态
  • 3 主从容错切换迁移案列
    • 3.1 数据读写存储
    • 3.2 容错切换迁移
  • 4 后记

0 引言

本节咱么就来学习redis集群配置，先从一个面试题开始叭。

1 面试题

1~2亿条数据需要缓存，请问如何设计这个存储案例
单机单台100%是不可能的，一定是分布式存储，那用redis如何落地实现呢？

有三种解决方案
1 哈希取余分区
2 一致性哈希算法分区
3 哈希槽分区

1.1 哈希取余分区

1.1.1 是什么

这个很好理解，加入我们有3个分区，将数据用3进行取余就可以，余数为0就将数据存储到0分区的redis中，若余数为1，就将数据存储到1分区的redis中；若余数为2就将数据存储到2分区的redis中。

1.1.2 优点

操作简单，容易理解

1.1.3 缺点

原来规划好的节点，进行扩容或者缩容就比较麻烦，无论是扩容还是缩容，每次数据变动会导致节点变动，映射关系需要重新进行计算，在服务器个数固定不变时没有问题，如果需要弹性扩容或故障停机的情况，原来的取模公式就会发生变化。同时，若某个redis机器宕机了，由于台数的变化，会导致hash取余全部数据重新洗牌。

1.2 一致性哈希算法分区

1.2.1 背景

一致性哈希算法在1997年由麻省理工学院提出的，设计目标是为了解决分布式缓存数据变动和映射问题，某个机器宕机了，分母数量改变了，自然取余数就无法继续了。

1.2.2 目的

当服务器个数发生变动时，尽量减少影响客户端到服务器的映射关系。

1.2.3 三大步骤

（1）算法构建一致性哈希环

一致性哈希算法有一个hash函数并按照算法产生hash值，这个算法的可能hash值会构成一个全量集，这个集合可以成为一个hash空间 [ 0 , 2 32 − 1 ] [0, 2^{32}-1] [0,232−1]，这是一个线性空间，但在算法中，我们通过适当的逻辑控制将它首尾相连 ( 0 = 2 32 ) (0=2^{32}) (0=232)，这样，让它逻辑上形成一个环形
在这里插入图片描述

比如，圆环的正上方的点代表0，0点右侧的第一个点代表1，以此类推， 2 、 3 、 4 、 . . . 、 0 , 2 32 − 1 2、3、4、...、0, 2^{32}-1 2、3、4、...、0,232−1，也就是说0点左侧的第一个点代表 2 32 − 1 2^{32}-1 232−1，0和 2 32 − 1 2^{32}-1 232−1在零点中方向重合，我们把这个由 2 32 2^{32} 232个点组成的圆环称为Hash环。

（2）服务器IP节点映射

将集群中各个IP节点映射到环上的某一个位置。
在这里插入图片描述

将各个服务器使用Hash进行一个哈希，具体可以选择服务器的IP或主机名作为关键字进行哈希，这样每台机器就能确定其在哈希环上的位置。加入4个节点NodeA、B、C、D，经过IP地址的哈希函数计算（hash(ip)），使用IP地址哈希后在环上的位置如上图所示。

（3）key落到服务器的落键规则

当我们需要存储一个kv键值对的时候，首先计算key的hash值，hash(key)，将这个key相同的函数Hash计算出哈希值并确定此数据在环上的位置，从此位置沿环顺时针“走”，第一台遇到的服务器就是其应该定位到的服务器，并将该键值对存储在该节点上。
在这里插入图片描述
如我们有Object A、Object B、Object C、Object D四个数据对象，经过哈希计算后，在环空间上的位置如下：根据一致性Hash算法，数据A会被定为到Node A上，B被定为到Node B上，C被定为到Node C上，D被定为到Node D上。

1.2.4 优点

（1）容错性

假设Node C节点宕机，可以看到此时对象A\B\D不会受到影响，只有C对象被重新，只有C对象被重定位到Node D。简单来说，C宕机了，受影响的只是B\C之间的数据，并且这些数据会转移到D进行存储。

（2）扩展性

在这里插入图片描述

数据量增加了，需要增加一台节点Node X，X的位置在A和B之间，那受到影响的也就是A到X的数据，重新把A到X的数据录入到X上即可，不会导致hash取余全部数据重新洗牌。

1.2.5 缺点

数据倾斜问题
在这里插入图片描述

一致性Hash算法在服务节点太少时，容易因为节点分布不均匀而造成数据倾斜（被缓存的对象大部分集中缓存在某一台服务器上），如大部分数据缓存在了A上

1.3 哈希槽分区

1.3.1 背景

因为一致性哈希算法分区存在数据倾斜的问题

1.3.2 是什么

哈希槽实质是一个数组，数组 [ 0 , 2 14 − 1 ] [0, 2^{14}-1] [0,214−1]形成的hash slot空间。

它能够解决均匀分配的问题，在数据和节点之间又加入了一层，把这层称为哈希槽(slot)，用于管理数据和节点之间的关系，就相当于节点上放的是槽，槽里放的是数据。
在这里插入图片描述

1.1.3 计算

槽解决的是粒度问题，相当于把粒度变大了，便于数据移动。哈希解决的是映射问题，使用key的哈希值来计算所在的槽，便于数据分配。

一个集群只能由16384个槽，编号 ( 0 , 2 14 − 1 ) (0,2^{14}-1) (0,214−1)。这些槽会分配给集群的所有主节点，分配策略没有要求。可以指定哪些编号的槽分给哪个主节点。集群会记录节点和槽的对应关系。解决了槽和节点的关系后，就需要对key求哈希值，然后对16384取余，余数是多少key就落入对应的槽里。 s l o t = C R C ( k e y ) % 16384 slot=CRC(key)\%16384 slot=CRC(key)%16384。以槽为单位移动数据，因为槽的数目是固定的，处理起来比较容易，这样数据移动问题就解决了。

2）3主3从redis集群配置

关闭防火墙+启动docker后台服务器

关闭防火墙命令：

systemctl stop firewalld

启动docker后台服务器

sytemctl start docker

在这里插入图片描述

新建6个dockers容器redis实例

docker run -d --name redis-node-1 --net host --privileged=true -v /data/redis/share/redis-node-1:/data redis:6.0.8 --cluster-enabled yes --appendonly yes --port 6381
docker run -d --name redis-node-2 --net host --privileged=true -v /data/redis/share/redis-node-2:/data redis:6.0.8 --cluster-enabled yes --appendonly yes --port 6382
docker run -d --name redis-node-3 --net host --privileged=true -v /data/redis/share/redis-node-3:/data redis:6.0.8 --cluster-enabled yes --appendonly yes --port 6383
docker run -d --name redis-node-4 --net host --privileged=true -v /data/redis/share/redis-node-4:/data redis:6.0.8 --cluster-enabled yes --appendonly yes --port 6384
docker run -d --name redis-node-5 --net host --privileged=true -v /data/redis/share/redis-node-5:/data redis:6.0.8 --cluster-enabled yes --appendonly yes --port 6385
docker run -d --name redis-node-6 --net host --privileged=true -v /data/redis/share/redis-node-6:/data redis:6.0.8 --cluster-enabled yes --appendonly yes --port 6386

在这里插入图片描述

这里介绍一下各个参数的含义：

 --name表示容器的名字
 --net host 使用宿主机的IP和端口，默认
 --privileged=true 获取宿主机root的用户权限
 -v /data/redis/share/redis-node-6:/data 表示容器卷，宿主机地址:docker内部地址
 redis:6.0.8 表示redis镜像和版本号
 --cluster-enabled yes 开启redis集群
 --appendonly yes 表示开启持久化
 --port 6386 表示redis的端口号

进入容器redis-node-1并为6台机器构建集群关系

docker exec -it redis-node-1 /bin/bash

在宿主机中，执行ifconfig来查看主机的ip

ifconfig

192.168.91.132

在这里插入图片描述

redis-cli --cluster create 192.168.91.132:6381 192.168.91.132:6382 192.168.91.132:6383 192.168.91.132:6384 192.168.91.132:6385 192.168.91.132:6386 --cluster-replicas 1

--cluster-replicas 1 表示为每一个master创建一个slave节点

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

链接进入6381作为切入点，查看集群状态

redis-cli -p 6381

cluster info

cluster nodes

在这里插入图片描述

3 主从容错切换迁移案列

3.1 数据读写存储

启动6机构成的集群并通过exec进入

docker exec -it redis-node-1 /bin/bash
redis-cli -p 6381

对6381新增几个key

set k1 v1
set k2 v2
set k3 v3
set k4 v4

在这里插入图片描述

防止路由失效加参数-c并新增两个key

redis-cli -p 6381 -c
flushall
set k1 v1
set k2 v2
set k3 v3
set k4 v4

在这里插入图片描述

查看集群信息

redis-cli --cluster check 自己的ip地址:6381

在这里插入图片描述

3.2 容错切换迁移

为什么需要主设备和从设别呢，因为害怕机器出现故障，有从设备的存在，我们就可以有容错性，让故障的损失降到最小
首先让6381宕机

docker stop redis-node-1

在这里插入图片描述

再次根据之前的步骤查看集群中节点的关系，不难发现，1节点的slave变成了master
然后我们再关闭4节点，启动1节点
在这里插入图片描述

docker stop redis-node-4
docker start redis-node-1

在这里插入图片描述

会发现1成为了master
接着启动4节点
又回到了开始的状态，1节点是4节点的主节点

最后，我们再查看一下集群的状态

redis-cli --cluster check 192.168.91.132:6382

在这里插入图片描述

4 后记

今天吃的食堂，稍微有点咸了，不过鸡蛋和豆子还是很好吃的嘛！

BB，如果文档对您有用的话，记得给我点个赞赞！您的赞赞对我非常重要滴，写作的动力百分之八十来自您！

相关文章