LINUX.ORG.RU

Mesage Queue + Python


0

0

Хочется следующего: Есть на удаленной машине Web приложение, оно должно общаться с корпоративной системой. Думаю использовать какой-нибудь MQ. Линии связи не всегда хорошие, да и система может быть в какой-то момент недоступна (обновление или что-то еще). Хочется, чтобы Web приложение посылало запросы на актуализацию цены например, показывая её из кэша. А когда получит ответ обновляло кэш. Хочется коллбэки на ошибки связи еще, чтоб прореагировать (почту админу отправить или что-то еще).

Кто с таким работал, что можете посоветовать?

Не буду оригинальна - запланированная однонаправленная синхронизация с подгрузкой данных и «большой» системы. Наименее ресурсоемкий и наименее трудозатратный вариант, как мне кажется. MQ здесь «из пушки по воробьям».

Nastishka ★★★★★ ()
Ответ на: комментарий от Nastishka

Ну вопервых она не однонаправленная. В системе постоянно меняются остатки, цены.... С другой стороны пользователи Web интерфейса постоянно делают заявки.

Соединения регулярно падают. Я использовал различные RPC. Но хочется асинхронности. Сделал заявку, она отметилась как «стоит в очереди». Большая система в этот момент может быть переведена на обслуживание. RPC тут потыкался и сдох. А хочется, чтоб когда связь восстановилась все продолжило жить. Большая система получила запрос, сделала дело. Взлетел коллбэк. А варианты с загрузкой всего и вся по крону.. Там 9 гигов данных. Нужны все практически. Но иногда одни, иногда другие. Делаем так - пишем на страничке «Кисточка - 5 руб (цена устарела)» jQuery делает запрос на обновление именно этой цены. Это летит в Web интерфейс и там кеш обновляется и страница перерисовывает только цену. А если коннекта нету, ну ждем....

demmsnt ()

Точно так-же пользователь зашел на страницу (а он может по пол года туда не заходить). Сразу полетел запрос в БОЛЬШУЮ систему, обновить данные пользователя (документы, сделки, прайсы). И это готовится в большой системе (это минут 5 может занять). И потихоньку приходит в Web интерфейс. А пользователей несколько тысяч и грузить всегда поледние данные по всем накладно.

demmsnt ()

А почему бы не попробовать Real-time Web? Вроде как раз тот самый случай, особенно если клиентов много.

Клиент не будет постоянно запрашивать обновление цены, а просто будет ждать пока большая система не пришлет ответ.

Для Питона есть прекрасный Orbited, в нем же и STOMP.

Если система реально большая и медленная, то можно поставить прослойку типа redis, чтобы она хранила данные в памяти.

ntp ()
Ответ на: комментарий от ntp

Большую систему пишут «Плохие парни». Они могут взять и одним махом поменять там много чего. В итоге я бегу за поездом. Это раз. Во вторых как я уже сказал работоспособность большой системы в неделю по 3 часа стоим...

Насчет прослойки, опять-же Все данные редиска хранить не сможет. Там надо умный кэш. Который понимает, что вот эти документы не менялись....

demmsnt ()
Ответ на: комментарий от ntp

Да и написана большая система из серии «Рассчитаю бооооооольшой лист, потом загружу его на клиента в DBF». Потом клиент мордуется с этим DBF, а потом изменения пачкой летят.

demmsnt ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.