Artwork

Konten disediakan oleh Stefan Majewsky and Xyrillian Noises. Semua konten podcast termasuk episode, grafik, dan deskripsi podcast diunggah dan disediakan langsung oleh Stefan Majewsky and Xyrillian Noises atau mitra platform podcast mereka. Jika Anda yakin seseorang menggunakan karya berhak cipta Anda tanpa izin, Anda dapat mengikuti proses yang diuraikan di sini https://id.player.fm/legal.
Player FM - Aplikasi Podcast
Offline dengan aplikasi Player FM !

STP027: Verteilte Systeme

58:13
 
Bagikan
 

Fetch error

Hmmm there seems to be a problem fetching this series right now. Last successful fetch was on January 02, 2025 14:02 (5d ago)

What now? This series will be checked again in the next day. If you believe it should be working, please verify the publisher's feed link below is valid and includes actual episode links. You can contact support to request the feed be immediately fetched.

Manage episode 345364134 series 2920733
Konten disediakan oleh Stefan Majewsky and Xyrillian Noises. Semua konten podcast termasuk episode, grafik, dan deskripsi podcast diunggah dan disediakan langsung oleh Stefan Majewsky and Xyrillian Noises atau mitra platform podcast mereka. Jika Anda yakin seseorang menggunakan karya berhak cipta Anda tanpa izin, Anda dapat mengikuti proses yang diuraikan di sini https://id.player.fm/legal.

In dieser Episode bringt Xyrill uns versprengte Systeme näher. Dabei erfahren wir auch, dass Dinge, die wir als Grundvoraussetzung ansehen würden, bei genauerer Betrachtung gar nicht so selbstverständlich sind.

Shownotes

Laut Wikipedia eine überraschend breite Definition:

Ein verteiltes System ist [...] ein Zusammenschluss unabhängiger Computer, die sich für den Benutzer als ein einziges System präsentieren.

  • Motivationen für verteilte Systeme

    • Kommunikation zwischen Computern mit verschiedenen Eigentümern (z.B. Chatnetzwerk, Banküberweisung)
    • Teilen von Ressourcen (z.B. Druckerfreigabe)
    • Hochverfügbarkeit
    • Lastverteilung
  • Grundlage des Problems: CAP-Theorem

    • Es gibt drei extrem wünschenswerte Eigenschaften. Wähle zwei.
    • Konsistenz (Consistency): Lesevorgänge liefern immer die Daten, die zuletzt geschrieben wurden.
    • Verfügbarkeit (Availability): Alle Anfragen an das System werden stets beantwortet.
    • Partitionstoleranz: Das System kann bei Störungen des Netzwerkes oder einzelner Computer weiterarbeiten.
  • Beispiele bekannter Systeme gemäß CAP-Klassifikation

    • CP: Banküberweisung, Geldautomat
    • CA: Datenbanksysteme (siehe Folge 12)
    • AP: DNS (siehe Folge 18)
  • Komplexbeispiel: Verteilte Datenbank mit Raft-Konsensalgorithmus

    • Computernetzwerk aus N gleichartigen Teilnehmern (N meist ungerade, um Pattsituationen zu vermeiden)
    • pro Wahlperiode ein Anführer, alle anderen folgen dem Anführer
    • Schreibvorgänge gehen an den Anführer, werden von ihm an die Folger verteilt, und erst quittiert, wenn eine Mehrzahl der Folger Vollzug meldet
    • Anführer sagt regelmäßig (Größenordnung 150-300 ms) allen Folgern Bescheid, dass er noch anführt
    • bei Ausbleiben der Meldung vom Anführer startet jeder Folger eine neue Wahlperiode und stimmt für sich selbst als neuen Anführer
    • pro Wahlperiode:
      • wer jemand anderen abstimmen sieht, bevor er selbst abstimmt, folgt sofort der gesehenen Stimme
      • wer die Mehrheit der Stimmen auf sich vereinigt, ist der neue Anführer
    • bei Pattsituationen beginnt nach einer Wartefrist die nächste Wahlperiode (Wartefrist ist pro Teilnehmer randomisiert, um Kettenpatt zu vermeiden)
    • CAP-Bewertung: CA (nicht partitionstolerant, weil eine Mehrheit der Teilnehmer erforderlich ist)
  • hier nicht betrachtet: Byzantinische Fehler

  • zum Nachlesen: Irrtümer der verteilten Datenverarbeitung

  • Sidebar: Volunteer Computing (BOINC, SETI@Home, Folding@Home, etc.)

  • Nachtrag: geführte Visualisierung des Raft-Algorithmus (englisch): https://thesecretlivesofdata.com/raft/

  continue reading

