Задать вопрос
@ChemAli
restful-api

Интенсивная передача данных из LAN в БД вебсайта (синхронизация)

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

На сайт попадают только меняющиеся данные, а не вся БД. Информация обновляется в живом порядке. В идеале нужно отражать на сайте то же состояние БД в котором она находится на сервере внутри корпоративной сети. То есть при каждой правке единицы она отправляется на сайт.

Опыта нет, видится такое решение: измененные единицы ставятся в очередь, из которой по одной или пакетами отправляются на веб-сервер POST-запросом, содержащим единицу(-ы) информации в виде XML или JSON, где их подхватывает импортирующий скрипт. Обратно ничего не принимается кроме сигнала об успешном приеме данных. В случае потери связи очередь наполняется и при восстановлении коннекта отправка возобновляется.
  • Интенсивность потока до 1500 единиц в час.
  • Объем данных в одной единице ~3 кб + служебный мусор от xml/json.
  • Требования к устойчивости минимальные: полная актуализация после обрыва коннекта в течение часа-двух.

Нормален ли такой подход? Если нет, то как можно сделать лучше?

Возможно, есть стандартные общепринятые решения, которые улизнули из сектора обстрела?
  • Вопрос задан
  • 2573 просмотра
3 комментария
Подписаться 2 Оценить 3 комментария
Решения вопроса 1
@ComodoHacker
Самая лучший вариант репликации — отсутствие репликации. :) Потому что это еще одна потенциальная точка отказа в системе, которую нужно мониторить, еще один источник головной боли как для админов, так и для разработчиков. То есть решение — сайт берет данные непосредственно из корпоративной БД.

Если по каким-то причинам это вас не устраивает (обдумайте причины еще раз), то сделайте репликацию средствами БД. Это будет надежнее, чем вы сможете сами написать и оттестировать в разумные сроки.

Если же БД не умеет то, что вам нужно, или просто очень хочется сделать свой велосипед, тогда вперед. Вначале выберите модель pull или push. Исходя из ваших требований, лучше pull, но это менее безопасно. Возиться с xml/json не стоит, пишите прямо в БД. Везде вставляйте код для мониторинга. Очередь изменений может переполняться при длительном отсутствии связи. На случай большой рассинхронизации неплохо иметь код «полной перезаписи всего».
Ответ написан
1 комментарий
1 комментарий
Пригласить эксперта
Ответы на вопрос 4
strib
@strib
Посмотрите в сторону репликации данных средствами самих БД. К примеру накат redo-log.
Ответ написан
2 комментария
2 комментария
opium
@opium
Просто люблю качественно работать
Нахрен вам вообще репликация, делайте все в одной бд и храните её бекап на всякий случай(а лучше два).
Для доступности сделайте второй канал в офис.
1500 на 3 кб это 4.5МБ, трафик ниочемный, потянет даже резервный 3г или ваймакс.
Ответ написан
Комментировать
Комментировать
@kader
Видится мне опасность такого подхода. Если ответ не придет от сервера, по каким-то причинам, а пост по факту дойдет, то велика вероятность получить дублирование отправки, то есть, например, 2 одинаковых носости запостится.
Ответ написан
1 комментарий
1 комментарий
@ChemAli Автор вопроса
Парадигма сменилась. Будем заливать все данные разом по крону. Всем спасибо, все красавчики!
Ответ написан
Комментировать
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
Вакансии с Хабр Карьеры
QA engineer (настройка автоматизации на PyTest), тесты API, UI.
HR BIG G
До 250 000 ₽
Intern System Analyst
Media Code
До 30 000 ₽
Junior Backend Developer (Node.js) / selfstudio.se
Self Studio
от 800 до 1 500 $
Ещё вакансии
Заказы с Хабр Фриланса
Доработать дизайн лендинга
25 апр. 2024, в 09:29
2500 руб./за проект
Сделать красивый лендинг в Тильде
25 апр. 2024, в 09:27
4000 руб./за проект
Создание видео. Моушен дизайн
25 апр. 2024, в 09:20
10000 руб./за проект
Ещё заказы