Mesage Queue + Python

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

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

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

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

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

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

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

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

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

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

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