Skalierung mit dem Observer Pattern und Events in PHP

Das ist ja mal ein abstrakter Titel! Aber im Artikel versteckt sich einer der besten Skalierungstipps, die ich derzeit im Angebot habe.

Normalerweise sind alle Webapplikationen durch Benutzer-Events getrieben. Der Surfer klickt irgendwo, stößt ein Skript an, das macht irgendwas und er kriegt ein Ergebnis. Spannend wird es immer dann, wenn dieses “irgendwas machen” länger dauert, als man dem Surfer zumuten möchte. Dann geht es los mit Cronjobs und Spooler-Tabellen. Es geht aber auch schlauer.

Ein Beispiel aus unserem Alltag: wenn sich bei Hitmeister der Preis eines Artikels ändert, gucken wir ob jemand per E-Mail informiert werden möchte (Preisalarm). Jetzt ändert sich auch der Preis eines Artikels, wenn jemand etwas in den Warenkorb legt. Soll derjenige, der sogar noch im Kaufprozess ist, warten bis alle Mails verschickt wurden? Sicher nicht.

Der klassische Ansatz wäre hier einen Spooler einzubauen, der dann durch einen Cron abgearbeitet wird. Das ist auch eine zeitlang sinnvoll. Nur gibt es bei großen Projekten irgendwann dutzende Crons mit entsprechenden Tabellen. Man muss die Crons warten, den Tabellenstand überprüfen, den Verlauf monitoren usw. Nicht schön.

Die Lösung? Events und ein Observer Pattern. Wir haben eine kleine message queue programmiert. Da drin gibt es eine Queue, /Events (Füchse erkennen direkt die baumartige Struktur). In dieser Queue stehen dann Meldungen mit einem header und einem body, wie z.B.

header | body
PriceChange | id_item = 12345
ContentUpdate | id_item = 56789
NewOrder | id_order = 1234

Der Body ist ein serialisiertes Array (hier vereinfacht dargestellt). Jetzt gibt es nur eine Komponente, bei uns einfallsreicherweise Observer genannt, die diese Queue abarbeitet. Jeder header entspricht dabei einer Klasse. Wenn ein header kommt, wird der Code in der klasse ausgeführt. Die Parameter im body reichen dabei aus, um alles auszuführen. Hinterher wird die message gelöscht.

So ein Observer ist eine prima Sache. Jeder, der etwas asynchron verarbeiten möchte, kann dem Observer mitteilen bei welchen Events etwas aufgerufen werden soll. Artikel in Exporten modifizieren, wenn der Artikel sich ändert? Kein Problem. Langsame externe URLs aufrufen, wenn es eine neue Bestellung gibt? Auch easy.

Und wenn man den Observer saubert programmiert (ACID usw.) dann kann der auf beliebig vielen Rechner laufen. Und zack können wir eine Weile länger horizontal skalieren!

Wir haben unsere Message Queue selbst programmiert. Wer das ganze in Groß angehen möchte, sollte sich AMQP, RabbitMQ und ActiveMQ anschauen (alle in Java, aus dem Bankenumfeld). Die bieten dann nette Features wie Priorisierung, Echtzeit-Messages usw. Man kann auch Amazon SQS verwenden, wobei ich eine ausgelagerte Queue wegen der hohen Latenz für ziemlich sinnlos halte.

This entry was posted on Montag, Juni 16th, 2008 at 2:46 pm and is filed under PHP, Neue Technologien. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.