Работя върху това да накарам някои разпределени задачи да работят чрез RabbitMQ.
Прекарах известно време, опитвайки се да накарам Celery да направи това, което исках, и не можах да го накарам да работи.
След това се опитах да използвам Pika и нещата просто заработиха, безупречно и за минути.
Има ли нещо, което пропускам, като използвам Pika вместо Celery?
Това, което pika предоставя, е само малка част от това, което Celery прави. Pika е библиотека на Python за взаимодействие с RabbitMQ. RabbitMQ е брокер на съобщения; в основата си той просто изпраща съобщения до/получава съобщения от опашки. Може да се използва като опашка със задачи, но може и просто да се използва за предаване на съобщения между процеси, без реално да се разпределя „работата“.
Celery прилага разпределена опашка със задачи, като по избор използва RabbitMQ като брокер за IPC. Вместо просто да предоставя начин за изпращане на съобщения между процесите, той предоставя система за разпределяне на действителни задачи/задачи между процесите. Ето как го описва сайтът на Celery:
Опашките със задачи се използват като механизъм за разпределяне на работата между нишки или машини.
Входът на опашката със задачи е единица работа, наречена задача, специализирани работни процеси, след което постоянно наблюдават опашката за нова работа, която да извършат.
Celery комуникира чрез съобщения, като обикновено използва брокер за посредничество между клиенти и работници. За да инициира задача, клиентът поставя съобщение на опашката, след което брокерът доставя съобщението на работник.
Системата Celery може да се състои от множество работници и брокери, което дава път на висока наличност и хоризонтално мащабиране.
Celery има цял куп вградени функции, които са извън обхвата на pika. Можете да разгледате документите на Celery, за да добиете представа за нещата, които може направи, но ето един пример:
>>> from proj.tasks import add
>>> res = add.chunks(zip(range(100), range(100)), 10)()
>>> res.get()
[[0, 2, 4, 6, 8, 10, 12, 14, 16, 18],
[20, 22, 24, 26, 28, 30, 32, 34, 36, 38],
[40, 42, 44, 46, 48, 50, 52, 54, 56, 58],
[60, 62, 64, 66, 68, 70, 72, 74, 76, 78],
[80, 82, 84, 86, 88, 90, 92, 94, 96, 98],
[100, 102, 104, 106, 108, 110, 112, 114, 116, 118],
[120, 122, 124, 126, 128, 130, 132, 134, 136, 138],
[140, 142, 144, 146, 148, 150, 152, 154, 156, 158],
[160, 162, 164, 166, 168, 170, 172, 174, 176, 178],
[180, 182, 184, 186, 188, 190, 192, 194, 196, 198]]
Този код иска да добави всеки x+y, където x е в range(0, 100), а y е в range(0,100). Той прави това, като взема задача, наречена add, която добавя две числа, и разпределя работата по добавяне на 1+1, 2+2, 3+3 и т.н. на части от по 10 и разпределя всяка част на толкова работници на Celery, колкото са налични. Всеки работник ще стартира add на своята част от 10 елемента, докато цялата работа приключи. След това резултатите се събират от повикването res.get(). Сигурен съм, че можете да си представите начин да направите това с помощта на pika, но съм сигурен, че можете също да си представите колко работа ще е необходима. Получавате тази функционалност веднага с Celery.
Със сигурност можете да използвате pika за внедряване на разпределена опашка от задачи, ако искате, особено ако имате доста прост случай на използване. Celery просто предоставя решение „включени батерии“ за планиране на задачи, управление и т.н., които ще трябва да внедрите ръчно, ако решите, че ги искате с вашето pika решение.
Ще добавя отговор тук, защото това е вторият път днес, когато някой препоръчва целина, когато не е необходима въз основа на този отговор, който подозирам. Така че разликата между разпределена опашка със задачи и брокер е, че брокерът просто предава съобщения. Нито повече, нито по-малко. Celery препоръчва използването на RabbitMQ като брокер по подразбиране за IPC и поставя върху него адаптери за управление на задачи/опашки с процеси на демон. Въпреки че това е полезно, особено за разпределени задачи, където имате нужда от нещо общо много бързо. Това е просто конструкция за процеса издател/потребител. Действителни задачи, при които сте дефинирали работен процес, през който трябва да преминете и да осигурите трайност на съобщението въз основа на вашите специфични нужди, ще бъде по-добре да напишете свой собствен издател/потребител, отколкото да разчитате на целина. Очевидно все още трябва да извършите всички проверки на издръжливостта и т.н. С повечето свързани с мрежата услуги човек не контролира действителните „работни“ единици, а по-скоро ги предава на услуга. По този начин няма смисъл от опашка с разпределени задачи, освен ако не достигате произволно ограничение за извикване на API въз основа на ip/географски регион или номер на акаунт... Или нещо в този дух. Така че използването на celery не ви пречи да се налага да пишете или да се занимавате с код на състоянието или управление на работния процес и т.н. и излага AMQP по начин, който ви улеснява да избягвате писането на конструкциите на кода за издател/потребител.
Така че накратко, ако имате нужда от проста опашка със задачи, за да дъвчете работата и не сте наистина загрижени за нюансите на производителността, тънкостите на издръжливостта на вашия работен процес или действителните процеси на публикуване/използване. Целината работи. Ако просто предавате съобщения на api или услуга, която всъщност не контролирате, разбира се, можете да използвате Celery, но бихте могли също толкова лесно да привлечете своя собствен издател/потребител с Pika за няколко минути. Ако имате нужда от нещо стабилно или което се придържа към вашите собствени сценарии за издръжливост, напишете свой собствен код за публикуване/потребител като всички останали.
