docker小白第九天

docker小白第九天

安装redis集群

cluster(集群)模式-docker版本,哈希槽分区进行亿级数据存储。如果1~2亿条数据需要缓存,请问如何设计这个存储案例。单机存储是不可能的,需要分布式存储,如果使用redis又该如何部署。

哈希取余分区

docker小白第九天_第1张图片
优点:简单粗暴,直接有效,只需要预估好数据,规划好节点,例如3台、8台、10台,就能保证一段时间的数据支撑。使用Hash算法让固定的一部分请求落到同一台服务器上,这样每台服务器固定处理一部分请求(并维护这些请求的信息),起到负载均衡+分而治之的作用。
缺点:原来规划好的节点,进行扩容或者缩容就比较麻烦,不管扩缩,每次数据变动导致节点有变动,映射关系需要重新进行计算,在服务器个数固定不变时没有问题,如果需要弹性扩容或故障停机的情况下,原来的取模公式就会发生变化:Hash(key)/3会变成Hash(key)/?。此时地址经过取余运算的结果将发生很大变化,根据公式获取的服务器也会变得不可控。某个redis机器宕机了,由于机器台数数量变化,会导致hash取余全部数据重新洗牌。

一致性哈希算法分区

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

  • 算法构建一致性哈希环
  • 服务器lP节点映射
  • key落到服务器的落键规则