67 episode

Artwork
iconBagikan
 

Fetch error

Hmmm there seems to be a problem fetching this series right now. Last successful fetch was on January 02, 2025 14:02 (5d ago)

What now? This series will be checked again in the next day. If you believe it should be working, please verify the publisher's feed link below is valid and includes actual episode links. You can contact support to request the feed be immediately fetched.

Manage episode 345364134 series 2920733
Konten disediakan oleh Stefan Majewsky and Xyrillian Noises. Semua konten podcast termasuk episode, grafik, dan deskripsi podcast diunggah dan disediakan langsung oleh Stefan Majewsky and Xyrillian Noises atau mitra platform podcast mereka. Jika Anda yakin seseorang menggunakan karya berhak cipta Anda tanpa izin, Anda dapat mengikuti proses yang diuraikan di sini https://id.player.fm/legal.

In dieser Episode bringt Xyrill uns versprengte Systeme näher. Dabei erfahren wir auch, dass Dinge, die wir als Grundvoraussetzung ansehen würden, bei genauerer Betrachtung gar nicht so selbstverständlich sind.

Shownotes

Laut Wikipedia eine überraschend breite Definition:

Ein verteiltes System ist [...] ein Zusammenschluss unabhängiger Computer, die sich für den Benutzer als ein einziges System präsentieren.

  • Motivationen für verteilte Systeme

    • Kommunikation zwischen Computern mit verschiedenen Eigentümern (z.B. Chatnetzwerk, Banküberweisung)
    • Teilen von Ressourcen (z.B. Druckerfreigabe)
    • Hochverfügbarkeit
    • Lastverteilung
  • Grundlage des Problems: CAP-Theorem

    • Es gibt drei extrem wünschenswerte Eigenschaften. Wähle zwei.
    • Konsistenz (Consistency): Lesevorgänge liefern immer die Daten, die zuletzt geschrieben wurden.
    • Verfügbarkeit (Availability): Alle Anfragen an das System werden stets beantwortet.
    • Partitionstoleranz: Das System kann bei Störungen des Netzwerkes oder einzelner Computer weiterarbeiten.
  • Beispiele bekannter Systeme gemäß CAP-Klassifikation

    • CP: Banküberweisung, Geldautomat
    • CA: Datenbanksysteme (siehe Folge 12)
    • AP: DNS (siehe Folge 18)
  • Komplexbeispiel: Verteilte Datenbank mit Raft-Konsensalgorithmus

    • Computernetzwerk aus N gleichartigen Teilnehmern (N meist ungerade, um Pattsituationen zu vermeiden)
    • pro Wahlperiode ein Anführer, alle anderen folgen dem Anführer
    • Schreibvorgänge gehen an den Anführer, werden von ihm an die Folger verteilt, und erst quittiert, wenn eine Mehrzahl der Folger Vollzug meldet
    • Anführer sagt regelmäßig (Größenordnung 150-300 ms) allen Folgern Bescheid, dass er noch anführt
    • bei Ausbleiben der Meldung vom Anführer startet jeder Folger eine neue Wahlperiode und stimmt für sich selbst als neuen Anführer
    • pro Wahlperiode:
      • wer jemand anderen abstimmen sieht, bevor er selbst abstimmt, folgt sofort der gesehenen Stimme
      • wer die Mehrheit der Stimmen auf sich vereinigt, ist der neue Anführer
    • bei Pattsituationen beginnt nach einer Wartefrist die nächste Wahlperiode (Wartefrist ist pro Teilnehmer randomisiert, um Kettenpatt zu vermeiden)
    • CAP-Bewertung: CA (nicht partitionstolerant, weil eine Mehrheit der Teilnehmer erforderlich ist)
  • hier nicht betrachtet: Byzantinische Fehler

  • zum Nachlesen: Irrtümer der verteilten Datenverarbeitung

  • Sidebar: Volunteer Computing (BOINC, SETI@Home, Folding@Home, etc.)

  • Nachtrag: geführte Visualisierung des Raft-Algorithmus (englisch): https://thesecretlivesofdata.com/raft/

  continue reading

67 episode

Semua episode

×
 
Loading …

Selamat datang di Player FM!

Player FM memindai web untuk mencari podcast berkualitas tinggi untuk Anda nikmati saat ini. Ini adalah aplikasi podcast terbaik dan bekerja untuk Android, iPhone, dan web. Daftar untuk menyinkronkan langganan di seluruh perangkat.

 

Panduan Referensi Cepat

Dengarkan acara ini sambil menjelajah
Putar