Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
MQ подскажите архитектуру
|
|||
|---|---|---|---|
|
#18+
Добрый день. Есть сеть магазинов >50. В которых крутится самописное ПО на кассах + учет товара. Есть желание чтобы каждый чек в онлайне отображался в центральном офисе. Каналы связи более-менее везде есть, но не обязательно супер надежные. Вопрос: Как должна выглядеть архитектура решения? Нужно ставить MQ сервер в каждом магазине, чтобы магазинное ПО ложило в локальную очередь пакет данных, MQ из магазина передавало в MQ центрального офиса? Связь может быть двухсторонеей. Из магазина чеки в магазин накладные на приход товара. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2007, 13:32 |
|
||
|
MQ подскажите архитектуру
|
|||
|---|---|---|---|
|
#18+
да, так и надо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2007, 15:00 |
|
||
|
MQ подскажите архитектуру
|
|||
|---|---|---|---|
|
#18+
2 IgorTv 2 IBA не круто ли будет покупат,ставит и суппортит аж 50 мq? можно конечно (какие магазини и т.д.), но 2 two-phase commit ни кто неотменял... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2007, 01:46 |
|
||
|
MQ подскажите архитектуру
|
|||
|---|---|---|---|
|
#18+
tipa resenie... не круто ли будет покупат,ставит и суппортит аж 50 мq? можно конечно (какие магазини и т.д.), но 2 two-phase commit ни кто неотменял... а просвятите пожалуйста это о чем? Как должна выглядеть архитектура в таком случае? Что ставить в магазине что в центре? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2007, 10:11 |
|
||
|
MQ подскажите архитектуру
|
|||
|---|---|---|---|
|
#18+
На мой взгляд, Вам лучше обратиться в локальное представительство IBM в Украине. Специалисты компании помогут Вам выбрать архитектурное решение. IBM EE/A в Украине тел.: +380 44 501-1888 ул. Глубочицкая, 4 Киев, 04050, Украина ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2007, 11:19 |
|
||
|
MQ подскажите архитектуру
|
|||
|---|---|---|---|
|
#18+
Зачем вам MQ на стороне каждого магазина? Что-то мне подсказывает, что кассе не надо ждать цепочки Код: plaintext Например, передавать данные через локальный WEB сервис. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2007, 14:10 |
|
||
|
MQ подскажите архитектуру
|
|||
|---|---|---|---|
|
#18+
Все бы хорошо .... только как на счет каналов связи ? Бывают варианты и с кассовым аппаратом (вышел из строя) и т.д. С уважением, Вадим. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2007, 18:27 |
|
||
|
MQ подскажите архитектуру
|
|||
|---|---|---|---|
|
#18+
GVF112GVFВсе бы хорошо .... только как на счет каналов связи ? Я наверно не правильно выразился\меня не поняли. В магазине есть кассовый сервер. Его никто не собирается убирать. В случае обрыва связи - магазин работает. Нужен механизм, позволяющий отражать чеки с кассы в центральной базе. Чьлю это было не раз в день вечером а если связь есть то сразу, если связи нет, то копим в магазине чеки, появилась связь - передали в центр. Насколько я понимаю MQ как раз и занимаеться подобными задачами - обеспечение гарантированной и единоразовой доставки пакетов. Не понятно только где что должно стоять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2007, 18:46 |
|
||
|
MQ подскажите архитектуру
|
|||
|---|---|---|---|
|
#18+
В каждом магазине сервер MQ и MQ Server в центре. Можно в магазинах поставить MQ Server Express он дешевле (правда ограничено кол-во очередей в нем, но вам хватит) Только учтите MQ не волшебный инструмент. Если у вас допустим средний размер чека допустим 512 байт, а в магазине в день миллион чеков и канал 64-к, то MQ не сможет доставить все чеки в течение суток. Оценка следующая 6kb Sec * 3600 (кол-во секунд в часе) * 24 (кол-во часов в сутках) * 2 (кол-во чеков в килобайте) = 1036800 Так что просчитывайте все до малейших деталей, в том числе среднее и максимальное количество чеков в магазине их разер и каналы связи до магазина. Кстати кассовый сервер на чем работает (БД в смысле) ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2007, 08:55 |
|
||
|
MQ подскажите архитектуру
|
|||
|---|---|---|---|
|
#18+
2 IgorTv как Вы понимаете, на основании доступной здесь информации, можно только предлагать какие-то варианты и только. Итак, задача сводиться к тому, чтобы положить цеки из "кассовой" базы в МQ-сервер в центральный офис (как и принять накладную и положить ее в "кассовую" базу). Как минимум, на стороне кассы у Вас будет приложение (scheduler service) которое в одной транзакции должна промаркировать что чек положен в МQ-очередь (типа UPDATE Chek SET PoslanVGalvnijOfis='Y' WHERE id = 1, думаю необходимо, так как касса должна работать и без работующего МQ) и собственно положить чек в очередь, далее вся забота по передачи касса<->офис дозлагается на МQ2МQ. В данном случае, МQ выступает в роле координатора транзакций. Это вариант, где МQ сервер везде установлен (здесь Всеми и предлагалось) С другой стороны, наверное у Вас там не все Мегасторе магазины, есть и большие и express-маленькие (предполагаю) и смысл ставить везде сервер не совсем оправдивает по многим параметрам/ Тогда на стороне кассы можно использовать MQ Extended Transactional клиент. Но в этом случае, все будет работать как и прежде (скажем так), за исключением: клиент работает на прямую и используется внешний координатор транзакций (типа Microsoft DTS и т/д/)... Есть еще вариант с "простым" клиентом - то там одновремено работать с базой и МQ в одной транзакции неполучится. Опять, могу предполагатъ, что все ваши магазини можно разнести географически, типа север, юг, восток и запад. Выбратъ, какой-то один мега-магазин, там поставить МQ-сервера , настоить их с главним офисом. "Малыши"-магазины будут тогда работать с региональными серверами, а регионы с главним. При этом, ту же связь в дальнейшем можно улут'шать только в "больших" Короче, сперва надо знать и понимать Ваш бизнес и его перспективы/развитие, текушую инфраструктуру, технический персонал, да и тотже бюджет как и массу другой полезной информации необходимой для формулировки решений... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2007, 13:20 |
|
||
|
MQ подскажите архитектуру
|
|||
|---|---|---|---|
|
#18+
nkulikovВ каждом магазине сервер MQ и MQ Server в центре. Можно в магазинах поставить MQ Server Express он дешевле (правда ограничено кол-во очередей в нем, но вам хватит) Это я вроди уже понял. А поставить в магазине чтото типа MQ клиента нельзя? Чтоб в магазине было минимальное количество администрируемых вещей. nkulikov Если у вас допустим средний размер чека допустим 512 байт, а в магазине в день миллион чеков и канал 64-к, то MQ не сможет доставить все чеки в течение суток. Кстати кассовый сервер на чем работает (БД в смысле) ? У меня слава богу обувные магазины, так количество чеков идет на тысячи, а не на миллионы. Каналов хватит. Я надеюсь, что MQ не увеличивает трафик на порядки. Сейчас идет процесс переписывания магазинного софта на MSSQL вот я и хочу сразу прикрутить туда чтото, что обеспечт гнарантированную доставку пакетов, с возможностью организовывать какието пересылочные сервера на региональном уровне если понадобится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2007, 13:52 |
|
||
|
MQ подскажите архитектуру
|
|||
|---|---|---|---|
|
#18+
tipa resenie...2 IgorTv как Вы понимаете, на основании доступной здесь информации, можно только предлагать какие-то варианты и только. Итак, задача сводиться к тому, чтобы положить цеки из "кассовой" базы в МQ-сервер в центральный офис (как и принять накладную и положить ее в "кассовую" базу). Как минимум, на стороне кассы у Вас будет приложение (scheduler service) которое в одной транзакции должна промаркировать что чек положен в МQ-очередь (типа UPDATE Chek SET PoslanVGalvnijOfis='Y' WHERE id = 1, думаю необходимо, так как касса должна работать и без работующего МQ) и собственно положить чек в очередь, далее вся забота по передачи касса<->офис дозлагается на МQ2МQ. В данном случае, МQ выступает в роле координатора транзакций. Это вариант, где МQ сервер везде установлен (здесь Всеми и предлагалось) С этим понятно. Я примерно так себе это все и видел. Насколько тяжело будет поддерживать 50 MQ серверов в магазинах? Их нужно регулярно перезагружать? или еще какие неприятные вещи делать. Админов в каждом магазине нет. Хочется чегото такого, чтоб единажды настроенное работало вечно и не боялось ресетов по питанию и т.д. У меня есть вообще другой вариант. Коннектиться напрямсую в 50-ти SQL базам коннекторами типа JDBC. Но оно при нестабильной связи будут проблемы, да и 50 JDBC коннесторов ООООчень много памяти скушают :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2007, 14:03 |
|
||
|
MQ подскажите архитектуру
|
|||
|---|---|---|---|
|
#18+
2 IgorTv Nemogu izmerit/skazat "kak tjazelo" nuzno administrirovat 50 mq serverov. No vljubom sluchae samo-po-sebje ono rabotat' nebudet... Smotrite v storonu MQ Extended Transactional client + Microsoft Transaction Server (MTS)/COM+ (u vas naskol'ko ja ponjal tam windows server) + vasha baza (mssql). MQ server na kassu, dumaju, vi segda smozite postavit p.s. dumaju zjarja vi integriruete "ганарантированную доставку пакетов" v novij soft, tak kak pri sluchii nuzno budet updajtit ves' soft na kasah. proshe organizovat, imho, kak otdel'nij servis. offtop: u ms sql server 2005 est' tak nazivaemij Server Broker voobseto... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2007, 14:44 |
|
||
|
|

start [/forum/topic.php?fid=43&msg=34383439&tid=1604732]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
54ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
| others: | 249ms |
| total: | 391ms |

| 0 / 0 |
