Comments 35
как устроен самый популярный Channel Layer для продакшена — Redis.
Мне было всегда интересно, почему? Redis же просто ужасен как MQ, почему он так популярен то?)
1. Он не способен хранить вещи не в памяти. То есть вам нужно, что бы очередь влезла в память, что очень не всегда получается. Более того, если он у вас еще и в персистентном режиме, то после того, как он упадет из-за нехватки памяти, он еще и не поднимется, пока вы его не почистите. У нас такое было в sentry, который по умолчанию запускает celery на redis.
2. Redis не может в нормальный master<->master кластер, вам нужно это делать на стороне приложения или использовать какие-то из redis-совместимых приложений.
Опубликовано: 3 нояб. 2016 г.ну в общем-то вопросы отменяются, хотя всё равно странно.
Хорошая новость: для того, чтобы использовать Django Channels, вам вообще не нужно знать ни Twisted, ни Redis — это все детали реализации. Это будут знать ваш DevOps, или вы познакомитесь, когда будете чинить в три часа ночи упавший продакшен.
Как красиво сказано. Но на самом деле в «детали реализации» вы полезете смотреть уже через 20 минут, когда вам захочется, например, узнать сколько юзеров в группе и через час-два гугления вы поймете что это не поддерживается API вообще и тикет закрыт с пометкой о том что так и надо.
Когда будете гуглить, то учитывайте что 90% примеров в сети и в SO в частности относятся к channels 1.x, в то время как автор уже переписал ее в 2.0 и она, мягко говоря, поменялась. В доках стоит почитать его восторги по этому поводу и порадоваться за него.
Вообще говоря, немного разочаровала эта библиотека, хотя, конечно, принесла много новых вещей. Ждали ее как silver bullet, но она довольно туповата.
Во всех без исключения примерах разбирается «чат» и кроме чата на ней, действительно, что-то реализовать уже потребует некоторых размышлений. Синяя изолента должна быть под рукой.
С 14го года не интересовался джангой, она всё также вширь и вширь? Всё больше и больше батареек? А шаблонизатор всё также отстаёт в несколько раз от jinja2 по всем параметрам? ORM думаю тоже не приблизился к уровню SQLAlchemy?
Какой тогда смысл в джанге? Оторвать от неё куски и лишится всех её плюшек? Взять фреймворк, чтобы там почти всё поменять? Мне, видимо, этого не понять. Я лучше возьму предназначенный для этого фласк или другой микрофреймворк.
Достоинство Django в том, что уже есть готовые решения для практически любой задачи. Не надо изобретать велосипед. А ORM совершенствуется с каждым релизом. Если в первые годы использования Django регулярно приходилось использовать .raw
запросы или вообще голый SQL, то внезапно осознал, что не делаю этого уже последние года 4-5.
SQLAlchemy и есть ORM.
Не так. У sqla есть слой ORM.
SQLAlchemy is the Python SQL toolkit AND Object Relational Mapper that gives application developers the full power and flexibility of SQL.
У SQLA есть core (интерфейсы и методы самого низкого уровня, напр. db.query('SELECT * FROM ..')) слой, есть query-builder, а есть ORM. ORM использует query-builder который использует core. Использованием ORM который предоставляет SQLA совершенно не обязательно, можно пользоваться прекрасным query-builder-ом и забыть про ORM совсем. Собственно, многие так и делают.
Andrew Godwin в нем ответил следующее:
In general I wouldn't recommend Channels groups for any sort of large-scale work — you should probably roll your own solution if you have more than about 50 concurrent users in any single group, as you'll know the best option to use at your scale.
… Groups is more designed to have hundreds of groups with only a few members in each (i.e. per-user).
По сути, группа в большей степени предназначена для разных подключений одного пользователя (разные браузеры/устройства). Для большого количества одновременных подключений Channels не подходит (во всяком случае пока). Глубже копать особо не стали, вернулись к прошлому решению на Centrifugo, которое успешно работало у нас несколько лет.
Каков вообще предел одновременных подключений к Channels трудно сказать, мы в него не успели упереться.
Кстати, Андрей Светлов на PiterPy говорил, что вообще ASGI это костыль и он по своей архитектуре в принципе не может работать быстро. Хотя и отметил, что это неплохое решение для Django из коробки для тех, у кого нет больших нагрузок.
Из-за чего такое происходило-то в итоге?
Django Channels – ответ современному вебу