Redis und RabbitMQ sind vielleicht die Broker der Wahl, wenn Sie Celery verwenden, aber wenn Sie lokal entwickeln, können sie sich wie ein Overkill anfühlen. In der Dokumentation zu Celery 5.4 wird erwähnt, dass Sie SQLite als experimentellen Broker für die lokale Entwicklung verwenden können. Wenn Sie jedoch zur Backend- und Broker-Seite von Celery navigieren, wird SQL nur für das SQLAlchemy-Backend erwähnt. Glücklicherweise stellt die Seite fest, dass „dieser Abschnitt Backends und Broker nicht umfassend behandelt.“

Dieser Beitrag zeigt Ihnen, wie Sie einen SQLite-Broker (oder ein beliebiges SQL!) für Celery in einem Django-Projekt implementieren. In diesem Beitrag lernen Sie nicht, wie man Celery verwendet: Schauen Sie sich dazu die offizielle Celery-Dokumentation an.

Bevor wir beginnen

Für die Zwecke dieses Beitrags gehen wir davon aus, dass Sie bereits ein bestehendes Django-Projekt mit Celery installiert haben, indem Sie die Schritte aus Celerys offiziellem Leitfaden „Erste Schritte mit Django“ befolgen. Ein Celery-Backend ist nicht erforderlich, aber Sie können die Schritte in der Anleitung zum Installieren und Konfigurieren von django-celery-results befolgen. Wenn Sie sich nicht sicher sind, was der Unterschied zwischen Backends und Brokern ist, lesen Sie meinen Artikel „Aufgaben, Broker, Worker und Backends in Celery verstehen.“

Alle Links zur Quelldokumentation gelten für die aktuellen Versionen von Django, Celery und SQLAlchemy zum Zeitpunkt der Veröffentlichung (Juli 2024), sofern nicht ausdrücklich anders angegeben. Wenn Sie dies in ferner Zukunft lesen, haben sich die Dinge möglicherweise geändert.

Einrichten des SQL Brokers

Während Celery Aufgaben und Warteschlangen verwaltet, delegiert es den Nachrichtenaustausch mit dem Broker an eine andere Bibliothek namens Kombu. RabbitMQ und Redis sind die funktionsreichsten Transporte (Broker) von Kombu, es gibt aber auch virtuelle Transporte für Amazon SQS, ZooKeeper und MongoDB.

Versteckt in den hintersten Ecken der Kombu-Dokumentation gibt es ein SQLAlchemy-Transportmodell, das PostgreSQL, MySQL und SQLite unterstützt. Es gab einmal eine Zeit, in der der SQLAlchemy-Broker sogar auf der Website von Celery dokumentiert war, aber seitdem wurde er aus den Dokumenten in neueren Versionen der Bibliothek entfernt. Dennoch funktioniert es immer noch gut genug für die lokale Entwicklung.

Um eine Folgedatenbank als Celery-Broker in Ihrer Django-App zu verwenden, installieren Sie zunächst SQLAlchemy:

pip install SQLAlchemy

In der Datei „settings.py“ Ihres Django-Projekts können Sie das Backend Ihres Brokers mithilfe der Einstellung „CELERY_BROKER_URL“ festlegen:

# BASE_DIR is the directory of your project's main directory.

CELERY_BROKER_URL = f"sqlalchemy sqlite:////{BASE_DIR}/broker.sqlite3"

Die SQLAlchemy Broker-URL besteht aus 3 Teilen:

1. Die Zeichenfolge sqlalchemy oder sqla (sie sind austauschbar)
2. Ein Zeichen
3. Eine SQLAlchemy-Verbindungszeichenfolge

Verbindungszeichenfolgen unterscheiden sich für SQLite auf Mac/Unix und Windows:

# MacOS/Unix
CELERY_BROKER_URL = "sqla sqlite:////your/project/path/broker.sqlite3"

# Windows
CELERY_BROKER_URL = "sqla sqlite:///C:your\\project\\path\\broker.sqlite3"

Sie können Postgres auch als Celery-Broker verwenden, oder Sie können MySQL genauso einfach als Celery-Broker verwenden:

# MySQL
CELERY_BROKER_URL = "sqlalchemy mysql://scott:tiger@localhost/foo"

# PostgreSQL
CELERY_BROKER_URL = "sqla postgresql://scott:tiger@localhost/mydatabase"

# PosgreSQL connecting using pg8000
CELERY_BROKER_URL = "sqla postgresql pg8000://scott:tiger@localhost/mydatabase"

Möglicherweise müssen Sie andere Bibliotheken installieren, um eine Verbindung zu MySQL oder PostgreSQL herzustellen, und welche Bibliothek Sie installieren, kann sich auf die SQLAlchemy-Verbindungszeichenfolge auswirken. Weitere Informationen finden Sie in den URL-Dokumenten der SQLAlchemy-Datenbank.

Unabhängig davon, für welche Datenbank Sie sich entscheiden, sollten Sie die Speicherung der Broker-URL in einer Umgebungsvariablen in Betracht ziehen, um eine einfache Änderung in verschiedenen Umgebungen zu ermöglichen:

CELERY_BROKER_URL = os.getenv("CELERY_BROKER_URL")

Ein Wort der Vorsicht

Der SQLAlchemy-Transport gilt wahrscheinlich als experimentell und ist daher nicht für den Produktionseinsatz gedacht. Es kann zu Datenverlust kommen oder Nachrichten könnten mehrfach zugestellt werden. Erwägen Sie den Wechsel zu einem robusteren Broker, der auf der Seite „Broker und Backends“ von Celery aufgeführt ist.

Das heißt, es könnte für die lokale Entwicklung oder sogar kleine Nebenprojekte in Ordnung sein. Aber ich wäre nicht schockiert, wenn die Möglichkeit, SQLAlchemy als Broker zu verwenden, in Zukunft wegfallen würde.

Nächste Schritte

Wenn Celery lokal ausgeführt wird, können Sie mit der Arbeit an Ihrer warteschlangengesteuerten Anwendung beginnen. Allerdings kann es sein, dass das Fehlen einer automatischen Nachladefunktion einen Reibungspunkt darstellt. Wenn Sie das automatische Neuladen von Celery in Ihrer Django-Anwendung einrichten möchten, lesen Sie meinen Beitrag „Celery-Worker mit einem benutzerdefinierten Django-Befehl automatisch neu laden.“