Archiv: 2011 | 2012 | 2013 | 2014 | 2015 | 2016 | 2017 | 2018 | 2019 | 2020 | 2021 | 2022 | 2023 | 2024

Auf ausgewählte Projekte aus den unterschiedlichen Modulen wird im Folgenden genauer eingegangen.

Modul: Software-Design

Programmierprojekte stellen in der Regel die Umsetzung der in den Modulen Software-Design und Game-Design entwickelten Konzepte dar. Sie sollen neben dem Computercode eine Dokumentation und ggf. Anleitungen erstellen.

Projekt: Asynchroner Datenbankzugriff

Die meisten Software-Produkte für mehrere Benutzer lassen sich grob in drei Schichten aufteilen: Benutzungsoberfläche („Frontend“), Verarbeitungslogik („Backend“) und eine Datenbank. Diese grobe Unterteilung ist für praktisch alle Software-Architekturen möglich, auch wenn sich die möglichen Systemarchitekturen im Detail unterscheiden.

Die einfachste Möglichkeit ein solches System zu programmieren besteht darin, eine Benutzeraktion von Anfang bis Ende abzuarbeiten und erst am Ende eine Rückmeldung zu geben.

Wenn der primäre Zweck des Systems darin besteht, gespeicherte Daten zu bearbeiten (zum Beispiel die Erfassung und Bearbeitung von Anträgen), ist dieses Vorgehen sinnvoll und ausreichend.

Wenn dagegen die primäre Verarbeitung im Backend geschieht und die gespeicherten Daten eine untergeordnete Rolle spielen, dann sollte das Backend nicht blockieren während die Datenbank auf die Festplatte schreibt.

Zum Beispiel: Wenn ich in einem Online-Konferenzsystem von Lautsprechern zum Headset wechsele, soll diese Einstellung in der Datenbank gespeichert werden. Aber während die Datenbank damit beschäftigt ist, soll mir das Backend trotzdem weiter Bild und Ton der anderen Teilnehmer schicken.

Projekt: Priority Queue bei asynchronen Datenbankzugriff

Ausgehend von dem oben beschriebenen Projekt, realisierte dieses Projekt auch den nächsten Schritt: Eine Priorisierung des Datenbankzugriffs.

Die Reihenfolge, in der Datenbanktransaktionen ausgeführt werden, ist im Allgemeinen wichtig. Zum Beispiel: Eine Geldanlage läuft aus und wird auf das laufende Konto überwiesen. Danach legt der Benutzer das Geld neu an. Wenn diese beiden Transaktion in umgekehrter Reihenfolge ausgeführt werden würden, kann die Neuanlage fehlschlagen, weil das Konto zu weit überzogen wird.

Ein anderes Beispiel ist eine Online-Kommunikationsplattform. In besagtem System kam es zu einem zweistündigen Ausfall, weil ein Benutzer etwa 10.000 mal pro Sekunde geklickt hat. Auch wenn dieser Angreifer nach nur 10 Minuten gesperrt wurde, dauerte es etwa zwei Stunden, bis die Warteschlange abgearbeitet war. In dieser Zeit konnte sich kein anderer Benutzer anmelden.

Aus diesem Anlass wurden die Datenbankzugriffe kategorisiert:

• Benutzeranmeldung und Abmeldung, inklusive dem Laden und Speichern von Einstellungen

• Protokollierung von Statistiken zur Systemauslastung und Qualität der Übertragungen

• Protokollierung von Informationen zu Spam und Überlastungsangriffen (Denial-of-Service)

Innerhalb dieser Gruppen werden die Transaktionen streng nach Reihenfolge durchgeführt. Also beispielsweise wird erst ein Abmelden mit Speichern der Einstellungen verarbeitet, bevor das folgende Anmelden mit dem Laden der Einstellungen verarbeitet wird.

Aber jetzt wird ein Anmelde-Vorgag ausgeführt, auch wenn in Kategorie 3 noch hunderttausende von Anfragen warten.

In diesem Zusammenhang war es wichtig, die Protokollierung von Zeitstempeln anzupassen. Bisher wurden Zeitstempel beim Schreiben in die Datenbank durch den Datenbankserver selbständig erstellt. Diese Zeitstempel konnten damit zwar jünger sein als der tatsächliche Zeitpunkt, aber sie waren Konsistent.

Das ist jetzt nicht mehr der Fall. Der Anmelde-Vorgang wird sofort verarbeitet, der dazugehörige Protokollierungseintrag allerdings erst in ein paar Minuten. Eine Zuordnung wäre nicht mehr möglich. Daher musste die Behandlung von Zeitstempel so angepasst werden, dass der Zeitpunkt des Hinzufügens zur Warteschlange zwischengespeichert und verwendet wird.