...
В дополнение к реляционной базе данных мы дополнительно используем in-memory (т.е. хранящую все данные в оперативной памяти) key-value (т.е. хранящую данные в виде ассоциативного массива ключ-значение) базу данных Redis. За счёт работы в оперативной памяти Redis является очень быстрым хранилищем, отлично подходящим для кэширования часто запрашиваемых данных, и хранения временной информации информации.
И, наконец, ещё одна значимая область бэкенда - это фоновые задания. Обычно взаимодействие с пользователем происходит в формате "запрос-ответ": пользователь отправил запрос, бэкенд сходил в БД, достал данные и отдал их в ответе. Однако иногда в результате запроса требуется запустить какое-либо задание, окончания которого не нужно дожидаться "здесь и сейчас" - например, при бронировании стиральной машинки мы хотим отправить пользователю уведомление в ВК за 10 минут до начала бронирования. Для выполнения таких "фоновых" заданий требуется отдельный механизм.
Такой механизм предоставляет фреймворк Celery
По сути он позволяет с помощью специального декоратора объявить python-функцию как асинхронную задачу. Такую функцию можно вызывать как обычную функцию (тогда она будет выполняться в процессе Django в процессе обработки запроса пользователя), а можно вызывать как асинхронную - тогда django вместо прямого выполнения функции добавит сообщение о необходимости выполнить функцию в специальную очередь и "забудет". В качестве специальной очереди используется специальная база данных сообщений (она называется "брокер сообщений") RabbitMQ.
Итак, Django отправляет сообщения в RabbitMQ о том, что надо выполнить функцию. Django выступает в роли "Producer" - отправщика. А кто эту функцию по-факту выполняет?
Для выполнения асинхронных задач у нас запускаются отдельные программы - воркеры фоновых задач. Они спрашивают RabbitMQ о новых сообщениях, и при получении сообщения начинают выполнять указанную функцию. Эти воркеры (в дальнейшем будем называть их Celery-воркеры, или консьюмеры/Consumers) - это такие же python-приложения, только запущенные с другими параметрами. Благодаря использованию одинаковой кодовой базы с веб-сервером, эти воркеры понимают, о какой именно функции "говорил" веб-сервер, и как её выполнять.
Архитектурно получается следующая картинка:
Для понимания всего вышесказанного настоятельно рекомендуется прочитать и понять следующую статью