КМК - это аббревиатура "как мне кажется".
Случай а), кмк, не имеет смысла. Если между серверами кластера нет быстрой и устойчивой связи - надо перепланировать структуру, а не включать в один кластер серверы в калининграде и владивостоке.
Пункт 1 решается админами комплексно; все остальные выполняются наличием базы блокировок внутри кластера (на каждом сервере). Ну или - выделенный кластер для базы блокировок (либо смежный кластер, на который её можно впихнуть): тогда это будет "централизованное место" для блокировок с резервированием.
Отталкиваться надо от структуры своей сети (при выборе внутри- вне- кластерная блокировка) и от стандартов кодирования (при выборе технологии: sql, html, nrpc - не принципиально ни разу). Например, если есть доступ на общий для всех серверов и отказоустойчивый скл - то просто табличку в ём запилить для блокировок...

 

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

Например 2 пользователя одновременно пытаются создать документ с ключом ххх подключившись к кластерному серверу А
А другие 2 пользователя одновременно пытаются создать документ с тем же ключом xxx подключившись к кластерному серверу Б

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

И какие допущения нужно принять.

 

Хм, ну проще (и быстрее) всего воспользоваться темой с юнидами (выше писали). Сервер сам проверит, есть ли док с таким юнидом, а второго не даст создать (окурки тоже считаются). Да, встанет технический вопрос с освобождением блокировки: придётся либо явно удалять документ со всех серверов кластера (без окурка), либо хранить в документе признак "занят/свободен" и чистить по расписанию. Зато - быстро и без потенциальных проблем с видами.
Если два юзера открывают для правки один док на одном сервере, то кто-то станет первым. Если на разных серверах кластера - то остаётся надеяться на кластерную репликацию и на маловероятность варианта "кластер не успел отреплицировать блокировку с сервера А, а на Б уже пользователь создал альтернативную блокировку"... Ну или, опять же, особо проверять наличие блокировки на всех серверах кластера. Вопрос технический, кмк - сделать можно.

С единой точкой блокировок возникает принципиальное противоречие: либо единство, либо отказозащищённость В идеале, наверное, я бы предложил маленький скл-сервер на кластере уровня ОС (если таковой у кого-то имеется). Ну или собрать такой кластер из двух линуховых десктопов

 

С единой точкой блокировок возникает принципиальное противоречие: либо единство, либо отказозащищённость В идеале, наверное, я бы предложил маленький скл-сервер на кластере уровня ОС (если таковой у кого-то имеется). Ну или собрать такой кластер из двух линуховых десктопов

MQ-кластер / sql-кластер + java-back (optional) + nginx в режиме failower.
Если два сервера откажут - ой, поэтому они на разных площадках должны быть.

 

Если сервер блокировок в кластере
Почитав ваши предложения пришел к мысли, что надо опираться на допущения:
1. Канал связи между серверами в кластере должен работать идеально.
2. Один из серверов должен быть главным

Тогда пользователь обращается на сервер А - главный, если сервер или канал к этому серверу лежат, то его перекидывает на сервер Б. Сервер Б проверяет, доступен ли сервер А по каналу между серверами, если доступен - создает/проверяет блокировку на сервере А, если нет - значит считает что сервер А лежит и создает/проверяет блокировку на сервере Б.

Ну а сами блокировки реплятся между серверами пока они работают.

Наверное так, что думаете?

 

"Один из серверов должен быть главным" - нет, это не моя мысль. Мне нравится равноправность серверов в кластере, сколько бы их ни было. Ваша схема тоже рабочая, но выделение "главных" серверов на практике не очень удобно (на примере компани-медиа - пока всё работает, всё ок, но когда начинается движуха с серверами, легко провафлить изменение настроек).
Мне кажется, есть 2 варианта: более быстрый и простой, но менее надёжный ("базовый") - когда мы полагаемся на кластерную репликацию. Тогда да, "Канал связи между серверами в кластере должен работать идеально", иначе начнутся проблемы блокировок (пропорциональные плотности работы пользователей и степени тормознутости класт.репл.). В процессе "блокировки реплятся между серверами" и база на любом сервере полагает, что можно доверять блокировкам на своём сервере. И да, скорее всего для обычного сэд этого хватит (но я ТЗ не читал, так что это не точно))
Или более сложный и менее быстрый, но более надёжный ("замороченный") - когда мы готовы к косякам кластера и код блокирования документа сам проверяет наличие блокировок на других серверах. Тогда мы сможем гарантировать отсутствие ложных разрешений на правку документа вне зависимости от состояния кластерной репликации, вплоть до её отсутствия; заплатив за это скоростью.
Как подвариант "замороченного" - Ваша идея с условным "главным" сервером блокировок, который при недоступности заменяется соседями по кластеру в каком-либо порядке. Но это опять же кодить руками придётся.
Выбор заказчика

 

