python 可以做网站吗,免费企业建站源代码,客户管理软件单机版,网页游戏交易平台官网作者 | 码哥字节来源 | 码哥字节本文将对集群的节点、槽指派、命令执行、重新分片、转向、故障转移、消息等各个方面进行深入拆解。目的在于掌握什么是 Cluster #xff1f;Cluster 分片原理#xff0c;客户端定位数据原理、故障切换#xff0c;选主#xff0c;什么场景使用… 作者 | 码哥字节来源 | 码哥字节本文将对集群的节点、槽指派、命令执行、重新分片、转向、故障转移、消息等各个方面进行深入拆解。目的在于掌握什么是 Cluster Cluster 分片原理客户端定位数据原理、故障切换选主什么场景使用 Cluster如何部署集群 …...将数据分成多份存在不同实例上哈希槽与 Redis 实例映射复制与故障转移故障检测故障转移选主流程用表保存键值对和实例的关联关系可行么重新分配哈希槽MOVED 错误ASK 错误Gossip 消息实例的通信频率降低实例间的通信开销为什么需要 Cluster“65 哥码哥自从用上了你说的哨兵集群实现故障自动转移后我终于可以开心的跟女朋友么么哒也不怕 Redis 宕机深夜宕机了。可是最近遇到一个糟心的问题Redis 需要保存 800 万个键值对占用 20 GB 的内存。我就使用了一台 32G 的内存主机部署但是 Redis 响应有时候非常慢使用 INFO 命令查看 latest_fork_usec 指标最近一次 fork 耗时发现特别高。”主要是 Redis RDB 持久化机制导致的Redis 会 Fork 子进程完成 RDB 持久化操作fork 执行的耗时与 Redis 数据量成正相关。而 Fork 执行的时候会阻塞主线程由于数据量过大导致阻塞主线程过长所以出现了 Redis 响应慢的表象。“65 哥随着业务规模的拓展数据量越来越大。主从架构升级单个实例硬件难以拓展且保存大数据量会导致响应慢问题有什么办法可以解决么”保存大量数据除了使用大内存主机的方式我们还可以使用切片集群。俗话说「众人拾材火焰高」一台机器无法保存所有数据那就多台分担。使用 Redis Cluster 集群主要解决了大数据量存储导致的各种慢问题同时也便于横向拓展。两种方案对应着 Redis 数据增多的两种拓展方案垂直扩展scale up、水平扩展scale out。垂直拓展升级单个 Redis 的硬件配置比如增加内存容量、磁盘容量、使用更强大的 CPU。水平拓展横向增加 Redis 实例个数每个节点负责一部分数据。比如需要一个内存 24 GB 磁盘 150 GB 的服务器资源有以下两种方案水平拓展与垂直拓展在面向百万、千万级别的用户规模时横向扩展的 Redis 切片集群会是一个非常好的选择。“65 哥那这两种方案都有什么优缺点呢”垂直拓展部署简单但是当数据量大并且使用 RDB 实现持久化会造成阻塞导致响应慢。另外受限于硬件和成本拓展内存的成本太大比如拓展到 1T 内存。水平拓展便于拓展同时不需要担心单个实例的硬件和成本的限制。但是切片集群会涉及多个实例的分布式管理问题需要解决如何将数据合理分布到不同实例同时还要让客户端能正确访问到实例上的数据。什么是 Cluster 集群Redis 集群是一种分布式数据库方案集群通过分片sharding来进行数据管理「分治思想」的一种实践并提供复制和故障转移功能。将数据划分为 16384 的 slots每个节点负责一部分槽位。槽位的信息存储于每个节点中。它是去中心化的如图所示该集群有三个 Redis 节点组成每个节点负责整个集群的一部分数据每个节点负责的数据多少可能不一样。Redis 集群架构三个节点相互连接组成一个对等的集群它们之间通过Gossip协议相互交互集群信息最后每个节点都保存着其他节点的 slots 分配情况。集群安装一个 Redis 集群通常由多个节点node组成在刚开始的时候每个节点都是相互独立的它们都处于一个只包含自己的集群当中要组建一个真正可工作的集群我们必须将各个独立的节点连接起来构成一个包含多个节点的集群。连接各个节点的工作可以通过 CLUSTER MEET 命令完成CLUSTER MEET ip port 。向一个节点 node 发送 CLUSTER MEET 命令可以让 node 节点与 ip 和 port 所指定的节点进行握手handshake当握手成功时node 节点就会将 ip 和 port 所指定的节点添加到 node 节点当前所在的集群中。CLUSTER MEETCluster 实现原理“65 哥数据切片后需要将数据分布在不同实例上数据和实例之间如何对应上呢”Redis 3.0 开始官方提供了 Redis Cluster 方案实现了切片集群该方案就实现了数据和实例的规则。Redis Cluster 方案采用哈希槽Hash Slot接下来我会直接称之为 Slot来处理数据和实例之间的映射关系。将数据分成多份存在不同实例上集群的整个数据库被分为 16384 个槽slot数据库中的每个键都属于这 16384 个槽的其中一个集群中的每个节点可以处理 0 个或最多 16384 个槽。Key 与哈希槽映射过程可以分为两大步骤根据键值对的 key使用 CRC16 算法计算出一个 16 bit 的值将 16 bit 的值对 16384 执行取模得到 0 16383 的数表示 key 对应的哈希槽。Cluster 还允许用户强制某个 key 挂在特定槽位上通过在 key 字符串里面嵌入 tag 标记这就可以强制 key 所挂在的槽位等于 tag 所在的槽位。哈希槽与 Redis 实例映射“65 哥哈希槽又是如何映射到 Redis 实例上呢”在 部署集群的样例中通过 cluster create 创建Redis 会自动将 16384 个 哈希槽平均分布在集群实例上比如 N 个节点每个节点上的哈希槽数 16384 / N 个。除此之外可以通过 CLUSTER MEET 命令将 7000、7001、7002 三个节点连在一个集群但是集群目前依然处于下线状态因为三个实例都没有处理任何哈希槽。可以使用 cluster addslots 命令指定每个实例上的哈希槽个数。“65 哥为啥要手动制定呢”能者多劳嘛加入集群中的 Redis 实例配置不一样如果承担一样的压力对于垃圾机器来说就太难了让牛逼的机器多支持一点。三个实例的集群通过下面的指令为每个实例分配哈希槽实例 1负责 0 5460 哈希槽实例 2 负责 5461~10922 哈希槽实例 3 负责 10923 16383 哈希槽。redis-cli -h 172.16.19.1 –p 6379 cluster addslots 0,5460
redis-cli -h 172.16.19.2 –p 6379 cluster addslots 5461,10922
redis-cli -h 172.16.19.3 –p 6379 cluster addslots 10923,16383键值对数据、哈希槽、Redis 实例之间的映射关系如下数据、Slot与实例的映射Redis 键值对的 key 「码哥字节」「牛逼」经过 CRC16 计算后再对哈希槽总个数 16384 取模模数结果分别映射到实例 1 与实例 3 上。切记当 16384 个槽都分配完全Redis 集群才能正常工作。复制与故障转移“65 哥Redis 集群如何实现高可用呢Master 与 Slave 还是读写分离么”Master 用于处理槽Slave 节点则通过《Redis 主从架构数据同步》方式同步主节点数据。当 Master 下线Slave 代替主节点继续处理请求。主从节点之间并没有读写分离 Slave 只用作 Master 宕机的高可用备份。Redis Cluster 可以为每个主节点设置若干个从节点单主节点故障时集群会自动将其中某个从节点提升为主节点。如果某个主节点没有从节点那么当它发生故障时集群将完全处于不可用状态。不过 Redis 也提供了一个参数cluster-require-full-coverage可以允许部分节点故障其它节点还可以继续提供对外访问。比如 7000 主节点宕机作为 slave 的 7003 成为 Master 节点继续提供服务。当下线的节点 7000 重新上线它将成为当前 70003 的从节点。故障检测“65 哥我知道哨兵通过监控、自动切换主库、通知客户端实现故障自动切换Cluster 又如何实现故障自动转移呢”一个节点认为某个节点失联了并不代表所有的节点都认为它失联了。只有当大多数负责处理 slot 节点都认定了某个节点下线了集群才认为该节点需要进行主从切换。Redis 集群节点采用 Gossip 协议来广播自己的状态以及自己对整个集群认知的改变。比如一个节点发现某个节点失联了 (PFail)它会将这条信息向整个集群广播其它节点也就可以收到这点失联信息。如果一个节点收到了某个节点失联的数量 (PFail Count) 已经达到了集群的大多数就可以标记该节点为确定下线状态 (Fail)然后向整个集群广播强迫其它节点也接收该节点已经下线的事实并立即对该失联节点进行主从切换。故障转移当一个 Slave 发现自己的主节点进入已下线状态后从节点将开始对下线的主节点进行故障转移。从下线的 Master 及节点的 Slave 节点列表选择一个节点成为新主节点。新主节点会撤销所有对已下线主节点的 slot 指派并将这些 slots 指派给自己。新的主节点向集群广播一条 PONG 消息这条 PONG 消息可以让集群中的其他节点立即知道这个节点已经由从节点变成了主节点并且这个主节点已经接管了原本由已下线节点负责处理的槽。新的主节点开始接收处理槽有关的命令请求故障转移完成。选主流程“65 哥新的主节点如何选举产生的”集群的配置纪元 1是一个自曾计数器初始值 0 每次执行故障转移都会 1。检测到主节点下线的从节点向集群广播一条CLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST消息要求所有收到这条消息、并且具有投票权的主节点向这个从节点投票。这个主节点尚未投票给其他从节点那么主节点将向要求投票的从节点返回一条CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK消息表示这个主节点支持从节点成为新的主节点。参与选举的从节点都会接收CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK消息如果收集到的票 (N/2) 1 支持那么这个从节点就被选举为新主节点。如果在一个配置纪元里面没有从节点能收集到足够多的支持票那么集群进入一个新的配置纪元并再次进行选举直到选出新的主节点为止。跟哨兵类似两者都是基于 Raft 算法来实现的流程如图所示集群Leader选举用表保存键值对和实例的关联关系可行么“65 哥我来考考你“Redis Cluster 方案通过哈希槽的方式把键值对分配到不同的实例上这个过程需要对键值对的 key 做 CRC 计算并对 哈希槽总数取模映射到实例上。如果用一个表直接把键值对和实例的对应关系记录下来例如键值对 1 在实例 2 上键值对 2 在实例 1 上这样就不用计算 key 和哈希槽的对应关系了只用查表就行了Redis 为什么不这么做呢””使用一个全局表记录的话假如键值对和实例之间的关系改变重新分片、实例增减需要修改表。如果是单线程操作所有操作都要串行性能太慢。多线程的话就涉及到加锁另外如果键值对数据量非常大保存键值对与实例关系的表数据所需要的存储空间也会很大。而哈希槽计算虽然也要记录哈希槽与实例时间的关系但是哈希槽的数量少得多只有 16384 个开销很小。客户端如何定位数据所在实例“65 哥客户端又怎么确定访问的数据到底分布在哪个实例上呢”Redis 实例会将自己的哈希槽信息通过 Gossip 协议发送给集群中其他的实例实现了哈希槽分配信息的扩散。这样集群中的每个实例都有所有哈希槽与实例之间的映射关系信息。在切片数据的时候是将 key 通过 CRC16 计算出一个值再对 16384 取模得到对应的 Slot这个计算任务可以在客户端上执行发送请求的时候执行。但是定位到槽以后还需要进一步定位到该 Slot 所在 Redis 实例。当客户端连接任何一个实例实例就将哈希槽与实例的映射关系响应给客户端客户端就会将哈希槽与实例映射信息缓存在本地。当客户端请求时会计算出键所对应的哈希槽在通过本地缓存的哈希槽实例映射信息定位到数据所在实例上再将请求发送给对应的实例。Redis 客户端定位数据所在节点重新分配哈希槽“65 哥哈希槽与实例之间的映射关系由于新增实例或者负载均衡重新分配导致改变了咋办”集群中的实例通过 Gossip 协议互相传递消息获取最新的哈希槽分配信息但是客户端无法感知。Redis Cluster 提供了重定向机制客户端将请求发送到实例上这个实例没有相应的数据该 Redis 实例会告诉客户端将请求发送到其他的实例上。“65 哥Redis 如何告知客户端重定向访问新实例呢”分为两种情况MOVED 错误、ASK 错误。MOVED 错误MOVED 错误负载均衡数据已经迁移到其他实例上当客户端将一个键值对操作请求发送给某个实例而这个键所在的槽并非由自己负责的时候该实例会返回一个 MOVED 错误指引转向正在负责该槽的节点。GET 公众号:码哥字节
(error) MOVED 16330 172.17.18.2:6379该响应表示客户端请求的键值对所在的哈希槽 16330 迁移到了 172.17.18.2 这个实例上端口是 6379。这样客户端就与 172.17.18.2:6379 建立连接并发送 GET 请求。同时客户端还会更新本地缓存将该 slot 与 Redis 实例对应关系更新正确。MOVED 指令ASK 错误“65 哥如果某个 slot 的数据比较多部分迁移到新实例还有一部分没有迁移咋办”如果请求的 key 在当前节点找到就直接执行命令否则时候就需要 ASK 错误响应了槽部分迁移未完成的情况下如果需要访问的 key 所在 Slot 正在从从 实例 1 迁移到 实例 2实例 1 会返回客户端一条 ASK 报错信息客户端请求的 key 所在的哈希槽正在迁移到实例 2 上你先给实例 2 发送一个 ASKING 命令接着发发送操作命令。GET 公众号:码哥字节
(error) ASK 16330 172.17.18.2:6379比如客户端请求定位到 key 「公众号:码哥字节」的槽 16330 在实例 172.17.18.1 上节点 1 如果找得到就直接执行命令否则响应 ASK 错误信息并指引客户端转向正在迁移的目标节点 172.17.18.2。ASK 错误注意ASK 错误指令并不会更新客户端缓存的哈希槽分配信息。所以客户端再次请求 Slot 16330 的数据还是会先给 172.17.18.1 实例发送请求只不过节点会响应 ASK 命令让客户端给新实例发送一次请求。MOVED指令则更新客户端本地缓存让后续指令都发往新实例。集群可以设置多大“65 哥有了 Redis Cluster再也不怕大数据量了我可以无限水平拓展么”答案是否定的Redis 官方给的 Redis Cluster 的规模上线是 1000 个实例。“65 哥到底是什么限制了集群规模呢”关键在于实例间的通信开销Cluster 集群中的每个实例都保存所有哈希槽与实例对应关系信息Slot 映射到节点的表以及自身的状态信息。在集群之间每个实例通过 Gossip协议传播节点的数据Gossip 协议工作原理大概如下从集群中随机选择一些实例按照一定的频率发送 PING 消息发送给挑选出来的实例用于检测实例状态以及交换彼此的信息。PING 消息中封装了发送者自身的状态信息、部分其他实例的状态信息、Slot 与实例映射表信息。实例接收到 PING 消息后响应 PONG 消息消息包含的信息跟 PING 消息一样。集群之间通过 Gossip协议可以在一段时间之后每个实例都能获取其他所有实例的状态信息。所以在有新节点加入节点故障Slot 映射变更都可以通过 PINGPONG 的消息传播完成集群状态在每个实例的传播同步。Gossip 消息发送的消息结构是 clusterMsgDataGossip结构体组成typedef struct {char nodename[CLUSTER_NAMELEN]; //40字节uint32_t ping_sent; //4字节uint32_t pong_received; //4字节char ip[NET_IP_STR_LEN]; //46字节uint16_t port; //2字节uint16_t cport; //2字节uint16_t flags; //2字节uint32_t notused1; //4字节
} clusterMsgDataGossip;所以每个实例发送一个 Gossip消息就需要发送 104 字节。如果集群是 1000 个实例那么每个实例发送一个 PING 消息则会占用 大约 10KB。除此之外实例间在传播 Slot 映射表的时候每个消息还包含了 一个长度为 16384 bit 的 Bitmap。每一位对应一个 Slot如果值 1 则表示这个 Slot 属于当前实例这个 Bitmap 占用 2KB所以一个 PING 消息大约 12KB。PONG与PING 消息一样一发一回两个消息加起来就是 24 KB。集群规模的增加心跳消息越来越多就会占据集群的网络通信带宽降低了集群吞吐量。实例的通信频率“65 哥码哥发送 PING 消息的频率也会影响集群带宽吧”Redis Cluster 的实例启动后默认会每秒从本地的实例列表中随机选出 5 个实例再从这 5 个实例中找出一个最久没有收到 PING 消息的实例把 PING 消息发送给该实例。“65 哥随机选择 5 个但是无法保证选中的是整个集群最久没有收到 PING 通信的实例有的实例可能一直没有收到消息导致他们维护的集群信息早就过期了咋办呢”这个问题问的好Redis Cluster 的实例每 100 ms 就会扫描本地实例列表当发现有实例最近一次收到 PONG 消息的时间 cluster-node-timeout / 2。那么就立刻给这个实例发送 PING 消息更新这个节点的集群状态信息。当集群规模变大就会进一步导致实例间网络通信延迟怎加。可能会引起更多的 PING 消息频繁发送。降低实例间的通信开销每个实例每秒发送一条 PING消息降低这个频率可能会导致集群每个实例的状态信息无法及时传播。每 100 ms 检测实例 PONG消息接收是否超过 cluster-node-timeout / 2这个是 Redis 实例默认的周期性检测任务频率我们不会轻易修改。所以只能修改 cluster-node-timeout的值集群中判断实例是否故障的心跳时间默认 15 S。所以为了避免过多的心跳消息占用集群宽带将 cluster-node-timeout调成 20 秒或者 30 秒这样 PONG 消息接收超时的情况就会缓解。但是也不能设置的太大。都则就会导致实例发生故障了却要等待 cluster-node-timeout时长才能检测出这个故障影响集群正常服务。总结哨兵集群实现故障自动转移但是当数据量过大导致生成 RDB 时间过长。而 Fork 执行的时候会阻塞主线程由于数据量过大导致阻塞主线程过长所以出现了 Redis 响应慢的表象。使用 Redis Cluster 集群主要解决了大数据量存储导致的各种慢问题同时也便于横向拓展。在面向百万、千万级别的用户规模时横向扩展的 Redis 切片集群会是一个非常好的选择。集群的整个数据库被分为 16384 个槽slot数据库中的每个键都属于这 16384 个槽的其中一个集群中的每个节点可以处理 0 个或最多 16384 个槽。Redis 集群节点采用 Gossip 协议来广播自己的状态以及自己对整个集群认知的改变。客户端连接到集群候任何一个实例后实例会将哈希槽与实例映射信息发送给客户端客户端将信息保存用于将 key 定位到对应的节点。集群并不能无限增加由于集群通过 Gossip协议传播集群实例信息所以通信频率是限制集群大小的主要原因主要可以通过修改 cluster-node-timeout调整频率。往期推荐进程切换的本质是什么一次限制进程的 CPU 用量的实操过程Redis 内存满了怎么办这样置才正确手工模拟实现 Docker 容器网络点分享点收藏点点赞点在看
