Кто поднимал на 1С:Рознице такое количество узлов (от 100), откликнитесь! С чем столкнулись, как победили блокировки узлов? Как часто происходит обмен, какой регламент в магазине?

что за блокировка узлов?

(1) Ошибка при чтении изменений при обмене РИБ:  Ошибка при вызове метода контекста (ПрочитатьИзменения): Конфликт блокировок при выполнении транзакции

ПланыОбмена.ПрочитатьИзменения(ЧтениеСообщения, СтруктураНастроекОбменаДанными.КоличествоЭлементовВТранзакцииНаЗагрузкуДанных);

Если не требуется оперативные остатки центрального склада то какие проблеммы могут тут быть.

Вопщем опиши предпологаемую структуру предприятия.

(0) У меня на клюшках 97 в разных часовых поясах

дык ето же просто конфликт блокировки таблиц, причем здесь количество магазинов?

(2) делай обмен чаще

(5) когда центр делает без передыху обмен с 100 узлами - блокируются таблицы изменений. и обмен выполняется пооереди

(6)тогда надо делать реже, ночью например. За ночь то можно провести все нужные обмены

(7) если делать часто - пакеты будут маленькие, обмен будет проходить быстро. а привязываться к ночи - слишком низкая оперативность, не всех устроит

Конфигурация 1С:Розница 1.0.
Один центральный узел в офисе клиент-сервер и 150 подчиненных узлов - файловые версии, подчиненные узлы в свою очередь также выступают центральными для касс магазина (2-8 касс). Оперативные остатки не требуются - в центральной итоги по регистрам можно вообще отключить.
Центральный узел розницы в свою очередь связан с корпоративной ИБ.
Мы пока что столкнулись с блокировками (2)

сейчас порядка 50 магазинов, обмен каждый час идет.

Сделайте деревом
1 центр. 10 промежуточных. у кажой промежуточных по 10 магазинов.
можно меньше/больше промежуточных

(11) и нанять еще 10 программистов или сисадминов!

(0) решение есть, но потребуется уйти от типового РИБа.

(12) зачем. Промежуточные - автономны. И помогают как раз избегать избыточных блокировок, т.к. в очереди не такое количество обменов.
Можно остановиться в вашем варианте на 3 промежточных по 50 магазинов.
Советую не по собственному - к сожалению опыту а по тому что есть такие варианты =)

(14) этот вариант рассматривался - при этом хочешь не хочешь возникают затраты времени на обслуживание этих узлов, хотя бы тот же бэкап, увеличивается время прохождения информации

(13) обмен текстовичками?

а перевод на управляемый режим блокировок не спасает случаем?

(16) Нет не поможет, делайте чаще, в чем проблема? или у вас спутник раз в час пролетает над магазином?)

(дурацкое, но решение) Риб-база на 152 узла: 150(магазины) + 1(для юзверей ЦУ) и центральный узел - только для обмена. Ну и для обновления конфигурации, естественно.

(17) у вас крутится 150 магазинов? сталкивались с тем, что бывает, когда магазин забил на обмен, а потом по звонку из центра его включает и вываливает всю накопленную кучу изменений?
(18) именно такое и нужно, параллельность обменов только подкачала.

(19)это организационный момент, с тем что магазин забил на обмен никогда не сталкивался так как обмен обычно автоматизирован.С проблемами технического характера да, но это единичные случаи

бери по 300 руб за магазин, по предварительным расчетам, озолотишься, правда, я еще не умножал сам, но предполагаю.

Гланое, бери заранее и убегай, а то с этими обменами заколебешься.

(21) 300*150 = 45000 - это называется озолотится? :) мелко живете товарищ

(22) а ты, математик !

О промежуточных узлах (по опыту) согласен

(19) ТС, а никакой "параллейности" обменов и не надо - этого не требуется.

Допустим, в 12-00, все магазины начинают выгружать в общую директорию свои сообщения обмена.

Центральный узел, последовательно, загружает эти сообщения от всех узлов и потом выгружает, также последовательно, сообщения обмен для узлов.
В 12-30, например, все магазины начинают принимать сообщения обмена...

Взаимные обмены с каждым узлом есть? Есть. Что ещё надо? :)

(25) мне бы еще программу лояльности... с картами накопительными там, с обновлением данных в течении часа... а еще хотелось бы, чтобы данные об отгруженном на складе товаре приходили чуть раньше, чем доедет товар до магазина...

(25) Хочу себе такой обмен, чтобы за полчаса 150 баз загрузилось. Правда это явно не на 1С будет сделано

