扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
本篇内容介绍了“redis集群收缩的概念和流程”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!
大厂网站建设公司创新互联建站,大厂网站设计制作,有大型网站制作公司丰富经验。已为大厂千余家提供企业网站建设服务。企业网站搭建\成都外贸网站建设要多少钱,请找那个售后服务好的大厂做网站的公司定做!
收缩集群也就是缩减集群节点的规模,也就是需要将部分节点下线。下线节点的流程如下:
1.首先需要确定下线节点是否有负责的槽,如果有则需要将槽迁移到其它节点中,保证节点下线后整个集群槽节点映射的完整性。
2.当下线节点不再负责槽或者本身是从节点时,就可以通过集群內其它节点忘记下线节点,这样当所有的节点都忘记了下线节点则该节点就可以正常关闭了。
下线节点需要把自己负责的槽迁移到其它节点,原理和上一篇介绍的集群扩容迁移槽一样。下面我们把6381和6383节点下线。
6381是主节点,并且如上图所示,我们知道该节点负责槽8192-12287。按照我们上面介绍的流程,我们在下线节点之前需要将该节点负责的槽迁移到其它节点中。并且收缩集群和集群扩容正好是相反的,我们需要将6381节点变为源节点,其它主节点变为目标节点。我们在迁移槽时,还是使用redis-trib reshard命令。因为reshard命令只能有一个目标节点,所以我们要迁移4096槽时,需要执行3次reshard命令。因为要保证迁移槽均匀的迁移到其它节点上,所以我们将上面4096个槽分别迁移1365、1365、1366个槽。
下面我们将6381的槽迁移到6379中:
当槽迁移完成后,我们可以查看6379节点已经负责了新迁移的槽了。
下面我们用同样的方式,我们将1365的槽迁移到6380中:
查看6380节点现在负责的槽。
我们还是用同样的方式,将1366的槽迁移到6382中:
继续查看6382节点负责的槽。
并且通过上图所示,我们已经知道了6381节点现在已经不负责任何槽了。下面我们继续流程的第二步骤,也就是将要下线的节点槽迁移完成后,还需要让集群忘记该下线的节点。
因为我们之前介绍过集群内的节点是不停的通过Gossip消息彼此交换节点状态,所以要让集群内其它节点忘记下线节点就是要让其它节点不再与要下线的节点进行Gossip消息交换。在Redis中我们使用cluster forget {downNodeId}命令。
当节点接受到cluster forget {downNodeId}命令后,会把nodeId指定的节点加入到禁用列表中,在禁用列表内的节点不再发送Gossip消息。禁用列表的有效期是60秒,超过60秒节点会继续参与消息交换。所以让要集群内其它节点忘记下线节点就是在这60秒之内操作。在实际的操作中如果使用cluster forget {downNodeId}命令下线节点时,因为会涉及到大量节点命令交互,并且还有60秒的限制,所以有可能会造成遗漏。所以在实际的操作中我们不会使用cluster forget {downNodeId}命令下线节点。我们会使用redis-trib.rb del-node {host:port} {downNodeId}命令。
备注:建议在使用redis-trib.rb del-node {host:port} {downNodeId}命令下线节点时,优先下线从节点,然后在下线主节点,以免不必要的复制发生。所以下面我们优先下线6383节点其次下线和6381节点。
当节点下线后,我们可以在次查看集群节点状态,我们此时发现刚刚的那个6381节点已经没有在集群中了。
这就是Redis收缩集群的全部内容,说白了也就是下线部分集群节点功能。这在我们实际的开发中很有必要,掌握集群扩容和收缩集群,可以为我们在实际的场景中做出从容应对。
“Redis集群收缩的概念和流程”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站,小编将为大家输出更多高质量的实用文章!
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流