1、构建哈希环:一致性哈希算法必然有个hash函数,并按照算法产生hash值,这个算法的所有可能哈希值构成一个全量集合,这个集合可以成为一个hash空间【0,(2^32)-1】,这个是一个线性空间,但是在算法中,我们通过适当的逻辑控制将它首尾相连(0=2*32),这样让它逻辑上形成了一个环形空间。
一致性哈希也是按照使用取模的方法,前面笔记介绍的节点取模法是对节点(服务器)的数量进行取模。而一致性Hash算法是对2’32取模,简单来说,一致性Hash算法将整个哈希值空间组织成一个虚拟的圆环,如假设某哈希函数H的值空间为0到(2^ 32)-1(即哈希值是一个32位无符号整形),整个哈希环如下图:整个空间按顺时针方向组织,圆环的正上方的点代表0,0点右侧的第一个点代表1,以此类推,2、3、4、……直到2^ 32-1,也就是说O点左侧的第一个点代表2^ 32-1,0和2^ 32-1在零点中方向重合,我们把这个由2^32个点组成的圆环称为Hash环。
2、IP节点映射:
将集群中各个IP节点映射到环上的某一个位置。将各个服务器使用Hash进行一个哈希,具体可以选择服务器的IP或主机名作为关键字进行哈希,这样每台机器就能确定其在哈希环上的位置。假如4个节点NodeA、B、C、D,经过IP地址的哈希函数计算(hash(ip)),使用IP地址哈希后在环空间的位置如下:
docker小白第九天_第2张图片
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上。
docker小白第九天_第3张图片
优点:假设Node c宕机,可以看到此时对象A、B、D不会受到影响,只有object C对象被重定位到Node D。一般的,在一致性Hash算法中,如果一台服务器不可用,则受影响的数据仅仅是此服务器到其环空间中前一台服务器(即沿着逆时针方向行走遇到的第一台服务器〉之间数据,其它不会受到影响。就是C宕机,受到影响的只是B、C之间的数据,并且这些数据会转移到D进行存储。假设数据量增加了,需要增加一台节点Nodex,X的位置在A和B之间,那收到影响的也就是A到X之间的数据,重新把A到X的数据录入到X上即可,不会导致hash取余全部数据重新洗牌。

缺点:一致性哈希算法的数据倾斜问题,在服务节点太少时,容易因为节点分布不均匀而造成数据倾斜(被缓存的对象大部分集中缓存在某一台服务器上),例如系统中只有两合服务器:

docker小白第九天_第4张图片

哈希槽分区

哈希槽实质就是一个数组,数组[0,(2^14)-1]形成hash slot空间。解决缓存数据均匀分配的问题,在数据和节点之间又加入了一层,把这层称为哈希槽(slot),用于管理数据和节点之间的关系,现在就相当于节点node上放的是槽,槽里放的是数据。

docker小白第九天_第5张图片
槽解决的是粒度问题,相当于把粒度变大了,这样便于数据移动(即一堆数据算做一类,以前是一个数据算做一类)。哈希解决的是映射问题,使用key的哈希值来计算所在的槽,便于数据分配。节点数1000以内的redis集群,槽位最多16384个。这些槽会分配给集群中的所有主节点,分配策略没有要求。可以指定哪些编号的槽分配给哪个主节点。集群会记录节点和槽的对应关系。解决了节点和槽的关系后,接下来就需要对key求哈希值,然后对16384取余,余数是几key就落入对应的槽里。slot =CRC16(key) % 16384。以槽为单位移动数据,因为槽的数目是固定的,处理起来比较容易,这样数据移动问题就解决了。
Redis集群中内置了16384个哈希槽、redis会根据节点数量大致均等的将哈希槽映射到不同的节点。当需要在Redis集群中放置一个key-valuel时,redis先对 key使用crc16算法算出一个结果,然后把结果对16384求余数,这样每个key都会对应一个编号在0-16383之间的哈希槽,也就是映射到某个节点上。如下代码,kéy取A、取B时在Node2, key取C时落在Node3上。
docker小白第九天_第6张图片

3主3从配置redis集群

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

先关闭防火墙,并确认dokcer是启动状态的

systemctl stop firewalld
systemctl start docker

然后开启新建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
# --cluster-enabled yes 是开启集群配置
# 创建并运行docker容器实例 docker run
# 容器名字--name redis-node-1
# 使用宿主机的IP和端口,默认--net host
# 获取宿主机root用户权限 --privileged=true
# 挂载容器卷,-v 宿主机地址:docker内部地址地
# redis镜像和版本号redis:6.0.8
# 开启持久化 --appendonly yes
# redis端口号--port 6381

依次修改节点的数字和端口的数字,执行六次新建容器命令
docker小白第九天_第7张图片

docker ps

查看启动后的容器
docker小白第九天_第8张图片
进入redis节点1的容器命令行配置,注意其中的ip要换为自己的真实ip地址。–cluster-replicas 1表示为每个master创建一个slave节点。

docker exec -it redis-node-1 /bin/bash
redis-cli --cluster create 192.168.0.175:6381 192.168.0.175:6382 192.168.0.175:6383 192.168.0.175:6384 192.168.0.175:6385 192.168.0.175:6386 --cluster-replicas 1

可以看到,自动创建了三个hash slots(哈希槽),分配给了三个主redis节点,另外新建了三个备redis节点,与主节点对应。
docker小白第九天_第9张图片
在redis节点1的命令行,查看集群状态

redis-cli -p 6381
# 连接到节点1的端口
cluster info
# 查看集群信息

docker小白第九天_第10张图片

cluster nodes
# 更详细的3主3从集群信息

注意,这里的主从对应的序号,是不固定的,是随机的,有可能1号机与4号机,做主从关系,有可能1号机与5号机,做主从关系。
docker小白第九天_第11张图片

redis集群读写error,优化路由案例

# 进入第一个redis节点的容器命令行
docker exec -it redis-node-1 /bin/bash
# 客户端进入redis节点1,通过端口6381
redis-cli -p 6381
# 输入命令查看里边是否有数据
keys *

可以看到里边数据为空。
在这里插入图片描述
输入以下命令存储数据,发现会报错。是因为经过哈希运算,需要分配给该数据的槽位是12706,超过了redis节点1的最大槽位5460,通过端口6383判断,该数据应该被存至redis节点3。

set k1 v1

在这里插入图片描述
可以通过修改连接集群的命令,新增数据。不通过redis-cli -p 6381这种单机的方式连接,造成数据只访问redis节点1。为防止数据自动跳转路由失效,加参数-c,代表使用的是集群环境,并新增两个key,测试

# 在redis节点1容器的命令行,输入如下命令
redis-cli -p 6381 -c
set k1 v1
set k2 v2

可以看到都存储成功了,并且经过哈希计算后,若待分配的槽位不在节点1时,自动redicrt重定向数据到对应的节点。
docker小白第九天_第12张图片

# 在节点1容器的命令行界面,查看集群信息
redis-cli --cluster check 192.168.0.175:6381

可以看到刚刚存储的两个键值对,分别在哪。还有其他一些集群信息。
docker小白第九天_第13张图片

你可能感兴趣的:(docker,容器,运维)