Weshalb chronologische Anmeldeverfahren mit Stud.IP gar nicht funktionieren können

Die Behauptung, man könne die Last-Probleme bei gleichzeitig startenden Anmeldeverfahren nicht technisch lösen, sorgt regelmäßig für Verwunderung. Wenn ein Server (oder zwei oder drei oder vier) es nicht schaffen, den Ansturm der Anmeldewilligen auszuhalten, weshalb nimmt man dann nicht einfach zwei (oder vier oder acht oder sechzehn)?

Problem 1: Flaschenhals Datenbank. Bei den Anmeldeverfahren geht es ja darum, eine begrenzte Menge Plätze der Reihe nach auf anmeldewillige Personen zu verteilen. Auch wenn es ein Dutzend Server gibt, die diese Anfragen abarbeiten, muss es genau eine Stelle geben, an der die derzeit gültige Anmeldeliste verwaltet wird. Diese Stelle ist eine so genannte Datenbanktabelle, die auch genau einem Datenbankserver liegt und nicht verfielfacht werden kann. Alle Anmeldungen müssen also auf diese eine Tabelle zugreifen.

Problem 2: Ungeeignete Datenbank. In den 60er und 70er Jahren hat die Informatik-Forschung sich intensiv mit der Frage beschäftigt, wie große Datenmengen effizient gespeichert werden können. Als besonders erfolgreich haben sich die Relationen Datenbankmodelle herausgestellt, bei denen Daten in zweidimensionalen Tabellen gespeichert werden, die Querverweise enthalten und miteinander verknüpft werden können. Problem dabei: Aktionen müssen dabei häufig auf mehrere Datenbankoperationen verteilt werden, die nicht getrennt werden dürfen. Zum Beispiel: Wenn 100 Euro von Konto A auf Konto B überwiesen werden sollen, müssen von Konto A 100 Euro abgezogen und bei Konto B 100 Euro hinzugerechnet werden. Wenn das Programm nach der ersten Operation abbricht, befindet sich die Datenbank in einem fehlerhaften Zustand.

Um das zu verhinden, werden so genannte Transaktionen verwendet, die mehrere Operationen untrennbar zusammenfassen. In der Stud.IP-Datenbank gibt es keine Transaktionen. Das sorgt dafür, dass die Datenbank einfacher ist, bei Leseoperationen schneller ist und etwas einfacher zu programmieren ist. Das heißt aber auch, dass solche Dinge wie Banküberweisungen mit dem verwendeten Datenbanksystem besser nicht abgebildet werden sollten. Oder solche Dinge wie Kursanmeldungen nach dem Windhundverfahren.

Dabei tritt nämlich das paradoxe Problem auf, dass es um so mehr Überbuchungen gibt, je mehr Server für die Anmeldung bereitgestellt werden. Eine Kursanmeldung läuft nämlich so ab:

  1. Nutzer ruft Kursseite auf, eine Datenbankabfrage (1) liefert die Information, wie viele Plätze noch frei sind.
  2. Nutzer klickt auf Anmelden, Server nimmt Anfrage entgegen und eine Datenbankabfrage (2) ermittelt erneut, ob es noch freie Plätze gibt (seit Datenbankabfrage (1) können mehrere Sekunden oder gar Minuten vergangen sein).
  3. Wenn ja, wird in einer separaten Datenbankoperation (3) der Nutzer eingetragen.

Die Datenbankabfragen (2) und (3) passieren im Stud.IP-Code ziemlich direkt hinereinander. Trotzdem kann zwischendurch allerlei passieren. Der Datenbankserver muss nämlich alle Eintrage-Operationen in eine Warteschlange stellen, weil für alle Veranstaltungen insgesamt immer nur eine Eintrage-Operation gleichzeitig passieren kann („table lock“). Die Abfrage, ob noch Plätze frei sind, kann diese Warteschlange aber nicht mitberücksichtigen.

Daher kommt es bei überlaufenen gleichzeitigen Anmeldeverfahren fast zwangsläufig zu Überbuchungen der Veranstaltungen. Genau das möchte man aber in der Regel nicht. Das Problem lässt sich – in Stud.IP und seiner dafür ungeeigneten Datenbank – nur durch Verwendung geeigneter Verfahren lösen: Einem Losverfahren, bei dem zunächst alle Anmeldewünsche gesammelt werden. Nach Ablauf dieser Sammelphase, sei sie 2 Stunden oder Tage oder Wochen lang, wird automatisch gelost, wer einen Platz bekommt und wer auf welchem Platz der Warteliste landet.

Ein Gedanke zu „Weshalb chronologische Anmeldeverfahren mit Stud.IP gar nicht funktionieren können“

  1. Warum dann nicht für solche Spezialfälle eigene Entwicklungen (Plug-Ins, oder …) die angekoppelt werden? Vorstellbar sind In-Memory-Datenbanken und ein Ansatz wie „Hallo Nutzer, du hast zwar gerade eine Anfrage gemacht und es heißt es sind noch 15 Plätze frei, wenn du jetzt auf ‚anmelden‘ klickst kann aber in der Zwischenzeit schon alles ausgebucht sein.“

    Oder ein System welches auf die Datenbankschicht verzichtet und nur mitloggt, wer wann versucht sich einzutragen (möglicherweise sogar verteilt um die Last zu mindern). Erst nach einem gewissen Intervall werden die Daten synchronisiert und die ersten (zeitlich) 100 Studenten bekommen den Platz. Beim Losverfahren erfahre ich ja auch nicht sofort ob ich einen Platz bekommen habe, dann kann man auch eine Stunde warten bis alles synchronisiert ist und die Erstplatzierten ermittelt sind.

    Hab ich aber weder getestet noch implementiert 😉 Vielleicht wurden solche Ideen aber auch schon verworfen?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.