Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
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

596 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
  • Als Erste(r) kommentieren

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

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!

×