Штатный домино кластер на раз даст создать 2 дока на серверах разными пользователя с одни унидом. Там нет блокировок как в субд в ружиме мультимастер.
Не нужно иметь всегда 2 активных сервера блокировок - достаточно доступа на 1, второй - в горячем резерве.
Через http + nginx перекл на горячий резерв делается легко и просто.
Разрушение кластера - это форс мажор.
Для терр разнесеных систем все сложнее ...

 

Если рухнет - заводят тикет в тп, тп разбирается и разблокирует.
Тикетов в месяц таких довольно мало, программы работают стабильно.

Причем большей частью обращаются те, у кого что то рухнуло. Заодно и выясняем и ликвидируем причину, чтобы не рушилось потом.
Думаю как то апгрейдить скрипт блокировки, чтобы пользователь на одном и том же устройстве после перезагрузки лотуса после падения мог бы заблокировать документ который был заблокирован им до падения.
Тут надо придумать, либо в нотес ини сгенерить пользователю уникальный ключик и потом писать его в док блокировки, либо в нотес ини писать/стирать униды блокируемых доков.
Наверное первый вариант универсальнее.

Если БП позволяет тратить время на тикеты то можно и не рефрешить лок. Но в моей практике такой роскоши еще не было )

 

Штатный домино кластер на раз даст создать 2 дока на серверах разными пользователя с одни унидом

Это как он даст, если созданный на одном сервере док уже приехал на второй? если кластерную репликацию остановить, это уже форсмажор. А вероятность попасть в зазор репликаций - есть, но небольшая.

Не нужно иметь всегда 2 активных сервера блокировок

В базовом варианте вообще не нужно иметь особый "сервер блокировок" - члены кластеры сами справятся) тут плюс как раз в простоте.

Для терр разнесеных систем все сложнее

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

 

Это как он даст, если созданный на одном сервере док уже приехал на второй? если кластерную репликацию остановить, это уже форсмажор. А вероятность попасть в зазор репликаций - есть, но небольшая.

В базовом варианте вообще не нужно иметь особый "сервер блокировок" - члены кластеры сами справятся) тут плюс как раз в простоте.

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

Попадания в зазор на практике оказалась весьма частым явлением
Если смотреть теоретически -Для определения “зазора“ можно глянуть статистику класт репликатора. Там более все наглядно...

Со всем остальным конечно же согласен.

 

Попадания в зазор на практике оказалась весьма частым явлением
Если смотреть теоретически -Для определения “зазора“ можно глянуть статистику класт репликатора. Там более все наглядно...

Со всем остальным конечно же согласен.

Соглашусь с тобой и разойдёмся довольные друг другом)) может кластерных репликаторов придётся побольше запустить, если тормозит - вроде мне помогло недавно, были вопросы по синхронизации реплик кластера, а потом кончились.

 

У меня не было проблем вызвать другой сервер. Не очень понятно откуда увеличение времени на блокировку, за какое время происходит блокировка, в милисекундах?

У меня тоже не было проблем вызвать. Но были проблемы с доступностью - либо возвращалась ошибка подключения, либо блокировка происходила, но через полторы МИНУТЫ, когда документ несколько раз уже мог быть заблокирован/разблокирован другими процессами, что в итоге вылазит конфликтами. Поэтому вариант подключения к другому серверу я не рассматриваю практически никогда ввиду его ненадёжности.

 

2) Нужна единая блокировка на нескольких кластерах? а зачем, собсно? и сколько у вас кластеров, в чём проблема растиражировать "внутрикластерное" решение?
Для блокировок в пределах кластера - кмк, это нормальное ограничение - вполне достаточно базы с блокировками, как собсно все и делают. Это и есть централизованное место, надёжное как сам кластер
...
В общем, проблема кажется несколько надуманной

Внурикластерное решение есть и работает 2 десятка лет лет. Оно ненадёжное. Даже в условиях нахождения серверов кластера в одной стойке бывают случаи затыка кластерной репликации до полу-минуты. Это не надуманно, а из опыта.

 

Ну у нас сделана кнопка "Заблокировать", после чего документ переоткрывается и доступны действия с заблокированным документом. По выходу - разблокируется.

