Репликация данных: с чего бы начать ознакомление?

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

С чего мне стоит начать знакомство?

С основ программирования, алгоритмов и CS. К СУБД это имеет очень далёкое отношение.

А нет ли каких-нибудь статеек, где разбиралась бы синхронизация на конкретном примере? Типа, «в такой-то CRMке синхронизация происходила так, так и так»?

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

посмотри rsync

Да чёрт с ним, с готовым решением. Мне бы хоть принцип понять.

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

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

Соответственно, если задача не принадлежит данному исполнителю, то он её и не может удалить.

Допустим, у тебя программисты делают тикеты. Труд программиста стоит 50 долларов в час. Два программиста забрали один и тот же тикет и делают его одновременно. Они его оба сделали независимо друг от друга сидя на пляже в офлайне и потратив по 10 часов, и ты попал на 500 долларов. Такого быть просто не должно.

Конечно, и при правильно построенном деле могут быть проблемы, потому что есть администратор, который может отменять задачи «поверх голов». И тогда действительно, пользователь придёт из офлайна и будет конфликт слияния. Но это не совсем то же, что «произвольное слияние произвольных данных в произвольной анархии».

P.S. организуя конвейеры и назначая ответственного, ты превращаешь «двустороннюю синхронизацию» в «одностороннюю», где есть определённый источник и приёмник изменений в каждом случае. Это намного облегчает ситуацию.

Но на самом деле тут есть грабли - справочник товаров. Если у тебя распределённые закупки, могут возникать дубликаты товаров - их действительно придётся сливать. Причём часто оказывается так, что сливать можно только вручную. И, самое печальное, при подсоединении клиента возникает двунаправленная синхронизация между тем, что понабивал твой клиент и тем, что понабивали/понасливали в центральной БД другие пользователи. Здесь и правда может понадобиться городить сложный огород, но поскольку я такую задачу не решал и пора уже спать, то ничего больше не напишу. У меня до такого счастья не доходило, работа была построена так, что все новые товары возникали в одном месте в онлайне.

Если бы это было правдой, git merge был бы не нужен :) Мы же не знаем, какая у ТСа задача, а бизнес-логика всякая бывает. На то он и бизнес, чтобы иногда быть нелогичным, если это приносит больше денег :)

На то он и бизнес, чтобы иногда быть нелогичным, если это приносит больше денег :)

И какой у тебя бизнес в git merge?

Почитай про two generals problem, Paxos, векторное время.

Анекдот:

Встречает Волк в лесу Красную Шапочку и говорит:
– Ну что ж, Шапка, я вижу два варианта развития событий: либо слияние, либо поглощение.

Синхронизировать действия из нескольких приложения - задача очень непростая.

http://swarmjs.github.io/ - попробуй в этом разобраться и поищи у них еще видео на ютюбе.

Погугли Operational Transformations. И https://github.com/josephg/ShareJS

swarmjs построен на более продвинутой теории, но он уже пару лет в состоянии «скоро будет». Если кратно - готовых решений без побочных эффектов вообще ни у кого пока нет.