В среднем на загрузку примерно минуты 3-4 будет уходить (обмен это же не только записать изменения, это скачать файлик распаковать, прочитать его записать изменения, зарегистрировать изменения для остальных 149 магазинов) Т.е. на 150 магазинов будет уходить порядка 10 часов только на загрузку. И еще минимум часов 5 на выгрузку. . Т.е. по факту полный цикл в идиале будет занимать 12 часов. Ну и толку что магазин будет выгружать каждые 5 минут, если центр физически не сможет это прожувать?

Даже если предположить 2 минуты на загрузку и выгрузку, то это всё равно выходит 5 часов. т.е. по факту 2 раза в день

(26) Нет сынок это фантастика.

Переходи на сап. Там нет такого понятия как УРИБ, потому что считается что все данные должны находится в одной базе. А значит это автоматически решает твою проблему с обменом :)

обмен данными в среднем занимает от 4 секунд до 1 минуты, в среднем - 20 секунд на один узел

(27) Делал так называемый "непрырывный" обмен: это когда постоянно сканируется директория на предмет появления файла обмена. И сеанс обмена - как только появляется файл обмена. "Сеанс обмена" - это загрузка и выгрузка сообщений.

"Скорость" сеанса обмена "в среднем" - от5 до 20 сек.

(30) На один узел. Т.е. час на весь цикл

Недостаточно? Тогда двух-трех уровневая структура риб (ЦУ-магазины-кассы)

Тьфу, неверно сказал: ЦУ - двух-трехуровневая риб-база.

(33) в (15) про это расписал

(33) я это выше и предлогал.
Но повидимому сеть уже работает как есть. и чтоб перенастроиться нужно дофига времени затратить.
по этому (0) ищет решение для сущестующей мдели 1к150.
Тут помоему моно только качнуть железо попробовать.. + виртуальный деск находящийся в памяти для папки обмена....

(0) у вас что типовая Розница? и работает уже на 50 точках с ежечасовым обменом? жесть. На таких объемах ритейлу нет смысла ставить 1с на фронт, очень много геморроя и доработок.

(27)не факт что на входе будут пакеты от всех 150 баз

(13) какая 1с:Розница? Там вроде уже тогда делали упр блокировки.
Если отключаете итоги по регистрам - это плюс для обменов.
Если нет упр блокировок, то конечно их нужно включить и доработать конфигурацию под работу. Но! можно включить разделение итогов, так как при обмене не требуется делать исключительные блокировки. Далее можно делать одновременно несколько загрузок с разных узлов.
Это то, что легко сделать. Далее нужно переписывать саму логику РИБ обмена.

(0) по опыту могу сказать, загружать из 150 или даже 200 узлов в одну не рабочую базу можно "легко" и только средствами платформы.

У меня 96 магазинов, была такая же проблема, решил 3х уровневым РИБ. Сейчас схема 1-2-50. Проблем нет!

на обмен уходит 30 мин

пишите шину esb

(42) да чего уж там шину esb, надо замахнуться сразу на 3С (1С -есть, 2С - не понятно как живет) с блэкджеком и шлюхами, куда же без них

Конфу в любом случае нужно допиливать, на старой работе узлов было гораздо больше, чем 150, но и Розница 1.0 была до неузнаваемости переписана. Разделяли по планам обмена справочники и оперативные документы с магазинов, оптимизировали регистрацию изменений и формирование пакетов, переводили на упр блокировки. Движения по регистрам в ЦБ не передавались. Обмен через WS. Периферийные базы обращаются за изменениями с произвольным интервалом от 10 до 20 минут. В общем работы было много :)

(44) тоже кстати над этим думали, разделить на несколько частей план обмена и про WS думали, кстати, через WS гоняли стандартные выгрузки РИБа или свое навешивали?

(44) а можно подробнее про обмен через ws? а то не понятно как его делать и соблюдать целостность базы..

(45) розница переписана и оптимизирована под нас. запускайте замеры и убивайте не нужный код. там реально много чего лишнего занимает 70-80% времени.

(46) на сервере с ЦБ запущен веб-сервис, который управляет раздачей пакетов, т.е. обращение к WS с периферии происходит. Веб-сервис Рарус делал.
Кстати, еще оч рекомендую обратить внимание на процедуру регистрации изменений, чтобы параметр Данные был всегда заполнен, иначе может возникнуть ситуация, когда регаются все объекты. Столкнувшись с этой проблемой, далеко не сразу нашли косяк, внешне все выглядело хорошо, все параметры есть, но в итоге была обнаружена ситуация, когда у переменной было значение Неопределено.

И еще как мера - в ЦБ только обмены, пользователей не пускать.
Также необходимо разработать систему мониторинга за производительностью и обменами. Чтобы можно было оперативно определить стоят обмены или работают.

(48) да вот на этот веб сервис то как раз и глянуть бы..

(50) БСП последнюю посмотри, там обмены должны быть реализованы на уровне WS

(51) БСП 2 точно умеет

(51) (52) спс