Если рухнет - заводят тикет в тп, тп разбирается и разблокирует.
Тикетов в месяц таких довольно мало, программы работают стабильно.

У нас тоже есть база типа "Конфликт-менеджер", в которой люди сидят и сравнивают документы по полям, решая конфликты.
После того, как у меня уже была реализована полностью бесконфликтная система, то такие решения воспринимаются не то чтобы даже несерьёзно, а ежедневно вызывают боль... Отсюда и желания: никаких ручных "Заблокировать/Разблокировать", только работа невидимо для пользователя + система в принципе не позволяющая создавать конфликты. Такая система, повторюсь, уже была сделана, но там в доке прописывался сервер, на котором происходит блокировка/разблокировка и все внесения изменений в него.
Распределённое внесение изменений (данная тема) - эта идея возникла из-за того, что основная активная работа с документом может происходить, во-1 - на разных кластерах, а во-2 - небольшой часто статический (известный) период времени, т.о. помимо данного периода нет смысла блокировать документы и зазря увеличивать накладные расходы на транспорт.

 

Если два юзера открывают для правки один док на одном сервере, то кто-то станет первым. Если на разных серверах кластера - то остаётся надеяться на кластерную репликацию и на маловероятность варианта "кластер не успел отреплицировать блокировку с сервера А, а на Б уже пользователь создал альтернативную блокировку"... Ну или, опять же, особо проверять наличие блокировки на всех серверах кластера. Вопрос технический, кмк - сделать можно.

В том-то и дело, что надеемся, а надеяться не хочется. Потому и возникла данная тема.
Потому и мысль - блокировка по http, чтобы исключить трудоёмкие и ненадёжные (межсерверная связь по nrpc) операции.

 

В том-то и дело, что надеемся, а надеяться не хочется. Потому и возникла данная тема.
Потому и мысль - блокировка по http, чтобы исключить трудоёмкие и ненадёжные (межсерверная связь по nrpc) операции.

Говорил и повторю, что я не знаю, в каком контексте возникла тема (сколько у вас кластеров, где они, какие документы, сколько их, как часто меняются и тд), поэтому просто перечисляю возможные варианты, как их вижу. Я даже не знаю, вы с Gandliar одна шайка или нет

Если для каких-то кейсов не годится "базовый" вариант (то есть плотность изменения документов высокая, а наладить кластерную репликацию некому) - ну проверяй все серверы кластера на наличие блокировки, а не только текущий, в чём проблема-то? Ясно же, что за надёжность надо платить.

"у меня уже была реализована полностью бесконфликтная система" - ну так опиши её, может и пригодится кому. Может и мне)

И насчёт противопоставления http vs nrpc - а откуда данные про "трудоёмкие и ненадёжные" операции? реально хппт-запрос к домине быстрее, чем аналогичный нрпц?
"были проблемы с доступностью" - ну у всех были проблемы с хттп, нет причин на него смотреть как на волшебную палочку А полторы минуты на создание документа в базе - это инфраструкурная проблема. Или виды тормозят (если это время вместе с поиском существующей блокировки), или база в целом; в любом случае, доступ к такой базе по хттп быстрее не будет. Кстати, не во всех конторах есть прямой доступ на домино по 80 или (тем более) нестандартным портам (это к вопросу о sql).

 

"у меня уже была реализована полностью бесконфликтная система" - ну так опиши её, может и пригодится кому. Может и мне)

Уже давно здесь на форуме всё подробно было расписано.

 

Уже давно здесь на форуме всё подробно было расписано.

Вспомнилось.
Лежат зеки на нарах после отбоя. Вдруг из одного угла слышится: 27.
Вся камера: бу-га-га! Из другого угла: 34. Камера опять ржет.
Новенький зек спрашивает у лежащего рядом старожила: А че это за цифры из-за которых все в камере смеются?
Старый отвечает: Понимаешь, кореш, давно тут сидим, все анекдоты уже рассказали и, чтобы не повторять каждый раз, присвоили им номера. Называет кто-то номер анекдота, а все остальные вспоминают и смеются.
Новенький на всю камеру: 17. Тишина, никто не смеётся.
Он опять к старожилу: А что анекдот под №17 не смешной?
Старожил: Понимаешь, анекдот то смешной, просто есть люди которые умеют анекдоты рассказывать, а есть те которые не умеют!

 

@Mikle_GB
Длинная история)

По 17-му анекдоту уже не посмеёмся, т.к. видать IdeaJam навернулся... потому расписал как смог. Если нужны подробности по каждой из проблем, что я тут выше описывал - поиск по форуму по слову "блокировка" и автору.