Asynchrone Event
Verarbeitung
Jan Gregor Emge-Triebel (@jan0707)
Dennis Oehme (@dennisoehme)
Symfony User Group Frankfurt
...
Garden of Concepts GmbH
● Hanau / München
● Eigenes CMS - System
● Eigenes CRM - System
● Individual - Entwicklungen
● Sym...
Requests == Event
“Symfony is a request based
framework.”
Fabien Potencier, Symfony Live 2014
@fabpot
Requests
Request Controller Logik 1 Logik 2 Response
Request Controller
Logik 1
Logik 2
Response
Synchron
Asynchron
Warum benötigen wir asynchrone Verarbeitung?
● Langläufige Prozesse auslagern
● Reaktionszeit verkürzen
● Verlagerung von ...
Unsere Reiseroute
● Gearman
● (PHP) Resque
○ Demo
● RabbitMQ
Gearman
● Gearman Job Server (in C geschrieben)
● Läuft als Linux Daemon
● PECL Extension für Worker API
● Worker APIs für...
Gearman
http://gearman.org/examples/send-emails/
Gearman
● PECL-Extension Version 1.1.2 von August 2013
● Letztes Server-Release von Anfang 2014
● Gefühlter Stillstand
● G...
(PHP) Resque
● Portierung von Resque:
○ Resque is a Redis-backed Ruby library for creating background jobs, placing them o...
Demo
https://github.com/Jan0707/async-symfony
(PHP) Resque
● Seit 2012 unregelmäßig Commits im Master, letzter 2015-05-12
● chrisboulton/php-resque & michelsalib/BCCRes...
RabbitMQ
Oder warum wir den Vortrag
“Asynchrone Event Verarbeitung mit RabbitMQ”
hätten nennen sollen
RabbitMQ
● Message Broker in Erlang geschrieben
● AMQP (Advanced Message Queuing Protocol)
● Offenes, aber binäres Netzwer...
Vom publishen und consumen...
Publisher Publish Consumer
Ex-
change
QueueRoutes Consumes
There is a Bundle for it
● https://github.com/php-amqplib/RabbitMqBundle
● Consumer und Producer werden zu Symfony-Service...
app/config/rabbitmq.yml
Symfony Producer
Symfony Consumer
Erfahrungen mit Consumern
● PHP-Prozesse sind nicht für langläufige Prozesse gemacht
○ Ungewohnte Probleme: Memory Leaks, ...
Message
● Kompakte Messages, Queues fressen Storage / RAM
● Allgemeines Format, z.B. JSON oder XML
○ Keine serialisierten ...
Message Transformation
● JMS/Serializer um Objekte nach JSON zu konvertieren
○ Im Consumer JSON-formatierte Strings zurück...
Message Header
● Message “Header” für Content-Type und Version
○ Messages könnten sich ändern, Consumer müssen kompatibel ...
Tipp: Eigene Consumer- / Producer-Klassen
● Message Transformation
● Events
● Logging
Transaktionen
● Messages werden immer exakt einem Consumer zugewiesen
● Consumer muss explizit eine Nachricht mit “acknowl...
Toxic Messages
● Wird eine Message nicht explizit beantwortet, landet sie wieder in der Queue
● Wiederholt sich der Vorgan...
Dead Letter Exchange
● RabbitMQ kennt daher die sog. Dead Letter Exchange (DLX)
● Queue bestimmt eine DLX, eine weitere Qu...
app/config/rabbitmq.yml
Signal Handling
● Graceful Shutdown
● pcntl_signal / _dispatch
● SIGTERM
● FATAL ERROR abfangen
● Logging
● Toxic Message-...
Deployment
● Consumer benötigen i.d.R. die aktuelle Code-Base
● Consumer benötigen einen “graceful” Shutdown
● Consumer so...
Und andere Herausforderungen
● Maßgebliche Änderung der Infrastruktur
○ Vorsicht bei der Partnerwahl / Abhängigkeit
● Last...
Fragen ?
Danke :)
Diesen und andere Talks findet ihr auf:
https://www.gardenofconcepts.com/talks/
Talk bewerten nicht verg...
Nächste SlideShare
Wird geladen in …5
×

