Обмен данными между теплоходами

О клиенте

Компания «ВодоходЪ» является лидером круизной отрасли в России, а также входит в число лидеров в Европе по числу единиц флота и пассажировместимости. На протяжении 18-и лет компания организует круизы, проходящие через самые интересные города и локации нашей страны, придерживаясь высоких стандартов качества. С учетом пассажирских перевозок на малом флоте, «ВодоходЪ» и его дочерние предприятия ежегодно обслуживают в среднем 400 тысяч человек.

О проекте

Ранее мы уже писали о проекте “ВодоходЪ. Речные круизы”. Здесь мы расскажем о механизме обмена данными, одной из ключевых задач, которую нам предстояло решить при создании проекта.
Для пассажиров на борту теплохода работает мобильное приложение, которое общается с сервером, установленным здесь же, на корабле. Этот сервер занимается хранением всех необходимых для работы приложения данных.
В то же время, для централизованного управления списком предоставляемых услуг, экскурсий, мероприятий и прочего контента существует единая панель администратора, расположенная на сервере на берегу, где-то в дата центре. Мы называем его “глобальный сервер”.
Перед нами стояла проблема синхронизации всех необходимых данных между этим глобальным сервером и десятками серверов на теплоходах.

Цели

• Синхронизировать данные в обе стороны. Чтобы менеджеры могли управлять контентом как из офисе в городе, так и на теплоходе.
• Актуальность данных в пределах 10 минут. Чтобы достигнуть такой актуальности данных на теплоходах, нужна очень высокая скорость обмена.
• Высокая надежность обмена. Интернет на кораблях часто отсутствует. Но как только он появится – все изменения должны быть доставлены.

Решение

Алгоритм обмена

Для реализации синхронизации мы выработали специализированный алгоритм. Для его корректной работы необходим механизм отслеживания изменений и даты их проведения. Механизм работает на уровне ядра системы, но затрагивает только интересующие нас объекты, которые подлежат синхронизации.
На верхнем уровне алгоритм синхронизации выглядит следующим образом:

• Сервер теплохода инициирует синхронизацию с глобальным сервером. Если связь отсутствует — попробует позже.
• Все изменения, которые произошли в период отсутствия теплохода в сети, формируются в список, который впоследствии будет отправлен на глобальный сервер.
• Глобальный сервер, получив от теплохода сообщение о начале синхронизации, начинает формировать список изменений, которые произошли с момента последней синхронизации как на самом глобальном сервере, так и на других теплоходах.
• Как только обе стороны сформировали список изменений, происходит непосредственная передача и обработка, по результатам которой все сообщают друг другу о том, что все прошло нормально.

Передача фрагментами

Одна из главных особенностей — количество и объем изменений. Их может оказаться очень много. В условиях непостоянного соединения передавать большие объемы данных очень ненадежно, опасно и чревато многочисленными ошибками в данных.

Поэтому мы приняли решение разбивать изменения на более мелкие части. Для этого мы внедрили “период синхронизации” — временной промежуток, за который необходимо получить изменения. Он может быть настроен индивидуально, но помимо этого, период варьируется в течение дня. Зная дату и время последней успешной синхронизации, мы добавляем к ней указанный период и пытаемся синхронизировать данные, которые были созданы, изменены или удалены в этом промежутке.

Пример

Теплоход последний раз успешно синхронизировался в 06:00, потерял соединение и появился в сети в 18:00. Сразу же будет запущена синхронизация изменений, которая последовательно получит изменения за каждый час отсутствия связи. Таким образом, даже если теплоход потеряет связь на несколько дней, механизм обмена безболезненно и стабильно сможет обработать накопившиеся объемы данных.

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

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

Вызовы

Продолжительное отсутствие сети

На теплоходе может несколько дней отсутствовать интернет-соединение, но как только оно появляется — необходимо максимально оперативно провести синхронизацию.

Непостоянное количество узлов

Количество теплоходов, запущенных в навигацию, может меняться от сезона к сезон или прямо в течение сезона. В связи с этим система была спроектирована так, чтобы не зависеть от количества клиентов — пусть теплоходов 10 или 100, мы обеспечим данными каждый.

Синхронизация между теплоходами

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

Большие объемы данных

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