2015-06-01 7 views
11

Я прочитал в Akka's documentation, что при использовании одноэлементного кластера следует избегать автоматического спуска. Я не понимаю, как настроить настройку в этом случае. Я понимаю, что могу подписаться на события членства в кластере и планировать свою стратегию в соответствии с этими сообщениями. Однако я не понимаю, как практически это будет отличаться от автоматического спуска.Как настроить сглаживание в кластере akka при наличии синглета

Когда узел каким-то образом разбит на разделы из кластера, если используется автоматическое списание, секционированный узел «подумает» о том, что весь кластер пропал без вести и запустит собственный кластер (с его собственным одиночным движком). Но, с другой стороны, я не могу навсегда сохранить недоступные узлы в недостижимом состоянии, потому что кластер не достигнет конвергенции (новые узлы не смогут присоединиться), а если секционированный узел является единственным синглоном, то новый синглтон узел не будет назначен, и поэтому, согласно моему пониманию, единственное, что остается сделать, это удалить недоступные узлы после некоторого времени извлечения, что и делает автоматическое сглаживание.

Что я могу здесь пропустить?

+0

у меня такой же вопрос, как вы. Мне кажется, что у нас нет никакого способа, чтобы предотвратить раздел 2 кластера начать свой собственный кластер Singleton – mingchuno

ответ

1

ознакомьтесь с нижеследующим кодом. Я отключил функцию auto-down-unreachable-after, как сказал док. Вместо этого я реализую пользовательскую логику, которая немного отличается от обычной. Ключ к приведенному ниже коду заключается в том, что произойдет сетевой раздел, но только узлы кластера, которые имеют большинство, снимут UnreachableMember после некоторых конфигурируемых 5s. С другой стороны, меньшинство узлов кластера будет проталкивать их UnreachableMember (который является основной группой как unreachable и не снимает их с образованием острова. Идея числа большинства занимает заимствование у MongoDB, которое, по моему мнению, является не новые в компьютерной науке области.

class ClusterListener extends Actor with ActorLogging { 

    val cluster = Cluster(context.system) 
    var unreachableMember: Set[Member] = Set() 

    // subscribe to cluster changes, re-subscribe when restart 
    override def preStart(): Unit = { 
    //#subscribe 
    cluster.subscribe(self, initialStateMode = InitialStateAsEvents, classOf[UnreachableMember], classOf[ReachableMember]) 
    //#subscribe 
    } 
    override def postStop(): Unit = cluster.unsubscribe(self) 

    def receive = { 
    case UnreachableMember(member) => 
     log.info("Member detected as unreachable: {}", member) 
     val state = cluster.state 
     if (isMajority(state.members.size, state.unreachable.size)) { 
     scheduletakeDown(member) 
     } 
    case ReachableMember(member) => 
     unreachableMember = unreachableMember - member 
    case _: MemberEvent => // ignore 
    case "die" => 
     unreachableMember.foreach { member => 
     cluster.down(member.address) 
     } 
    } 

    // find out majority number of the group 
    private def majority(n: Int): Int = (n+1)/2 + (n+1)%2 

    private def isMajority(total: Int, dead: Int): Boolean = { 
    require(total > 0) 
    require(dead >= 0) 
    (total - dead) >= majority(total) 
    } 

    private def scheduletakeDown(member: Member) = { 
    implicit val dispatcher = context.system.dispatcher 
    unreachableMember = unreachableMember + member 
    // make 5s config able!!! 
    context.system.scheduler.scheduleOnce(5 seconds, self, "die") 
    } 

} 
+0

Спасибо за ваш комментарий, но я не понимаю, что-то Когда разделенные (меньшие) узлы возвращаются к большинству, скажем, что проблемы с сетью/gc были разрешены, если только узлы меньшинства не перезапускают свою актерскую систему (чтобы восстановить новый токен), смогут ли они снова подключиться к большинству голосов ? потому что, насколько я знаю, если узел был удален из кластера, он не может вернуться с тем же токеном. – Mizh

+0

Привет, я знаю, что это уже давно. Но для тех, кто ищет ответ. Секционированные узлы, отмеченные как «вниз» большинством, явно должны быть перезапущены, чтобы снова присоединиться к кластеру. http://doc.akka.io/docs/akka/2.4.2/scala/cluster-usage.html#Joining_to_Seed_Nodes – Cal

+1

Я протестировал это на Akka 2.4.3 и подтвердил, что он работает. У меня две машины, я запускаю большинство своих узлов на машине A и меньшинство на машине B. Я разорвать связь между A и B, чтобы имитировать раздел. Узлы машины Узлы выдают удары по меньшинству (узлы Machine B), а узлы меньшинства могут понять, что они на самом деле являются меньшинством. Обратите внимание, что узлы меньшинства не останавливаются и продолжают работать. Для их закрытия требуется дополнительная логика. Поиск «akka cluster split brain и reconnect» для получения дополнительной информации. Спасибо за обмен @mingchuno – Cal

 Смежные вопросы

  • Нет связанных вопросов^_^