Вам бонус- начислено 1 монета за дневную активность. Сейчас у вас 1 монета

Организация синхронизации данных клиент-сервер для мобильного приложения кратко

Лекция



Привет, Вы узнаете о том , что такое организация синхронизации данных, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое организация синхронизации данных, клиент-сервер для мобильного приложения , настоятельно рекомендую прочитать все из категории Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL.

Имеется клиент и сервер. Сейчас каждый хранит свои данные, которые внесены отдельно на клиент и отдельно на сервер.
Данные могут создаваться/изменяться/удаляться на клиенте и на сервере.

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

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

Как реализовать подобную схему синхронизации?
Что для этого нужно?

Архитектурно возможно два решения.

1. API снаружи обрабатывающий запросы мобильного приложения.
2. Локальное хранение файла настроек (sqlite, etc) и выгрузка/загрузка его в облако (dropbox, icloud, yadisk, etc)

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

Механизм такой: сделали что-то, есть подключение к инету?
ДА - отправляем на сервер - получили успешный ответ?
да - добавили в локальную базу с id который пришел с сервера.
нет - пишем в чем ошибка в лог, извиняемся перед пользователем (хотя схема другая,обычно все ок, и не ок только если сервер упал)
НЕТ - пишем в локальную базу, с пустым сервер ID

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

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

У вас всего два метода синхронизации:
- http запрос который отправляет клиент для загрузки/отправки данных;
- PUSH уведомление которое отправляет сервер на клиент;

Пример:
1. Об этом говорит сайт https://intellect.icu . Клиент А сделал фотографию.
2. Клиент А отправил фотографию на сервер.
3. Сервер получил фотографию
4. Сервер отправил PUSH уведомления клиентам B и C с инормацией "есть новое фото от клиента А"
5. Клиенты B и C получили уведомления.
5.1 Если пользователь(человек) находится в фото ленте, то клиент делает запрос на сервер, загружает фото и отображает ее.
5.2 Если пользователь находится, например, на экране настроек, то клиент отображает уведомление(тост) "есть новое фото от клиента А"
Пример реализации

Метод 1 Одностороння синхронизация изменений состояний

Организация синхронизации данных клиент-сервер для мобильного  приложения

Метод 2 Односторонняя синхронизация данных

Организация синхронизации данных клиент-сервер для мобильного  приложения
Примечания к реализации
  • передаваемые параметры (поля)
     1.data-  строка в формате  json
     
      
      Описание:
      
    1. данные в поле data передаются в строке в формате json 
     В них передаем данные, которые нужно синхронизировать.
     При этом используется:
     
      а)  уникальное локальное время создания(изменения)   "ut" (каждой записи )
      б) и уникальный локальный ид (для каждой сущности)   (ид толжны быть уникальны, иметь знак -).
       в)  передача без знака минус для ид ,  если ид глобальный.
  • пример
  •  data =
     [
        {
            "cmd":1,
            "ut":134256789088,
            "tb":"product",
            "dt": [-6341,134,13,12,12312,12]
         },
        {  "cmd":2,
           "ut":4578678789876,
           "tb":"product",
           "dt":[1,12,162,124,142,12,12,-341, 126,12,122,122]
        },
    	{  "cmd":3,
           "ut":45678908765,
           "tb":"product",
           "dt": 
        }
    
    ]
     
     где 
     
       cmd - команда (1,2,3) подробнее см. ниже
       ut -   юникстайм (в секундах)  каждой записи  на устройстве
      ( время  последней локальной  работы с данным объектом )
       dt- массив данных без названий полей 
       tb - название таблицы для синхронизации
       значения см ниже
     
     
     
     
     2.  передавать не более  N записей за один запрос, если записей больше N, то передать сначала подчиненные   записи  ,  потом все остальное порциями(постранично)

Комментарии

1. если устройство получило негативный ответ от сервера(отличный от 200 и после повтора передачи без синхронизации)
или у устройства нет доступа в интернет то все данные записывать в локальную базу

после появления интернет или при наличии таких данных определить разность ранее синхронизированных данных
и новых данных собранных offline

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

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



3.отправляем команду на синхронизацию
в случае успеха загружаем все данные или загружаем измененные данные и удаляем служебные данные в приложении
(в этот момент формируется отложенная запись на синхронизацию в связанных аккаунтах через PUSH)

4.клиент хранит
1. новые записи должны иметь ид <0 и равным уникальному локальному номеру
2.удаленные записи должны храниться в таблице удалений
3. обновленные записи в автономном режиме желательно помечать признаком обновлений

5.названия операций
ins=1
upd=2
del=3


6.название сущностей и полей доступных для вставки или обновления (если запись нужно удалить то нужен только ид):
передавать данные нужно именно в этом порядке без названия полей- только данные

сущность1 [id ид.поля..... ]
сущность2[id ид.поля..... ]
сущность3 [id ид.поля..... ]

т.о. синхронизация от устройства на сервер состоит из таких дейтвий
1. передать данные (при этом выволняются комплекс проверок на сервере)

2. сохранить изменения (выполняются изменения отсортированные по unixtime )
и ставятся изменения(синхронизвции через пуши) в очередь для связанных
с этим аккаунтом устройствами (аккаунтами)

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

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

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

Вау!! 😲 Ты еще не читал? Это зря!

Прочтение данной статьи про организация синхронизации данных позволяет сделать вывод о значимости данной информации для обеспечения качества и оптимальности процессов. Надеюсь, что теперь ты понял что такое организация синхронизации данных, клиент-сервер для мобильного приложения и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL

Из статьи мы узнали кратко, но содержательно про организация синхронизации данных
создано: 2016-12-27
обновлено: 2021-07-17
132423



Рейтиг 9 of 10. count vote: 2
Вы довольны ?:


Найди готовое или заработай

С нашими удобными сервисами без комиссии*

Как это работает? | Узнать цену?

Найти исполнителя
$0 / весь год.
  • У вас есть задание, но нет времени его делать
  • Вы хотите найти профессионала для выплнения задания
  • Возможно примерение функции гаранта на сделку
  • Приорететная поддержка
  • идеально подходит для студентов, у которых нет времени для решения заданий
Готовое решение
$0 / весь год.
  • Вы можите продать(исполнителем) или купить(заказчиком) готовое решение
  • Вам предоставят готовое решение
  • Будет предоставлено в минимальные сроки т.к. задание уже готовое
  • Вы получите базовую гарантию 8 дней
  • Вы можете заработать на материалах
  • подходит как для студентов так и для преподавателей
Я исполнитель
$0 / весь год.
  • Вы профессионал своего дела
  • У вас есть опыт и желание зарабатывать
  • Вы хотите помочь в решении задач или написании работ
  • Возможно примерение функции гаранта на сделку
  • подходит для опытных студентов так и для преподавателей



Комментарии


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

Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL

Термины: Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL