Как правильно синхронизировать данные между клиентскими приложениями?

Question

[Леонид Рожнов]

Имеется серверное приложение, для производельности и непривязанности к наличию интернета, у клиентов стоят локальные копии с необходимым для работы клиента объемом данных. Клиенты работают с этими серверами, все изменения записываются в локальные БД, после чего, раз в 5 минут, через очередь RabbitMQ синхронизируются на основной сервер и получают ревизионно изменения с него.
Из важных деталей - у одного клиента может стоять сразу несколько локальных серверов, данные между ними синхронизируются через основной сервер. Ревизионность изменений реализована на уровне приложения, при открытии транзакции мы получаем из БД новую ревизию для этой транзакции, помечаем ей все измененные сущности, и сохраняем в БД.

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

И вроде как жили с ним, пока не стали появляться клиенты с 50-60 локальных серверов, данные с которых мы импортировать не успеваем. Да, сейчас мы их в каком-то виде ускорили, добавили кеширования и временно решили проблему, и есть еще запас, что можно улучшить в текущем решении (перейти на более оптимистичные блокировки например). Но, стали задаваться вопросом, возможно наш подход неправилен принципиально и мы городим костыли, когда есть более менее стандартное решение для этой проблемы?
В целом, нашли решение на уровне БД, которое нас вроде бы устроило бы и позволило не переписывать целиком наш механизм обмена данными (https://docs.microsoft.com/en-us/sql/relational-da... Но проблема в том, что в ближайший год планируем переход с MS SQL (да, из-за стоимости лицензий), и завязываться на его специфику не хотелось бы. Пока что планируем переход на PostgreSQL, но в целом готовы подумать о других альтернативах, если они позволили бы решить эту (и другие естественно) проблему проще. Возможно сможете посоветовать статьи/книги на эту тему, или кто-то сталкивался с такими проблемами и сможет описать в каком направлении нам стоит думать?

Answer 1

[Дмитрий Энтелис]

У вас из описания получается что версионность идет на уровне всей базы целиком, а не конкретных объектов?
Если не секрет, что именно за данные?
Про "тысячи штук" - это метафора, или поток записей действительно небольшой?

А как вообще в этой архитектуре вы разруливаете (планируете разруливать) перезапись данных даже без учета технических проблем?
Или данные такие, что клиенты не могут их перезаписать?

Тогда я бы смотрел все таки в сторону введения версионности по конкретным объектам, хоть это и тянет на "переписать все целиком"

Comments

[Леонид Рожнов]

Нет, видимо не совсем точно описал. Отдельные объекты естественно имеют свои собственные ревизии, и версионность идет именно на уровне отдельных объектов. Данные - это заказы клиентов, информация о самих клиентах и оплаты по ним.
Тысячи штук - нет, у нас есть логика "батчинга" обмена, все данные которые надо прогрузить между серверами у нас передаются пакетами по 5000 штук. Плюс, синхронизация каждые 5 минут сделана для того, чтобы данные не копились, а передавались оперативно небольшими пакетами. Периодически, после некоторых массовых операций синхронизируется 100-200 тыс. объектов, но все идет отдельными пакетами, пакеты между собой полностью изолированы и в целом не мешают работе системы. Размеры основной БД - примерно по 7млн записей в 10 основных таблицах.
Проблема наступает только когда параллельно такие пакеты пытаются просинхронизировать 30+ клиентов, и не успевают это сделать за таймауты, что вызывает накопление запросов в очередях.
На импорте отрабатывает достаточно много логики, в том числе валидации + констрейнты на уровне БД, если про технические проблемы - это про это.
Про "данные такие, что клиенты не могут их перезаписать" - не совсем понял вопрос, можно поподробнее, что имеется ввиду?

Версионность по конкретным объектам есть, проблема в том, как мы выдаем ревизии, это мы понимаем, что оно сделано "по историческим причинам", и должно быть переписано, собственно об этом и есть этот вопрос, в каком направлении переписывать. Пока что у нас есть видение только в сторону более мягких блокировок, но такое ощущение что мы делаем то, что и так по хорошему уже реализовано на уровне БД и это костыль.

[Дмитрий Энтелис]

Леонид Рожнов,
"данные такие что клиенты не могут их перезаписать" - ну например у вас есть база контрагентов.
менеджер Петя на локальном сервере А меняет контактный номер контрагента Рога и Копыта на 123456.
менеджер Вася на локальном сервере B меняет контактный номер контрагента Рога и Копыта на 654321.
Чьи данные в итоге попадут в центральную базу и будут раскатаны по всем серверам?
Если те, которыми последними пришли на центральный сервер - то есть риск потери информации.
Если те, которые были последними записаны на локальный сервер - то тут опять же получается что порядок будет гарантирован с точностью до точности синхронизации времени + усложняется логика обработки на центральном сервере.

Тут сложно что-то советовать, мне кажется что это не решается средствами БД в принципе, у вас вся логика в приложении ведь.

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

Меня вот эта фраза прям очень смущает. Это какой-то ну очень фундаментальный косяк архитектуры.
Кто у вас формирует ID ревизии? Судя по проблема она генерится вне транзации импорта, т.е транзации импорта получаются не блокируют друг к друга - отсюда и все проблемы.
Решение минимум: в самом конце импорта генерировать в транзации id ревизии С БЛОКИРОВКОЙ и записывать его. Т.е чтобы гарантированно пока вы не закомитетесь - никто id больше вашего не получил.

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

[Леонид Рожнов]

Насчет перезаписи данных - да, эту проблему считаем что решаем на логическом уровне приложением, это не проблема.

Насчет того, что ревизию (у нас это фактически просто bigint'ы из sequence'а SQL сейчас) проставляет приложение, а не БД - это знаем что косяк. Хотели от этого уйти в сторону ChangeTracking'а SQL сервера, но собираемся с него уходить. Так что хотим найти какое-то универсальное решение, по возможности не привязанное к БД, либо доступное в Postgre.
И да, сейчас транзакции импорта как раз блокируют друг друга, к этому решению нам пришлось прийти чтобы система работала стабильно, и работает оно неплохо, когда параллельно синхронизирующихся клиентов немного. Стало больше - стали ловить проблемы с тем, что эта блокировка - узкое место всей синхронизации данных. Решение снести проставление ревизии на "последний момент перед записью в БД", ровно как и делать его триггерами - тоже рассматривали, это сильно снижает вероятность возникновения проблемы, но у нас бывает такое, что именно коммит транзакции идет довольно долго, плюс, в пределах транзакции данные флашатся периодически, а не одним большим куском, что добавляет сложностей с этим. Увы, пока что думаем над решением.

[Дмитрий Энтелис]

Леонид Рожнов, ну а разбить транзакцию на 100500 мелких? ведь с точки зрения ux наверняка каждое редактирование атомарно - ну и комитьте его тоже отдельно. зачем тут огромная транзакция?

[Леонид Рожнов]

Ну, в целом можно считать да, хотя каждая транзакция это зачастую не одна изменяемая сущность, а десяток (состояние счета, лог аудита, свойства клиента иногда, задания на рассылки нотификаций) и опять же, даже эти маленькие транзакции надо ведь гарантированно синхронизировать между собой, нельзя ведь просто положиться на то, что «изменения атомарно и точно не будут записываться в БД параллельно с непредсказуемым итоговым порядком

Answer 2

[xmoonlight]

Если у Вас есть синхронизация на клиенте, то следует различать работу с базой и модификацию базы:
1. Работа - это SELECT.
2. Модификация - это всё остальное.

При модификации: считайте логическую "разницу" между текущей и модифицированной локальной базой и сохраняйте в отложенный стек модифицирующих запросов (для запуска на центральной БД после отправки).

Пример: Добавили запись и тут же её удалили - "разница" значимых данных равна нулю. Изменений в модифицирующих запросах - нет.

После появления сети (или по тайм-ауту) - отправляйте все модифицирующие запросы на сервер центральной БД для их последующего запуска там.

Перед модификацией очередных данных - проверяйте сразу конфликты между всеми клиентами (пришедшими стеками). При конфликте - берите стек самого последнего (нового по timestamp) клиента с модификацией этих данных.

Т.е., Вам нужно построить систему разбора запросов синхронизации с клиентов на сервере с поиском пересечений и построением корректной очереди для их исполнения в правильном порядке.

Comments

[Леонид Рожнов]

Так, давайте на примере расскажу как у нас происходит работа.
Есть некоторые счета. Возьмём 2 счёта, А и Б на которых в начале лежат 100 рублей. И есть 3 сервера. Наш основной, стоящий у нас. И 2 «клиентских», опять же, сервера наши, но стоят лояльно у клиентов.
T0: на всех трёх серверах, есть оба счета, их балансы 100, ревизия обоих счетов 1 (изменены оба были в рамках одной транзакции) её считают последней все сервера.
Т1: на обоих клиентских серверах (К1 и К2) происходят операции с счетами . На К1 пополняют А на 20, на другом с Б списывают 10. Они создают у себя транзакции вида «баланс такой-то изменён на Х рублей» и готовят их к экспорту.
Т2: Для К1 настало время синхронизации, он выгружает данные на главный сервер (пусть будет М). М принимает все транзакции с него (включая баланс А изменён на 20 рублей) и начинает обрабатывать. При этом он достаёт из БД ревизию 2 и помечает все изменённые данные ей для сохраннния. Данных много, обрабатывает он их скажем 30 секунд, это время К1 ждёт ответа.
Т2: данные решает синхронизировать К2. У него только одна транзакция списания, М берет из БД ревизию 3 и присваивает обновлённому состоянию счета Б, с балансом 90, и считаем что сразу коммитит данные в БД. Тут же собирает ответные данные для К2, со всеми даннными с ревизией больше 1, туда попадает только счёт Б( поскольку пакет от К1 завис на коммите из-за блокировок в БД например), данные отправляются на К2, он их сохраняет и работает.
Т3: заканчивается импорт данных с К1, данные сохраняются в БД, для К1 отправляются все данные с ревизией больше 1, оба счета уходят корректно.
Теперь состояние системы:
Главный сервер: счёт А 120р, счёт Б 90р., последняя ревизия 3
К1: счёт А 120р, счёт Б 90р, ревизия 3
К2: счёт А 100р, счёт Б 90р, ревизия 3.

Данные по изменению счета А не попали на К2, так как ревизия у них меньше чем была последняя актуальная на момент завершения коммита транзакции в БД.

Сейчас решаем проблему тем, что на время всего импорта берём на М блокировку на родительский объект, объединяющий К1 и К2 ( по сути на все данные с которыми они работают) и Т3 гарантировано заканчивается до Т2.
Это начало работать плохо, когда вместо 2 дочерних серверов их стало 50 с одним набором данных и любой импорт дольше 6 секунд стал приводить к накоплению очереди запросов.

[Леонид Рожнов]

Ещё важное замечание: весь импорт с К серверов проходит в рамках одной транзакции БД, чтобы избежать неконсистентности данных в любой момент времени

[xmoonlight]

Леонид Рожнов, тогда синхронизируйте во время импорта локальную базу (клиентскую) с удалённой, удалённую в этот момент - блокируйте (ставьте на паузу) на обновление синхронизируемых данных.
После синхронизации локальной - пересчитывайте на клиенте все операции обновления на новые и сразу же отправляйте на удалённую (центральную) базу.
После успешной отправки и синхронизации на удалённой БД - снимайте блокировку на удалённой БД.
Т.е. нужно, чтобы был виртуальный пул транзакций на локальной БД, который потом приводится к реальной разнице между текущим состоянием этого пула и реальной удалённой БД и затем синхронизируется.

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

[Леонид Рожнов]

xmoonlight, Что мы собственно сейчас и делаем, блокируем синхронизацию так, что по данным одного клиента одновременно идет импорт/экспорт только с одного удаленного сервера. И все остальные удаленные сервера ждут своей очереди на синхронизацию. Их много - очередь растет, синхронизация не успевает проходить за таймауты. Увеличение таймаутов/снижение частоты синхронизации = деградация доступности, которой мы хотим избежать.

[xmoonlight]

Леонид Рожнов, почему только с одного? один клиент может изменять сразу все данные в базе?!

[Леонид Рожнов]

xmoonlight, ну, в пределах одной достаточно большой секции, доступной этой группе локальных серверов - да. Или я может неправильно мысль понял? А можно на небольшом примере пожалуйста?

[xmoonlight]

Леонид Рожнов, ну тут всё просто:
Любые ячейки любой одной или нескольких записей: A и B
1. Клиент 1 Сервер 1: A=1
2. Клиент 1 Сервер 2: A=A+20
3. Клиент 1 Сервер 1: B=B+10
4. Клиент 1 Сервер 2: B=5
5. Клиент 1 Сервер 1: B=A+B

Здесь видно, что значения переменных A и B не влияют друг на друга.
Поэтому транзакции 1 и 2 могут выполняться одновременно с 3 и 4.

А уже 5-ая - зависимая от результата предыдущих 4-ёх и может исполняться только после того, как будут выполнены все от 1 до 4.

Вот это - Вам нужно оптимизировать, чтобы иметь возможность обработки независимых данных в приоритетном режиме.