Кейс:
- есть, допустим 4 приложения (A,B,C,D) с неким типизированным списком, например электронная очередь в магазине, или список автобусов в автопарке
- 4 (и более) приложения выполняются на разных компьютерах
- нет возможности использовать сервер или облако к которому все могут подключиться, есть доступ между A&B и B&C и C&D
- возможна ситуация когда, например B & C в данной цепочке - "серверы" разных отделов
задача: синхронизировать список в памяти между всеми приложениями со скоростью задержки до 3..4 сек

Существует ли подобное готовое решение?
как компонент для встройки в .NET Framework приложение.

вариации СУБД с их синхронизациями не подходят:
- по большей части слишком медленно
- тяжеловесно (должно работать и на тухлых клиентских машинах)

возможно кто-то подскажет как правильно гуглить на английском, вариации "sharing memory over network" не дают нужных результатов

все должны должны менять и у каждого еще своя база в которую все изменения должны записываться

похоже наиболее близкое что есть как nuget пакет это 'distributed cache'
Я в нескольких таких покопался, и там больше про надстройку над Caching Memory или Redis.

Получается, что и различные Cache managers, distributed caches и MassTransit это обертки над "промышленными" системами - Redis, MongoDB, RabbitMQ, ActiveMQ (облака в расчет не берем).

То есть писать свой компонент который что-то там в памяти будет синхронизировать между парой машин, это одно.
Если же такое решение пытаться масштабировать как по количеству узлов так и по нагрузке - то сделать что-то надежно работающее довольно проблематично. Соответственно за это не берутся, а если берутся то получив нагрузку и кучу граблей быстро снимают колеса с самописного велосипеда и переползают на что-то вроде Redis/RabbitMQ и обертки над ними, в которых уже разрешили проблемы связанные с синхронизацией.
Есть ошибки в рассуждении?

Возвращаясь к моей задаче, я правильно понял как должно выглядеть использование MassTransit? (приложенный рисунок)

сейчас дорабатывается велосипед с синхронизацией через WCF с callback
для синхронизации выбрана такая "стратегия":

- у каждого сервера есть как WCF "сервер" так и WCF "клиент"
- каждые два узла относятся друг к другу как мастер/слэйв
- один из серверов обозначается как primary мастер
- если сервер работает как слэйв, то поступившие запросы транслируются мастеру, то есть по сути слэйв это прокси к мастеру
- любое изменение данных транслируется на мастер и меняет таблицу в памяти на мастере
- после обновления на мастере, через callback всем рассылаются пакеты изменений, которые меняют таблицу в памяти слэйва и делают фикс в БД слэйва
- перед изменением записи (на мастере) берется блокировка, которую соответственно два клиента получить не могут
- если слэйв теряет подключение к мастеру, то он начинает выполнять команды у себя, то есть работать как мастер.

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

>>логическое информационное кольцо
у нас получается логическое информационное дерево )

текущие объемы микроскопические по меркам Redis/RabbitMQ, до 4х серверов в цепочке и до 5 клиентов на каждом.
нагрузка тоже микроскопическая, максимум 3..4 добавления/обновления в секунду. среднее - примерно 1 запрос на добавление/обновление в 2..4 минуты. по времени больше упираемся в сохранение на SQL сервере.
конечно у тех кто дальше всего от primary мастера заметно растут задержки
с дальнего конца цепочки, после добавления/обновления строки до появления изменений может до 3х секунд пройти (обычно 1..2сек), что конечно многовато но заказчика устраивает.
остались не до конца решенные грабли с разрывами связи.

подумал что может есть готовое решение которое не попало в поле зрения когда все это затевали

судя по всему вариант с RabbitMQ + MassTransit не сильно будет отличаться от WCF, без прослойки между table in memory и синхронизацией через очереди сообщений не обойтись. По сути это поменять "транспорт" с WCF на RabbitMQ.
Также нужно будет кого-то делать "главным сервером", чтоб одну запись не начали редактировать, и если не менять "стратегию" задержки будут вряд ли заметно меньше.

ок, а если все сотрудники 16-ти офисов перемещаются между 4-мя этажами и 16-ю офисами?
"распределенное решение" - понятие относительное
в одном случае может быть овердохрена нагрузка и нужен упор на масштабируемость, чтоб добавить в кубернетисе три ноды и оп... обрабатывалось 10к запросов в секунду, а стало 30к
в другом, каждый из 16-ти офисов работает со своим набором данных но нужно единое НСИ и начальство хочет "единую базу" чтоб смотреть репорты по всем,
в третьем случае 16 офисов работают с одним набором данных, и быстродействие должно быть примерно как когда несколько пользователей редактируют гугл док, правишь один абзац сам, и видишь как дописывается следующий другим пользователем, или это диспетчерская аэропорта и буквально в реалтайм нужно видеть как меняются данные.