Asynchrone Event Verarbeitung

376 Aufrufe

Veröffentlicht am

Vortrag auf der Symfony UG Frankfurt zum Thema "Asychrone Event Verarbeitung" mit Symfony2 und RabbitMQ im Speziellen. Wir zeigen hier die Vor- und Nachteil, sowie einige Best Practices und Erfahrungswerte.

Veröffentlicht in: Software
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
376
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
18
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Asynchrone Event Verarbeitung

  1. 1. Asynchrone Event Verarbeitung Jan Gregor Emge-Triebel (@jan0707) Dennis Oehme (@dennisoehme) Symfony User Group Frankfurt 25. Februar 2016
  2. 2. Garden of Concepts GmbH ● Hanau / München ● Eigenes CMS - System ● Eigenes CRM - System ● Individual - Entwicklungen ● Symfony Entwicklung ○ MongoDB, ElasticSearch, MySQL, RabbitMQ, Redis, AngularJS, Twig, Jade, Gitlab, Docker, Vagrant, Ansible ● Say hi @goc_mediastudio
  3. 3. Requests == Event “Symfony is a request based framework.” Fabien Potencier, Symfony Live 2014 @fabpot
  4. 4. Requests Request Controller Logik 1 Logik 2 Response Request Controller Logik 1 Logik 2 Response Synchron Asynchron
  5. 5. Warum benötigen wir asynchrone Verarbeitung? ● Langläufige Prozesse auslagern ● Reaktionszeit verkürzen ● Verlagerung von Last ● Microservices ● Parallelisierung von Prozessen ● Skalierbarkeit ● Austausch von Nachrichten mit anderen (Sub-)Systemen
  6. 6. Unsere Reiseroute ● Gearman ● (PHP) Resque ○ Demo ● RabbitMQ
  7. 7. Gearman ● Gearman Job Server (in C geschrieben) ● Läuft als Linux Daemon ● PECL Extension für Worker API ● Worker APIs für weiteren Sprachen (C, Perl,...)
  8. 8. Gearman http://gearman.org/examples/send-emails/
  9. 9. Gearman ● PECL-Extension Version 1.1.2 von August 2013 ● Letztes Server-Release von Anfang 2014 ● Gefühlter Stillstand ● Gearmand und Extension oftmals inkompatibel / instabil
  10. 10. (PHP) Resque ● Portierung von Resque: ○ Resque is a Redis-backed Ruby library for creating background jobs, placing them on multiple queues, and processing them later. ● Nutzt Redis(-Cluster) ● Redis beherrscht atomare Transaktionen (FIFO)
  11. 11. Demo https://github.com/Jan0707/async-symfony
  12. 12. (PHP) Resque ● Seit 2012 unregelmäßig Commits im Master, letzter 2015-05-12 ● chrisboulton/php-resque & michelsalib/BCCResqueBundle tot ?
  13. 13. RabbitMQ Oder warum wir den Vortrag “Asynchrone Event Verarbeitung mit RabbitMQ” hätten nennen sollen
  14. 14. RabbitMQ ● Message Broker in Erlang geschrieben ● AMQP (Advanced Message Queuing Protocol) ● Offenes, aber binäres Netzwerkprotokoll ● Routing, Verteilen von Messages, etc. ● Transaktionen ● Weitere tolle Features ○ TTL ○ DLX (Dead Letter eXchange) ○ PreFetching
  15. 15. Vom publishen und consumen... Publisher Publish Consumer Ex- change QueueRoutes Consumes
  16. 16. There is a Bundle for it ● https://github.com/php-amqplib/RabbitMqBundle ● Consumer und Producer werden zu Symfony-Services ● Queue Consumer werden als Symfony Command ausgeführt ● Konfiguration via app/config.yml ○ Besser: app/config/rabbitmq.yml und in app/config/config.yml importieren
  17. 17. app/config/rabbitmq.yml
  18. 18. Symfony Producer
  19. 19. Symfony Consumer
  20. 20. Erfahrungen mit Consumern ● PHP-Prozesse sind nicht für langläufige Prozesse gemacht ○ Ungewohnte Probleme: Memory Leaks, ... ● Mit Supervisor Consumer überwachen und neu starten lassen ● Offene Datenbank-Verbindungen, ggf. Timeouts = Beendigung bei Inaktivät ● Begrenzte Laufzeit pro Prozess (nach x Messages automatisch beenden) ● Memory Limit: RabbitMQ-Bundle hat eine Art “Soft-Quota” ● Anlaufen von Consumern dauert vergleichsweise lange ● Prefetching (Achtung: Reihenfolge!)
  21. 21. Message ● Kompakte Messages, Queues fressen Storage / RAM ● Allgemeines Format, z.B. JSON oder XML ○ Keine serialisierten PHP Objekte oder Array, um langfristig Interoperabilität mit anderen System oder Sprachen zu gewährleisten
  22. 22. Message Transformation ● JMS/Serializer um Objekte nach JSON zu konvertieren ○ Im Consumer JSON-formatierte Strings zurück in Objekte ○ Objekte lassen sich dank Symfony Form und Asserts validieren ○ Alternativ: PHPs JsonSerializable Interface ○ Entities / Dokumente ggf. neu laden / aktualisieren (Unit of Work)
  23. 23. Message Header ● Message “Header” für Content-Type und Version ○ Messages könnten sich ändern, Consumer müssen kompatibel bleiben ● Eindeutige IDs machen das Logging / Debugging / Leben einfacher ● Weitere Metadaten: ○ Zeitstempel ○ User ○ App ID, etc.
  24. 24. Tipp: Eigene Consumer- / Producer-Klassen ● Message Transformation ● Events ● Logging
  25. 25. Transaktionen ● Messages werden immer exakt einem Consumer zugewiesen ● Consumer muss explizit eine Nachricht mit “acknowledge” beantworten ● Andernfalls wird Nachricht rejected (and ggf. requeued) ○ Verwerfen heißt ggf. Datenverlust ○ Requeuing - Achtung: ■ könnte u.U. zu sog. Toxic Messages führen ■ könnte die Reihenfolge der Messages verändern
  26. 26. Toxic Messages ● Wird eine Message nicht explizit beantwortet, landet sie wieder in der Queue ● Wiederholt sich der Vorgang, haben wir eine Endlosschleife
  27. 27. Dead Letter Exchange ● RabbitMQ kennt daher die sog. Dead Letter Exchange (DLX) ● Queue bestimmt eine DLX, eine weitere Queue, in der alle Messages landen, die zurückgewiesen wurden (Reject, TTL, Prefetch)
  28. 28. app/config/rabbitmq.yml
  29. 29. Signal Handling ● Graceful Shutdown ● pcntl_signal / _dispatch ● SIGTERM ● FATAL ERROR abfangen ● Logging ● Toxic Message-Handling Shutdown
  30. 30. Deployment ● Consumer benötigen i.d.R. die aktuelle Code-Base ● Consumer benötigen einen “graceful” Shutdown ● Consumer sollten nur bei Inaktivät beendet werden ○ Sonst Message/Daten - Verlust
  31. 31. Und andere Herausforderungen ● Maßgebliche Änderung der Infrastruktur ○ Vorsicht bei der Partnerwahl / Abhängigkeit ● Last verschoben ist nicht aufgehoben ● Umdenken erforderlich ○ Statusanzeige ○ Zwischenstände ○ Push statt Pull / Websockets ● Abhängigkeiten von Messages ○ Insbesondere bei Parallelisierung ! ● Performance (insg. mit Doctrine ORM / ODM)
  32. 32. Fragen ? Danke :) Diesen und andere Talks findet ihr auf: https://www.gardenofconcepts.com/talks/ Talk bewerten nicht vergessen!

×