美文网首页Java
redis 集群 高可用 测试

redis 集群 高可用 测试

作者: 阿fong | 来源:发表于2020-03-25 19:53 被阅读0次

    编写不易,转载请注明出处!!!

    测试redis主从节点宕机后的变化,以及数据迁移情况

    1 配置集群

    网上很多教程,我就略过了。

    2 编辑启动和关闭批处理文件

    2.1 start.sh——启动集群的批处理文件

    我们这里是配置了7001-7009端口的9台redis服务器

    vim start.sh

    2.2 createCluster.sh——组建集群的批处理文件

    vim createCluster.sh

    2.3 shutdown.sh——关闭集群的批处理文件

    vim shutdown.sh

    3 启动集群

    sh start.sh

    后面还有,没有显示完全,我就不截完了

    sh createCluster.sh

    组建集群,我们可以看到他分为三个master节点,平均管理0-16384的三个范围。并将三个master节点分别指定给7001,7002,7003端口的redis节点,

    yes

    然后输出了每个节点的信息,以及从节点跟随情况,并询问我是否使用默认分配。我这里选择yes,使用。

    然后又输出了节点信息,以及检查情况,最后16384个hash槽点全部分配完,集群组建成功

    至此,我们画图表述一下主从节点的跟随情况

    redis集群初始分布情况

    4 测试

    4.1 插入数据

    4.1.1 插入数据到7001

    成功插入数据到7001 成功同步到从节点7005

    4.1.2 插入数据到7002

    成功插入数据到7002 成功同步到从节点7009

    4.1.2 数据分布情况

    分布情况

    4.2 宕机测试

    4.2.1 宕掉7001

    shutdown CLUSTER NODES

    我们可以看到,7001是宕机了,状态变为fail。由从机其7005继位,而7007改为跟随7005。下面测试数据的高可用情况

    get test1

    还是能正常访问数据。

    set test1 2

    同样能正常修改数据并同步

    由此可见,集群通过master节点向slave节点同步数据,masster节点宕机后故障转移至slave节点来达到高可用的

    4.2.2 继续宕掉7005

    shutdown CLUSTER NODES

    我们可以看到7005也变为fail状态,又另一个slave节点7007,继位,此时0-5460阵营以没有slave节点,情况危急,7002慷慨大义,借了多余的slave节点7009给7007,而7002就只有7004节点跟随它了。如此,又能保证每个master节点都有slave节点跟随。

    我们继续测试一下数据的情况

    get test1     get test2

    我们可以看到,7007继位后,0-5460阵营的test1仍然正常,也成功同步到7009节点。但是7009节点原来保存的7002的数据却悄然丢失。

    由此,redis集群会通过转移多余的slave节点的方式,来尽量保证每个master节点都有slave节点跟随,同时,转移的slave节点会删除原来阵营的数据,而同步转移后阵营的数据。

    4.2.3 继续宕掉7007

    shutdown CLUSTER NODES

    我们可以看到,7007变为fail状态,slave节点7009继位,slave节点7006从7003转移至7009

    get test1

    数据成功同步

    4.2.4 继续宕掉7009

    shutdown CLUSTER NODES

    我们可以看到,7009宕掉以后,7006继位,但是别的阵营以及借无可借了,所以7006只能委屈当光杆司令,情况十分危急。

    数据情况是一样的,我就不做测试了。

    我们继续乘胜追击

    4.2.5 继续宕掉7006

    shutdown CLUSTER NODES

    我们可以看到0-5460阵营全军覆没,0-5460的hash槽点丢失,数据丢失,也无法在存入数据,若有数据经过哈希槽运算落在此范围,则无法存入,每次都需要去数据库取数据,集群的高可用宣告破裂,

    我们看看其余两个阵营能否正常使用

    4.2.6 测试存活阵营

    get test2 set test3 1

    我们可以看到,集群奔溃,其余存活的阵营也无法使用, 我们已至少5台的战绩摧毁了redis集群。

    太亏欠0-5460阵营了,我们送它个复活币

    4.2.7 启动7001

    redis-server 7001/redis.conf

    它非常踏实稳重,愿意从slave节点做起

    一段时间过后再看,我们发现7001再也回不到从前了

    我们尝试启动7006

    我们可以发现,7006成功启动成为master节点,而7001一开始跟随的节点就是7006。

    看看数据

    成功恢复,这是因为7006的文件里存有dump.rdb快照文件

    看看其他阵营

    我们可以看到,能正常使用。

    5 总结

    1.redis集群通过master节点向slave节点同步数据,masster节点宕机后故障转移至slave节点来达到高可用

    2.redis集群会通过转移多余的slave节点的方式,来尽量保证每个master节点都有slave节点跟随

    3.redis集群奔溃的条件是,当有hash槽范围丢失的时候,集群奔溃

    4.让集群奔溃,至少需要当掉的节点数量x为

                阵营数 m     每个阵营的节点数  n 

                x = n + (n-2)*(m-1)

    5.集群奔溃,其余存活的阵营也无法使用

    6.要成功再次启动redis集群,必须启动掌握了丢失的hash槽 的节点

    本人水平有限,欢迎大牛指正。

    看在我写了这么多的份上,如果觉得内容好可以请点个赞和关注哦。

    编写不易,转载请注明出处!!!谢谢!

    相关文章

      网友评论

        本文标题:redis 集群 高可用 测试

        本文链接:https://www.haomeiwen.com/subject/lpytuhtx.html