Microservices
Ein Architekturmuster, bei dem eine Anwendung aus vielen kleinen, unabhängigen Services besteht, die jeweils eine spezifische Aufgabe erfüllen.
Ein Kommunikationsmuster, bei dem Nachrichten in einer Warteschlange zwischengespeichert werden – ermöglicht asynchrone, entkoppelte Kommunikation zwischen Services.
Eine Message Queue ist eine Warteschlange für Nachrichten zwischen Services. Der Sender legt eine Nachricht ab und macht weiter. Der Empfänger holt sie ab, wenn er bereit ist.
Warum ist das nützlich?
Ohne Queue (synchron):
User → API → LLM (30 Sekunden warten) → Response
= User wartet, Server blockiert
Mit Queue (asynchron):
User → API → "Job in Queue, ID: abc123" (sofort)
Worker → Queue → LLM → Ergebnis speichern
User → "Status von abc123?" → Ergebnis
= User kann weitermachen, System skaliert besser
Producer → [Message Queue] → Consumer
↓
Persistenz
(Nachrichten überleben Neustarts)
from rq import Queue
from redis import Redis
redis_conn = Redis()
q = Queue(connection=redis_conn)
# Job in Queue legen
def process_llm_request(prompt):
response = call_llm_api(prompt)
save_result(response)
return response
job = q.enqueue(process_llm_request, "Erkläre ML")
print(f"Job ID: {job.id}")
# Später: Status prüfen
if job.is_finished:
result = job.result
| Broker | Stärke | Use Case |
|---|---|---|
| RabbitMQ | Flexibel, viele Patterns | Allgemein |
| Kafka | Hoher Durchsatz, Replay | Event Streaming |
| Redis | Einfach, schnell | Leichtgewichtig |
| SQS | Managed, skaliert | AWS-Umgebung |
| Garantie | Beschreibung |
|---|---|
| At-most-once | Nachricht kann verloren gehen |
| At-least-once | Nachricht kann doppelt ankommen |
| Exactly-once | Genau einmal (schwer zu erreichen) |
Eine Message Queue ist wie ein Briefkasten: Der Absender wirft den Brief ein und geht weiter (asynchron). Der Empfänger holt ihn ab, wenn er Zeit hat. Beide müssen nicht gleichzeitig verfügbar sein.
Entkoppelt Sender und Empfänger zeitlich und räumlich
Puffert Lastspitzen und erhöht Systemresilienz
Ermöglicht asynchrone Verarbeitung von LLM-Anfragen
LLM-Batch-Processing
Viele Anfragen in Queue, Worker verarbeiten asynchron
Microservices
Lose Kopplung zwischen Services
Task Queues
Hintergrund-Jobs wie E-Mail-Versand, Bildverarbeitung
Bei asynchronen Aufgaben (E-Mail, Bildverarbeitung), zur Entkopplung von Services, bei Lastspitzen (Puffer), oder wenn Sender und Empfänger unterschiedlich schnell sind.
Queue: Eine Nachricht wird von genau einem Consumer verarbeitet. Pub/Sub: Eine Nachricht geht an alle Subscriber. Kafka kann beides, RabbitMQ primär Queues.
Anfragen in Queue → Worker holt Anfrage → Ruft LLM-API auf → Ergebnis in Response-Queue oder Webhook. Ermöglicht Skalierung und Retry bei Fehlern.