Marathon: Vereinfachen Sie den Wahlkodex für die Führung

Erstellt am 22. Dez. 2016  ·  7Kommentare  ·  Quelle: mesosphere/marathon

Jetzt, da wir für die Leader-Wahl auf LeaderLatch des Kurators migriert sind, scheint es, dass unser Leader-Wahlcode VIEL mehr tut als nötig. Einige Dinge, die ich gerne behoben sehen würde:

  • alle Sperren entfernen. Beispielsweise blockiert LeaderLatch und dies führte zu einem Deadlock. Bei der Menge an Thread-Blockierungen, die wir durchführen, sollte dies keine Überraschung sein.
  • AnythingBase ist fast immer ein Anti-Pattern. Werde ElectionServiceBase los. Wenn wir eine gemeinsame Schnittstelle brauchen, definieren Sie sie. Ziehen Sie es vor, allgemeines Verhalten in Hilfsmethoden zu stecken, anstatt sie zu erben, usw.
  • Führen Sie blockierende E/A in einem Thread-Pool aus, der für das Blockieren von E/A ausgelegt ist. Blockieren Sie nicht den globalen Fork-Join-Pool.
  • Reißen Sie die State-Machine-artige Logik heraus. Wenn Sie Führung angeboten bekommen, großartig, Sie sind der Anführer. Wenn Sie verlieren, dann halten Sie sich bereit. Wenn Sie von Führung zu Nichtführung übergehen, CRASH. Die Leiterverriegelung des Kurators versucht ständig, die Führung zu erlangen, falls der Leiter verschwindet. Es muss nicht regelmäßig "neu gestartet" werden.

Das fallende Scala-Skript veranschaulicht, wie prägnant unser Leader-Wahlmodul sein sollte:

https://gist.github.com/timcharper/22a1bca65e9a8268225dcfb97420cdf7

picture timcharper
👍3

Hilfreichster Kommentar

Scalas eigene Empfehlung lautet, einen Threadpool mit fester Größe zum Blockieren von IO zu haben.

picture jasongilanfarr am 23. Dez. 2016
👍2

Alle 7 Kommentare

Ich stimme den meisten Ihrer Punkte zu. Einige Ergänzungen:

  • ElectionServiceBase : Die gemeinsame Schnittstelle ist bereits definiert: ElectionService .
  • Führen Sie blockierende E/A in einem Thread-Pool aus, der für das Blockieren ausgelegt ist. Dies ist ein größeres Thema für alle Orte, an denen wir IO betreiben. Schlagen Sie vor, für jeden Fall mehrere verschiedene Thread-Pools zu verwenden?
aquamatthias picture aquamatthias am 23. Dez. 2016
👍2

Scalas eigene Empfehlung lautet, einen Threadpool mit fester Größe zum Blockieren von IO zu haben.

jasongilanfarr picture jasongilanfarr am 23. Dez. 2016
👍2

Der Wahlcode verwendet eine andere Clientinstanz. Sollte es das gleiche wie der Speicher verwenden?

jeschkies picture jeschkies am 2. Jan. 2017

Ich möchte auch, dass stopLeadership und startLeadership sperrenfrei / nicht blockierend sind. Siehe meinen Kommentar in D379 .

jeschkies picture jeschkies am 4. Jan. 2017

@jeschkies warum hast du überhaupt stopLeadership ? Warum nicht einfach abstürzen?

timcharper picture timcharper am 4. Jan. 2017

@jeschkies sollte wahrscheinlich dieselbe Clientinstanz verwenden, aber ich bin mir nicht sicher, ob Curator hinter den Kulissen eine Aggregation des Zookeeper-Verbindungspools durchführt.

Bei genauerem Nachdenken sollten wir mehr recherchieren. Was passiert, wenn auf dem Speicher eine hohe Menge an Lese-/Schreibverkehr vorhanden ist und es zu einem Rückstand kommt? Könnten wir die Führung verlieren? Ich bin mir nicht sicher, was die Folgen sind.

timcharper picture timcharper am 4. Jan. 2017

Hinweis: Dieses Problem wurde zu https://jira.mesosphere.com/browse/MARATHON-2008 migriert. Weitere Informationen finden Sie unter https://groups.google.com/forum/#!topic/marathon-framework/khtvf-ifnp8 .

meichstedt picture meichstedt am 7. März 2017
War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

martonsereg picture martonsereg  ·  3Kommentare
ssk2 picture ssk2  ·  12Kommentare
a-nldisr picture a-nldisr  ·  16Kommentare
timcharper picture timcharper  ·  4Kommentare
liquid-sky picture liquid-sky  ·  6Kommentare