内容简介:在上一篇文章中,已经将 16384 个槽都进行了指派之后,集群已经进入上线状态现在客户端就可以向集群中的节点发送命令了。当客户端向节点发送与数据库键有关的命令时,接收命令的节点会计算出命令要处理的数据库键属于哪个槽,并检查这个槽是否指派给了自己:
在上一篇文章中,已经将 16384 个槽都进行了指派之后,集群已经进入上线状态
127.0.0.1:7000> cluster info // 集群状态:OK表示上线 cluster_state:ok cluster_slots_assigned:16384 cluster_slots_ok:16384 cluster_slots_pfail:0 cluster_slots_fail:0 cluster_known_nodes:3 cluster_size:3 cluster_current_epoch:3 cluster_my_epoch:1 ··· 复制代码
现在客户端就可以向集群中的节点发送命令了。
当客户端向节点发送与数据库键有关的命令时,接收命令的节点会计算出命令要处理的数据库键属于哪个槽,并检查这个槽是否指派给了自己:
- 如果键所在的槽刚好指派给当前节点,那么节点就回直接执行这个命令。
- 如果不在当前节点,那么节点会向客户端返回一个 MOVED 错误,指引客户端转向(redirect)至正确的节点,并再次发送之前想要执行的命令。
计算键属于哪个槽
CLUSTER KEYSLOT <key>
127.0.0.1:7000> cluster keyslot "date" (integer) 2022 复制代码
说明"date"键会分配在 2022 这个槽。
当节点计算出键所属的槽 i 后,节点就回检查自己在 clusterState.slots 数组中的项 i,判断键是否由自己负责。
MOVED 错误
当节点发现键所在的槽并非自己负责处理的时候,节点就会向客户端返回一个 MOVED 错误,指引客户端转向至正在负责槽的节点。
节点数据库的实现
集群节点保存键值对以及键值对过期时间的方式与单机 Redis 服务器一样,它们两者只有一个区别,节点只能使用 0 号数据库,而单机 Redis 服务器没有这一限制。
重新分片
Redis 集群的重新分片操作可以将任意数量已经指派给某个节点(源节点)的槽改为指派给另一个节点(目标节点),并且相关槽所属的键值对也会从源节点被移动到目标节点。
在重新分片过程,集群不需要下线,并且源节点和目标节点都可以继续进行命令请求。
这时需要 Redis 的集群管理软件 redis-trib 负责执行,Redis提供了进行重新分片所需的所有命令,而 redis-trib 则通过向源节点和目标节点发送命令来进行重新分片操作。
ASK 错误
在进行重新分片过程中,源节点向目标节点迁移一个槽的过程中,可能会出现这种情况:属于被迁移槽的一部分键值对保存在源节点里面,而另一部分键值对则保存在目标节点里面。
当客户端向源节点发送一个与数据库键有关的命令,并且命令要处理的数据库键就在正在被迁移的槽时:
- 源节点会先在自己的数据库里面查找指定的键,如果找到就回执行命令
- 相反地,没有找到,这个键可能被迁移到目标节点,源节点将想客户端返回一个 ASK 错误,指引客户端转向正在导入槽的目标节点,并再次发送之前想要执行的命令。
ASK 错误和 MOVED 错误的区别:
-
MOVED 错误代表槽的负责权已经从一个节点转移到了另一个节点:在客户端收到关于槽 i 的 MOVED 错误之后,客户端每次遇到关于槽i的命令请求时,都可以直接将命令请求发送至 MOVED 错误所指向的节点,因为该节点就是目前负责槽i的节点。
-
ASK 错误只是两个节点在迁移槽的过程中使用的一种临时措施:在客户端收到槽 i 的 ASK 错误之后,客户端只会在接下来的一次命令请求中将关于槽 i 的命令请求发送至 ASK 错误所指示的节点,但这种转向不会对客户端今后发送关于槽i的命令请求产生任何影响,客户端仍然会将关于槽i的命令请求发送至目前负责处理槽 i 的节点,除非 ASK 错误再次出现
复制与故障转移
Redis 集群中的节点分为 主节点(Master)和从节点(slave) ,其中主节点负责处理槽,而从节点则用于负责某个主节点,并在被复制的主节点下线时, 代替下线主节点继续处理命令请求 。
个人感觉与单机版时的主从配置很相似,多了一步,就是主节点挂了之后,从节点继承负责处理槽的职责。
集群中设置从节点
CLUSTER REPLICATE <node_id> 复制代码
可以让接收命令的节点成为node_id所指定节点的从节点,并开始对主机进行复制。
故障检测
集群中每个节点都会定期地想几区中的其他节点发送 PING 消息,以此来检测对方是否在线,如果接收 PING 消息的节点没有在规定时间内回复 PONG 消息,那么发送 PING 消息的节点就会将接收 PING 消息的节点标记为 疑似下线(probable fail, PFAIL) 。
在一个集群中, 超过半数以上 负责处理槽的主节点都将这个主节点x报告为疑似下线,那么这个主节点 x 将被标记为以下线(FAIL),并向 集群广播一条关于主节点x的FAIL消息 。
故障转移
主节点下线后,从节点将开始对下线主节点进行故障转移,有以下几个步骤:
- 从从节点中选出新的主节点
- 被选中的从节点会执行 SLAVEOF no one 命令 ,成为新的主节点
- 新的主节点会撤销所有对已下线主节点的槽指派,并将这些槽全部指派给自己
- 新的主节点像集群广播PONG消息,让其它节点了解这个节点已经成为新的主节点,接管原本已下线节点负责处理的槽
- 新的主节点开始接受和自己负责处理的槽有关的命令请求,故障转移完成。
小结
Redis 集群的坑只填了一点,还有关于 Redis 消息的没填,这个先留着吧,先去写论文。之后开始撸 NIO 还是SPRING呢,日常纠结:confounded:
以上所述就是小编给大家介绍的《Redis集群(二)发送命令和故障转移》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 详细分析Redis集群故障
- 一次Hbase集群故障记录
- Elasticsearch 集群故障排查及修复指南
- 记一次 Kafka 集群的故障恢复
- Redis源码解析:集群手动故障转移、从节点迁移详解
- rabbitmq 原理、集群、基本运维操作、常见故障处理
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
The Filter Bubble
Eli Pariser / Penguin Press / 2011-5-12 / GBP 16.45
In December 2009, Google began customizing its search results for each user. Instead of giving you the most broadly popular result, Google now tries to predict what you are most likely to click on. Ac......一起来看看 《The Filter Bubble》 这本书的介绍吧!