и, как мне кажется, для этих трех примеров более оптимальны свои решения.
наверно для первого случая - "промышленные" решения - Redis/MongoDb/RabbitMQ и т.д.. а ещё лучше что-то облачное
для второго хватит и репликации основной СУБД.
для третьего, нужно что-то... типа гугл документов.


если я вас правильно понял то:
- если добавить в ваше уравнение условие что на тех узлах которые серверы, изменения нужно коммитить в БД и в таких случаях "смысловая обработка" будет выполняться почти всегда;
- с другой стороны, есть пакеты которые не фиксятся в БД, к примеру установка блокировки, они сразу транслируются, это очень быстро происходит, в вашей терминологии это "путь 2"
- циклический массив - это очередь видимо
- 3 потока не нужно, 2х достаточно инфопакеты получаются из калбека и сразу кладутся в одну или 2 очереди, одна на отсылку своим клиентам/наблюдателям, другой для модификации данных в памяти и коммита в БД
- получается сейчас все работает примерно как вы и написали.



если индус решает эту проблему уже 9-й год - его решение будет лучше моего )))

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

1. Сейчас вот понимаю, что большая проблема не в том чтоб синхронизировать данные в двух UI табличках в ОЗУ у пользователя, грабли в другом:
- а если в базу какого-то узла не удалась запись? таймаут/дедлок/FK руганулся... как это обработать чтоб для все кейсов было корректно?
- а если был разрыв связи, данные в базах рассинхронизировались, и нужно и как-то синхронизировать и чтоб пользователи не переставали работать
- а если был разрыв и сервера автономно поработали, пол дня к примеру? и могли по сути одинаковые записи создать... как всю эту хрень потом мержить?
- а если был разрыв, сам главный мастер не работал, и 2..3 ноды начали накатывать свои изменения одновременно?
то есть есть большие траблы с поддержанием синхронности данных и обработкой разрывов связи.
у меня все это тесно coupling и я ошибочно думал что если саму синхронизацию таблицы в памяти вынести то код станет в двое проще.
но наверно правильное распределение сложности - 15% синхронизация таблицы в памяти и 85% синхронизация данных в БД.

2. У программистов (у меня тоже) есть плохая черта не смотреть по сторонам а делать свои велосипеды потому что это банально может быть интересно, увидел задачу и вызов в ней, нырнул, не до конца поняв глубину проблемы. Можно к примеру сделать свою обертку на SQL или WCF запросом чтоб ловить специфичные ошибки и повторять запрос при дедлоках, но лучше бы разобраться и применить Polly.
Так что это не "морально гнобить") Нужно себя всегда перепроверять, я к примеру вот вопрос на форуме задал, какашек вроде ни кто особо не накидал)))

3. в моем случае, из того что я вынес из этого топика и накопал по наводкам, велосипед видимо оправдан:
- нужна почти реалтайм работа по общим данным всеми пользователями и автоматизацией, проблемы с масштабирование нагрузки нет
- надежных решений которым года 4 от роду, у которых 40К скачиваний на NuGet и которые возьмут на себя хотяб 60..70% проблем и будут внутри твоего exe - похоже что нет.
- использование близколежащих промышленных решений снимает 15% проблем, остальное останется, и что-то мне подсказывает задержки меньше не станут.
- есть MSSQL к которому мы привязаны, и доп СУБД (например Redis) или броккер RabbitMQ для того чтоб синхронизировать табличку выглядит громоздко, там ещё зависимости тянутся... тоже растет сложность но в другом месте. для развертывания, с одной стороны нужно просто скопировать папку и запустить exe, и можно тестить к примеру, с другой, набор дополнительных компонентов подтянуть и их настроить - это много более трудоемко.

видимо следствие долгой работы на удаленке без дебатов в курилке)))


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


Вы про WCF+callback? чем вам он не понравился?



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

Еще поток сознания )))



Хочется чтоб автоматически )))

Тема плавно перетекает в синхронизацию баз данных )

Проблему можно обобщить: большая вариативность ситуаций разрыва связи.
Она на минуту может пропасть, может на 10 минут, на день, а может копию запустили с пустой базой.
Эти случаи сложно однозначно детектировать а общий компромиссный алгоритм часто не самый удачный.

