Сельдерей: общение между задачами (и клиентами) с комбу - PullRequest
Новая
       51

Сельдерей: общение между задачами (и клиентами) с комбу

1 голос
/ 23 января 2020

Это меня расстраивает и тратит много времени на исследования и реверс-инжиниринг из-за отсутствия документов Celery на внутренних устройствах. Здесь есть прекрасное учебное пособие:

https://ask.github.io/celery/tutorials/clickcounter.html

, которое делает именно это, использует комбу для связи между видом Django и задачей Celery. Но это для Celery 2.6 и хорошо, это 2020, и мы используем 4.4, и это в частности: 

from celery.messaging import establish_connection

давно устарел. Он также опирается на kombu.compat, когда я думаю, что уроженцы комбу будут работать нормально, и нам не нужно полагаться на совместимость с морковью, которую обеспечивает этот модуль. Но это побочный вопрос.

Моя главная проблема - привести этот пример в актуальное состояние, и я не нахожу никаких документов Celery, которые могли бы помочь, и до сих пор не могу, после нескольких часов чтения и отслеживания кода, все еще не обращая внимания на аналог это в Celery 4.4.

Я нахожу подсказки и подсказки по всей базе кодов сельдерея, просто не получил ответа.

Я был бы рад, благодарен и взволнован, если бы более опытный голос побродил и пролил свет на это, помог получить такой пример, как этот учебник, работающий с использованием методов Celery 4.4.

Для иллюстрации я нашел это: 

COMPAT_MODULES = {
    'celery': {
        'execute': {
            'send_task': 'send_task',
        },
        'decorators': {
            'task': 'task',
            'periodic_task': _compat_periodic_task_decorator,
        },
        'log': {
            'get_default_logger': 'log.get_default_logger',
            'setup_logger': 'log.setup_logger',
            'setup_logging_subsystem': 'log.setup_logging_subsystem',
            'redirect_stdouts_to_logger': 'log.redirect_stdouts_to_logger',
        },
        'messaging': {
            'TaskConsumer': 'amqp.TaskConsumer',
            'establish_connection': 'connection',
            'get_consumer_set': 'amqp.TaskConsumer',
        },
        'registry': {
            'tasks': 'tasks',
        },
    },
    'celery.task': {
        'control': {
            'broadcast': 'control.broadcast',
            'rate_limit': 'control.rate_limit',
            'time_limit': 'control.time_limit',
            'ping': 'control.ping',
            'revoke': 'control.revoke',
            'discard_all': 'control.purge',
            'inspect': 'control.inspect',
        },
        'schedules': 'celery.schedules',
        'chords': 'celery.canvas',
    }
}

здесь: https://github.com/celery/celery/blob/master/celery/local.py

, который является дразнящей подсказкой, которую celery.messaging.establish_connection заменили на ... connection ... хотя интерпретировать это сложно.

Приложение Celery, созданное при создании экземпляра Celery: 

app = Celery('current_module', broker='pyamqp://mybroker', backend='rpc://')

имеет атрибут connection, и все же app.connection не заменяет connection = establish_connection() в этом уроке (жизнь не так проста) .

Я буду продолжать изучать это и пытаться разобраться с этим, но я хочу пригласить любого, кто мог бы сэкономить мне время и усилия, с помощью некоторых указателей, чтобы помочь, с некоторым примером кода, который открывает соединение Kombu и отправляет сообщение в одной функции (скажем, представление Django) и открывает соединение kombu и получает сообщение в другой функции (скажем, задача Celery) либо с нуля (игнорировать Celery), либо в гораздо более идеальном случае, используя Celery (поскольку Celery уже имеет все конфиги для брокера на месте и, вероятно, получили вспомогательные функции для этого.

Одним из кандидатов могут быть классы Celery Queue или SimpleQueue, но у них нет внутренней документации любого вида, которую я могу найти.

...