Блокировка документов по http (?)

[Mikle_GB]

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

 

[Gandliar]

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

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

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

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

 

[Mikle_GB]

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

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

 

[savl]

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

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

 

[Gandliar]

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

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

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

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

 

[Mikle_GB]

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

 

[rinsk]

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

 

[rinsk]

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

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

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

 

[Mikle_GB]

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

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

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

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

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

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

 

[rinsk]

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

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

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

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

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

 

[Mikle_GB]

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

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

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

 

[VladSh]

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

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

 

[VladSh]

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

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

 

[VladSh]

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

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

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

 

[VladSh]

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

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

 

[Mikle_GB]

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

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

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

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

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

 

[VladSh]

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

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

 

[Mikle_GB]

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

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

 

[VladSh]

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

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