Redis集群(二)发送命令和故障转移

发送命令

在上一篇文章中,已经将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则通过向源节点和目标节点发送命令来进行重新分片操作。

[图片上传失败...(image-e2a2ef-1534470023589)]

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呢,日常纠结😖

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,684评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,143评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,214评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,788评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,796评论 5 368
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,665评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,027评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,679评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 41,346评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,664评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,766评论 1 331
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,412评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,015评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,974评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,203评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,073评论 2 350
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,501评论 2 343

推荐阅读更多精彩内容