江苏省张家港保税区建设厅网站,wordpress酷炫特效,制作h5的免费软件,做网站的专业公司文章目录1、Redis集群的基本概念2、浅析集群算法-分片-槽位slot2.1 Redis集群的槽位slot2.2 Redis集群的分片2.3 两大优势2.4 如何进行slot槽位映射2.5 为什么redis集群的最大槽数是16384个#xff1f;2.6 Redis集群不保证强一致性3、集群环境搭建3.1 主从容错切换迁移3.2 主从…
文章目录1、Redis集群的基本概念2、浅析集群算法-分片-槽位slot2.1 Redis集群的槽位slot2.2 Redis集群的分片2.3 两大优势2.4 如何进行slot槽位映射2.5 为什么redis集群的最大槽数是16384个2.6 Redis集群不保证强一致性3、集群环境搭建3.1 主从容错切换迁移3.2 主从扩容和缩容4、集群常用操作命令和CRC16算法分析1、Redis集群的基本概念
前面谈到哨兵的作用就是无人值守运维无非就是master宕机slave再顶上去。但此时会有一个大问题 master挂掉后写操作会被暂时中断哨兵们需要投票选举新的master选举新的leader由leader推动故障切换流程至此新的master才能对外提供写操作。在老master宕机到新master上位这个前期redis服务处于一个半瘫痪状态只能读不能写就会导致数据流失这个过程的持续时间可能还会因为硬件、网络等原因增长。因此承受单点高并发的master只有一个是远远不够的。所以Redis就引入了集群
Redis集群由于数据量过大单个Master复制集难以承担因此需要对多个复制集进行集群形成水平扩展每个复制集只负责存储整个数据集的一部分这就是Redis的集群其作用是提供在多个Redis节点间共享数据的程序集。 Redis集群对外是一个整体在内部具体是哪一个实例为客户端提供服务与客户端无关。
例如我打联通客服人工服务我只关心是否能够服务并不关心对应的具体是哪位客服
对应的master宕机了其他master也能对外提供服务除此之外slave会上位成为master也能对外提供服务。因此Redis集群几乎就替代了原来的主从复制哨兵监控机制。
一句话就是Redis集群是一个提供在多个Redis节点间共享数据的程序集
Redis集群能干嘛
Redis集群支持多个Master每个Master又可以挂载多个Slave——读写分离、支持数据的高可用、支持海量数据的读写存储操作由于Cluster自带SentineI的故障转移机制内置了高可用的支持无需再去使用哨兵功能客户端与Redis的节点连接不再需要连接集群中所有的节点只需要任意连接集群中的一个可用节点即可槽位slot负责分配到各个物理服务节点由对应的集群来负责维护节点、插槽和数据之间的关系
2、浅析集群算法-分片-槽位slot
2.1 Redis集群的槽位slot
Redis集群没有使用一致性hash而是引入了哈希槽的概念。Redis集群中内置了16384个哈希槽每个key通过CRC16校验后对16384取模来决定放置哪个槽集群的每个节负责一部分hash槽。 举个例子比如当前集群有3个节点那么
redis1负责槽位0-5460redis2负责槽位5461-10922redis3负责槽位10923-16383 比如冯同学需要写入一个数据它的key为fl经过CRC16运算后对16384进行取余假设余数为721由于721这个槽位是有由redis1负责那么这个写操作就是由redis1完成其他redis不能进行写操作否则会报错。读取操作也是由redis1负责
官方文档说明
大致意思 集群的密钥空间被划分为16384个槽位有效地设置了集群规模的上限为16384个主节点(然而节点的最大值建议是大约1000个节点)。 后续会讲到为什么只有16384个槽位为什么建议最大值为1000个节点
2.2 Redis集群的分片
使用Redis集群时我们会将存储的数据分散到多台redis机器上这称为分片。简言之集群中的每个Redis实例都被认为是整个数据的一个分片。
如何找到给定key的分片
这个问题的答案在前面已经给出但是我还是要再讲一遍加深印象。 为了找到给定key的分片我们对key进行CRC16(key)算法处理并通过对总分片数量取模。然后使用确定性哈希函数这意味着给定的key将多次始终映射到同一个分片我们可以推断将来读取特定key的位置。
2.3 两大优势
采用槽位和分片有两大优势方便扩容和数据分派查找 这种结构很容易添加或者删除节点比如如果我想新添加个节点D我需要将节点A, B, C中的部分槽转移到D上。如果我想移除节点A需要将A中的槽转移到B和C节点上然后将没有任何槽的A节点从集群中移除即可。由于从一个节点将哈希槽移动到另一个节点并不会停止服务所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态
2.4 如何进行slot槽位映射
哈希取余分区 2亿条记录就是2亿个k,v 我们单机不行必须要分布式多机假设有3台机器构成一个集群用户每次读写操作都是根据公式hash(key) % N个机器台数计算出哈希值用来决定数据映射到哪一 个节点上。
优点 简单粗暴直接有效只需要预估好数据规划好节点例如3台、8台、10台就能保证一段时间的数据支撑。使用Hash算法让固定的一部分请求落到同一台服务器上这样每台服务器固定处理一部分请求 ( 并维护这些请求的信息)起到负载均衡分而治之的作用。
缺点 原来规划好的节点进行扩容或者缩容就比较麻烦了额不管扩缩每次数据变动导致节点有变动映射关系需要重新进行计算在服务器个数固定不变时没有问题如果需要弹性扩容或故障停机的情况下原来的取模公式就会发生变化Hash(key)/3会变成Hash(key)/?。此时地址经过取余运算的结果将发生很大变化根据公式获取的服务器也会变得不可控。某个redis机器宕机了由于台数数量变化会导致hash取余全部数据重新洗牌。
一致性哈希
我之前写了一篇博客可以了解一下这里就不多赘述----》一致性哈希
哈希槽分区
哈希槽分区的相关概念已经讲过这里不多赘述。
那么为什么会采用哈希槽分区算法而不采用其他两种方法呢 哈希取余的缺点太过明显就不用说了。而一致性哈希感觉也没啥大毛病为啥不用一致性哈希算法呢 一致性哈希算法可以帮助在Redis节点之间平衡数据负载。但它有一个缺点就是当节点增加或删除时可能需要重新分配许多键值对这会导致大量的数据迁移带来额外的网络开销和延迟。此外一致性哈希算法在节点故障时也可能导致数据不平衡。
哈希槽架构则更加直接。Redis把数据分成固定数量的哈希槽每个节点负责一部分哈希槽。当节点增加或删除时只需将它们的哈希槽重新分配给其他节点即可这个过程不会涉及到大量的数据迁移。这使得Redis的扩展更加容易和可控而且在节点故障时也更加稳定。此外哈希槽架构也更加容易进行备份和恢复操作。
总的来说哈希槽架构相对于一致性哈希算法来说更加简单、可控、易于扩展和稳定这也是Redis采用哈希槽架构的原因。
2.5 为什么redis集群的最大槽数是16384个
CRC16算法产生的hash值有16bit该算法可以产生2^1665536个值。换句话说值是分布在0~65535之间有更大的65536不用为什么只用16384就够作者在做mod运算的时候为什么不mod65536而选择mod16384HASH_ SLOT CRC16(key) mod 65536为什么没启用
看看作者的原话 原话翻译 正常的心跳包携带一个节点的完整配置可以用幂等的方式替换旧的配置以更新旧的配置。这意味着它们包含一个节点的插槽配置以原始形式使用16k插槽使用2k空间但使用65k插槽将使用令人难以忍受的8k空间。 同时由于其他设计上的权衡Redis集群不太可能扩展到1000多个主节点。 因此16k是正确的范围可以确保每个master有足够的插槽最多为1000个maters但这个数字足够小可以很容易地将插槽配置为原始位图。请注意在较小的集群中位图将很难压缩因为当N很小时位图会有槽/N位这是一个很大的百分比。 看不懂没关系作者的意思可以总结为以下三点
(1)如果槽位为65536发送心跳信息的消息头达8k发送的心跳包过于庞大 在消息头中最占空间的是myslots[CLUSTER_SLOTS/8]。 当槽位为65536时 这块的大小是: 65536810248kb 在消息头中最占空间的是myslots[CLUSTER_SLOTS/8]。 当槽位为16384时 这块的大小是: 16384810242kb 因为每秒钟redis 节点需要发送一定 数量的ping消息作为心跳包如果槽位为65536这个ping消息的消息头太大了浪费带宽。 (2)redis的集群主节点数量基本不可能超过1000个 集群节点越多心跳包的消息体内携带的数据越多。如果节点过1000个也会导致网络拥堵。因此redis作者不建议redis cluster节点数量超过1000个。 那么对于节点数在1000以内的redis cluster集群 16384个槽位够用了。没有必要拓展到65536个。
(3)槽位越小节点少的情况下压缩比高 容易传输 Redis主节点的配置信息中它所负责的哈希槽是通过一张bitmap的形式来保存的在传输过程中会对bitmap进行压缩但是如果bitmap的填充率 slots / N很高的话(N表示节点数)bitmap的压缩率就很低。如果节点数很少而哈希槽数量很多的话bitmap的压缩率就很低。
2.6 Redis集群不保证强一致性
Redis集群不保证强一致性 这意味着在特定的条件下Redis集群可能会丢掉一些被系统收到的写入请求命令
例如当客户端写了三条数据此时master也写完成准备给slave同步数据时宕机了这三条数据就丢失了slave上位成为master对外提供服务此时客户端查看数据时并没有这三条数据因此造成了数据不一致
3、集群环境搭建
本次案例我在一台云服务器完成但实际生产上肯定是搭建在多台云服务器上
整体架构 新建6个独立的redis实列服务 每个.conf文件内容都为只需要变动6381即可
bind 0.0.0.0
daemonize yes
protected-mode no
port 6381
logfile /root/myredis/cluster/c1uster6381.log
pidfile /root/myredis/clustercluster6381.pid
dir /root/myredis/cluster
dbfilename dump6381.rdb
appendonly yes
appendfilename appendon1y6381.aof
requirepass 123456
masterauth 123456
cluster-enabled yes #打开集群
Cluster-config-file nodes-6381.conf #集群的配置文件叫nodes-6381.conf
cluster-node-timeout 5000 #集群之间的超时时间在复制上述配置时后面的中文信息一定要删掉否则在启动redis实例时会失败
启动6台redis主机实例 使用命令构建主从关系
redis-cli -a fl12345.0 --cluster create --cluster-replicas 1 ip:6381 ip:6382 ip:6383 ip:6384 ip:6385 ip:6386解释–cluster-replicas 1表示为每个master创建一个slave节点 查看是否生成对应的log和nodes.conf 链接进入6381作为切入点查看并检验集群状 在前面的整体架构图中主机6381下面是从机6382但是现在下面却是从机6384以实际分配为准
可以用命令 cluster nodes 查看集群之间的基本关系 也可以用命令 cluster info 查看信息 验证是否能进行读写操作 为什么插入 k2 v2就行而插入k1 v1 就失败呢 因为k1和k2映射的槽位不同需要到负责对应槽位的redis操作才能成功也就是说需要路由到位
如何解决 退出重新登录加上参数-c防止路由失效
可以看到该操作被重定向到了主机6383
用命令 cluster keyslot key 查看key属于哪个槽位
3.1 主从容错切换迁移
主机6381停机从机6384是否能成功上位成为master 查看集群关系 三主二从新master6384没有slave
6381重新启动是否会再次成为master呢 答案是并不会会以slave的形式回归它会成为主机6384的slave
在上述过程中6381从新上位成了6384的slave但是我们还是想让6381成为6384的master如何做可以使用命令 cluster failover 手动调整节点从属关系 3.2 主从扩容和缩容
主从扩容
新建6387、 6388两个服务实例配置文件新建后启动这里的操作和前面的一样就不多赘述 此时它们自己都是master
将新增的6387节点(空槽号)作为master节点加入原集群
redis-cli -a密码 --cluster add-node 自实际IP地址:6387 自己实际IP地址:63816387就是将要作为master新增节点 使用命令redis-cli -a 123456 --cluster check ip:6381 产看一下对应的集群信息以及槽位信息 重新分配槽号
命令:redis-cli -a 密码 --cluster reshard IP地址:端口号这里选择分配4096个槽位主要原因是一共有16384个槽位4台主机16384 / 4 4096
再次检测集群信息以及槽位信息 为什么6387是3个新的区间以前的还是连续? 重新分配成本太高所以之前的三台主句各自匀出来一部分 从6381/6382/6383三个旧节点分别匀出1364个坑位给新节点6387
为主机6387分配从机6388 命令redis-cli -a 123456 --cluster add-node ip:6388 ip:6387 --cluster-slave --cluster-master-id master_id 第三次检测集群信息以及槽位信息 主从缩容
从集群中将4号从节点6388删除
命令:redis-cli -a 密码 --cluster del-node ip:从机端口 从机6388节点ID检测集群信息查看从机6388是否被删除 将6387的槽号清空重新分配 本例将清出来的槽号都给6381
命令:redis-cli -a 密码 --cluster reshard ip:端口号第二次检查集群信息查看槽号是否重新分配 4096个槽位都指给6381它变成了8192个槽位相当于全部都给6381了不然要输入3次
将主机6387删除
命令:redis-cli -a 密码 --cluster del-node ip:端口号 6387主机ID第三次检查集群信息查看主机6387是否被删除 4、集群常用操作命令和CRC16算法分析
Redis集群有16384个哈希槽每个key通过CRC16校验后对16384取模来决定放置哪个槽。集群的每个节点负责一部分hash槽。到底CRC16是如何调用的 看一下cluster.c源码
再看一下crc16.c的源码
先调用keyHashSlot再调用crc16
集群是否完成才能对外提供服务
cluster-require -full coverage默认是yes现在集群架构是3主3从的redis cluster由3个master平分16384个slot每个master的小集群负责1/3的slot对应一部分数据。cluster-require-full-coverage默认值 yes 即需要集群完整性方可对外提供服务通常情况如果这3个小集群中任何一个(1主1从)挂了你这个集群对外可提供的数据只有2/3了整个集群是不完整的 redis默认在这种情况下是不会对外提供服务的。
如果你的诉求是集群不完整的话也需要对外提供服务需要将该参数设置为no这样的话你挂了的那个小集群是不行了但是其他的小集群 仍然可以对外提供服务。
不在同一个slot槽位下的键值无法使用mset、mget等多键操作因为请求没有对应到相应的槽位
不在同一个slot槽位下的多键操作支持不好通识占位符登场 可以通过{}来定义同一 个组的概念使key中{}内相同内容的键值对放到一个slot槽位去
{ }里面的z可以换成任何标识符
cluster countkeysinslot 槽位数字编号 如果返回值为0表示该槽位没有被占用
如果返回值为1表示该槽位已经被占用
cluster keyslot 键名称 判断某个键的槽位