На сейчас лучшее что удалось придумать и заставить работать такое:
"Бизнес логика" выполняется на одном, остальные получают обновления.
Если связь к главному рвется, то копия становится мастером. При разрыве связи между офисами пользователи должны продолжить работу на своем сервере.

Когда связь восстанавливается, таблица "в памяти" для слэйва становится ReadOnly.
У меня можно четко разделить "оперативные данные" от исторических.
По этому после подключения слэйва к мастеру, таблица становится ReadOnly и в это время происходит синхронизация оперативных данных и таблиц от которых эти данные зависят.
Это не затрагивая "таблицу в памяти", только по иерархии зависимостей между таблицами. что-то вроде своей репликации.
"оперативных" записей порядка 300...400 (основной документ), для синхронизации я сперва в SQL формирую таблицы с хэшами, это по сути хоть и тяжелый но один запрос на каждый сервер, и обрабатываю только разницу.

После, оперативные данные уже синхронны и перечитываем таблицу из базы в память, и включаем синхронизацию через WCF.
и пользователи могут продолжить работу, данные и команды от внешних систем в это время копятся в таблицах-очередях.

если разрыв по времени был небольшой - то это секунд 15...30 занимает, если база вообще пустая - несколько минут.

через 5 минут после установления связи, когда прошла синхронизация оперативных данных, запускается фоновая синхронизация исторических данных в глубину на 1 месяц (с глубиной пока экспериментирую) и данных которые не требую online синхронизации.
такое действие может и пару часов занять.

получается, алгоритм на любое отключение и не оптимален, если разрыв был на 1 минуту, то можно синхронизировать быстрее (к примеру просто подтянуть последние Change пакеты за время разрыва, их может и не быть), а если база пустая - то bulk insert будет круче обработки "по документу" хоть и в несколько потоков.

и продумать сразу логику оказывается не просто, к тому что описал выше я не сразу пришел, только как у заказчика поставили стенды и получили реальные данные.

реальные данные = пока то что выдает автоматика, люди еще не начала использовать, и мне что-то подсказывает, что часть правил всплывет только тогда когда начнется тестовое эксплуатирование пользователями.

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

нужно улучшать, и для этого пока сделал задел:
- пропитываем в документах office owner, когда это можно делать;
- ведем историю удаленных записей, когда и на каком сервере (это уже в мержинге используется)
- пишу время работы каждого сервера, чтоб отлавливать когда он был выключен/выключен.
- в синхронизаторе SQL предусмотрел возможность разных политик (упрощенно):
* правильная запись - либо та у которой UpdateDate свежее, если равен - то правильная на мастере (активная политика на сейчас)
* правильная запись - у owner-а
* правильная запись у мастера, синхронизация для архива (делаем зеркало мастера)

надо бы ещё как-то для слэйвов в базу фиксировать когда подключен к мастеру, а когда был разрыв.

и вот это все нужно как-то в одно уравнение свести (


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




Вы еще ранее описали логику передачи пакетов, я пытаюсь это на реализацию спроецировать, и несколько зависаю...
- "циклический массив" с индивидуальным для клиента указателем и с тремя потоками без дуплексного канала звучит как реализация структур и моделей со сложностью заметно выше WCF+callback+ConcurrentQueue, поясните в чем профит? как это должно лечь на реализацию с WCF?
- информационное кольцо - подразумевает что сервера связанны кольцом или что пакет проходит по иерархии серверов к главному а потом результат обратно в виде инфо-пакета?
- "циклический массив" со своим указателем для каждого клиента, как он будет работать с учетом вариаций разрыва связи от пары секунд до нескольких дней?

Картинка с masstransit что я выше выкладывал помните? 2 крайние машины это клиенты, по середине - 2 сервера. подсистемы синхронизации между клиентом/сервером и между двумя серверами унифицированные.

условно 2 офиса, то есть две подсети внутри которых "клиенты" должны работать со своим сервером. если шагнуть немного вперед по времени, также в каждой подсети должен быть резервный сервер.
офисы территориально разнесены, между подсетями офисов канал связи который временами не работает. интернет не задействуется.
сети изолированы, только серваки друг друга видят.
мне кажется нормальная практика.

заказчику нужно решение чтоб сотрудники обоих "офисов" работали как в одном.

и что дешевле то? на один сервер всех завести? или вы про кластер на промышленных решениях?

админы там толковые, но похоже всех временами палками пугает служба безопасности )