Двунаправленная синхронизация файлов с использованием механизма пула

Двунаправленная синхронизация файлов с использованием механизма пула

Georgii KapanadzeTechnical Leave a Comment

Введение

Интересует синхронизация различных систем управления файлами, таких как Dropbox, Microsoft OneDrive или Microsoft SharePoint? Позвольте мне представить некоторые основные принципы, лучшие практики двунаправленной синхронизации файлов и документов, как сократить время разработки и офф-курса финансовых затрат.

Что тебе нужно?

С самого начала вам необходимо позаботиться о прикладных программных интерфейсах (API) каждой системы, которую вы хотите синхронизировать. Чтобы иметь дело с аутентификацией, изучите представление схемы и принципы, манипуляцию данными и приведите их к одному общему языку. Этого можно добиться как с помощью кропотливой работы разработчика, изучающего сотни страниц документации, так и с помощью интеграционной платформы.

Так получилось, что мы предлагаем интеграционную платформу с довольно уникальной технологией, так что вы можете узнать больше о нашем Connect Bridge. Это программное обеспечение позволяет использовать API различных систем с использованием простого SQL (стандартный язык запросов). И не имеет значения, являетесь ли вы разработчиком .NET или Java или любого другого языка. Схема визуализируется в инструменте Query Analyzer Connect Bridge и разработчик может протестировать свой запрос в этом инструменте и сразу же увидеть результаты. Тогда вам просто нужно контролировать базу данных, чтобы отслеживать изменения, и вы можете идти.

Механизм водоохлаждения

Принцип механизма объединения довольно прост: данные из целевых систем извлекаются и обрабатываются один раз в заданный период времени или по действиям пользователя. И все.

Преимущества

Не все системы предоставляют возможность запускать действия после изменения файла в режиме реального времени. Если одна из них не предоставляет такой возможности, это может привести к серьезным осложнениям. Поэтому основным преимуществом является контроль данных и времени синхронизации файлов. Это дает более полное представление о происходящем и открывает возможность избежать ненужных действий.

Недостатки

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

Урегулирование конфликтов

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

Принцип основной программы

Признание изменений

Для того, чтобы отслеживать изменения, необходимо иметь базу данных с отображенными элементами целевых систем, которые были синхронизированы. Распознавание обновления может происходить либо по времени модификации, либо по версии, либо по тому, что может быть использовано и предоставлено целевыми системами. Создать или удалить довольно просто: если запись элемента не существует в базе данных, то она новая, а если элемента нет в целевой системе, но есть запись в базе данных, то она была удалена в целевой системе. И все. В некоторых системах есть возможность запросить изменения в заданный период времени, но в любом случае вам придется отслеживать, что было синхронизировано из-за сбоев, вызванных целевыми системами или соединением.

Двигатель синхронизации файлов

Для работы основной логики синхронизации с целевыми системами хорошо создать класс провайдера для каждой из них и реализовать общий интерфейс, задающий основные операции CRUD (Create-Read-Update-Delete). Тогда в алгоритме ядра нет необходимости заботиться о том, какой именно. Достаточно создать общую логику двунаправленной синхронизации, а самим манипуляцией займутся классы провайдеров. Если реализован хороший алгоритм ядра, то неважно, сколько систем вы синхронизируете. Можно просто добавить реализацию других провайдеров. Этот алгоритм должен следовать иерархии мастеров и рабов, чтобы корректно обрабатывать конфликты. Если вы синхронизируетесь по парам, отсортированным по превосходству, то все должно быть хорошо.

Пеформанс

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

Безопасность консистенции данных

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

В процессе работы могут возникать различные исключения, на которые нельзя повлиять, например, ошибка внутреннего сервера целевых систем, потеря связи и т.д.. Лучшей практикой является разделение обработки исключений на отдельные блоки, охватывающие код, который может попытаться выполнить до тех пор, пока не будут выполнены все операции, но не продолжить работу с следующим блоком. Это своего рода дерево уровней. Приведу пример: при синхронизации выяснилось, что в первой системе было создано 10 файлов в 5 папках. Таким образом, она начнет создавать эти 5 папок в других системах, но одна из операций вставки бросает исключение. Она может попытаться создать эти 4 папки, но не должна начинать вставлять файлы, потому что пути к 2 файлам не существуют. Это можно сделать по-разному и сложнее, но доверьтесь мне, чтобы все было как можно проще. Количество вариантов возможных сценариев ошибок при двунаправленной синхронизации большего количества систем очень велико и, более того, рекурсивно.


Нашли ли вы эту статью полезной?

Присоединяйтесь к более чем 6000 подписчиков нашего информационного бюллетеня со свежими новостями из мира системной интеграции и программного обеспечения для бизнеса!

100% конфиденциальность. Мы не спам.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

For security, use of Google's reCAPTCHA service is required which is subject to the Google Privacy Policy and Terms of Use.