это зависит (мне нравится так говорить ...), но если серьезно, чтобы спроектировать такую архитектуру, вам нужно проанализировать множество факторов, в основном потому, что у вас есть 2 проблемы здесь:
- скорость отклика от freeswitch
- очереди запросов к свободному переключателю
Если у вас будет один процесс, который будет обрабатывать все запросы и нулевой параллелизм - тогда никаких проблем вообще - вы оставите один сокет открытым и повторно открывайте его при необходимости на протяжении всего выполнения программы. Но это нереальная ситуация.
Если вы можете открыть только один сокет, тогда должна быть очередь для запросов. Это подразумевает, что весь ваш django-код должен быть асинхронным, не может быть опции, которую ваше приложение ожидает ответа, а просто проверить статус задач.
Здесь можно использовать сельдерей, но он не предназначен для того, чтобы держать сокет открытым, поскольку может быть несколько рабочих процессов, порожденных самим сельдереем - поэтому они не могут легко разделить сокет между ними. Использование потоков, гринлетов и т. Д. Может быть полезным, но все же - это не предназначено для поддержания открытого соединения.
Итак, вы получите написать свой собственный демон, я предлагаю написать его как команду управления, которая может управлять таким соединением и принимать данные из основного приложения.
В таком случае вы должны реализовать очередь, поэтому сельдерей не нужен.