zoukankan      html  css  js  c++  java
  • 关于redis主从架构重新选举master带来的问题

    redis嘛,主要问题就是关乎数据的问题;分布式嘛,主要问题就是C(一致性)A(可用性)P(分区容错性)。

    在这里考虑两个问题:数据不一致,数据丢失。

    数据不一致:

      有时候master会挂那么十几秒钟或者几秒钟然后又恢复正常,然后redis的调用者就觉得redis的master是没问题的,他就接着使用这玩意,但是哨兵在这段时间内已经把这个master淘汰出去,不但如此还选了一个新的master供redis集群内部共享数据。这样子就带来了一个问题,新的master会很自以为是的同步它的数据给他的slave,但是redis的调用者并不向这个新的master发送任何数据,也就是他的数据压根就不更新,导致他的slave数据也无法更新,最后实际对外提供服务的是那个被哨兵淘汰的master。

      这就是传说中的redis脑裂倘若集群部署的相对完善的话,新选举的master还应向被哨兵淘汰的master同步数据,并且将被哨兵淘汰的master置为新master的一个slave,那就更有意思了,master在被淘汰之前还在工作,也就是还在接收数据并且试图将数据写入自己的缓存中,直到新的master开始向它同步数据,为了同步数据,旧的master会将自己的数据同步成新的master一样,带来的问题就是旧的master数据丢失。当主从节点间数据同步时间间隔设置的比较久的话就会使问题变得很严重。但是显而易见的,像这样的数据丢失问题是没有办法避免,只能减小数据同步时间间隔,以求减小数据丢失的数据量。

    脑裂:

    解决方法:

    min-slaves-to-write 1
    min-slaves-max-lag 10

    说明:

    要求至少有1个slave,数据复制和同步的延迟不能超过10秒

    如果说一旦所有的slave,数据复制和同步的延迟都超过了10秒钟,那么这个时候,master就不会再接收任何请求了

    上面两个配置可以减少异步复制和脑裂导致的数据丢失

      减少异步复制的数据丢失

    有了min-slaves-max-lag这个配置,就可以确保说,一旦slave复制数据和ack延时太长,就认为可能master宕机后损失的数据太多了,那么就拒绝写请求,这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低的可控范围内

      减少脑裂的数据丢失

    如果一个master出现了脑裂,跟其他slave丢了连接,那么上面两个配置可以确保说,如果不能继续给指定数量的slave发送数据,而且slave超过10秒没有给自己ack消息,那么就直接拒绝客户端的写请求

    这样脑裂后的旧master就不会接受client的新数据,也就避免了数据丢失

    上面的配置就确保了,如果跟任何一个slave丢了连接,在10秒后发现没有slave给自己ack,那么就拒绝新的写请求

    因此在脑裂场景下,最多就丢失10秒的数据

  • 相关阅读:
    mac 下安装jenkins
    Appium元素定位难点:tap坐标定位不准确
    Appium元素定位难点:混合式的native+webview
    Linux 上安装 appium
    springMVC之AOP
    设计模式之装饰模式
    设计模式之桥接模式
    MyBatis特殊字符转义
    python+urllib+beautifulSoup实现一个简单的爬虫
    设计模式之代理模式
  • 原文地址:https://www.cnblogs.com/notably/p/11162253.html
Copyright © 2011-2022 走看看