LINUX.ORG.RU

Я спросил у ясеня^W инфосферы...

 ,


0

1

Интересует такая задачка на распределение и децентрализацию.

Пусть у нас есть N или даже K серверов, соединённых в доверенную p2p-сеть. Одному из серверов понадобились некоторые данные, которые, может быть у кого-то есть, а может — нет. Ну, для определённости, нужно получить снипет сайта по URL. Можно самому дёргать сайт с этой URL. Но сайт может тормозить, может лежать, может быть уже вообще этой страницы нет. Зато инфу для снипета мог уже дёргать какой-нибудь другой сервер нашей сети. Поэтому можно кинуть запрос в сеть. Будет ответ — воспользуемся готовым решением. Нет — тогда уже будем дёргать сами. Результат сохраним и в другой раз, если кто-то в сети сделает такой же запрос, вернём ему наш результат.

Время реакции... Ну, отлично — менее секунды. Удовлетворительно — несколько секунд.

Всё должно быть на достаточно популярных, мало зависящих от платформ решениях c произвольным конфигурированием (т.е. выпадение каких-то узлов сети не должно сказываться на нашей работоспособности).

Я вижу навскидку такие варианты.

Файловый командный синк через btsync (быстрее и надёжнее) или syncthing+syncthing-inotify (открыто, но менее надёжно и быстро). Клиент шлёт запрос в виде файла в специальном каталоге запросов, изменения в котором мониторят сервера. Обнаружив запрос, парсят, смотрят, есть ли чем ответить и кидают туда же файл с результатом. Клиент всё это время до истечения таймаута проверяет, не пришёл ли результат.

Плюсы — очень простая организация и полная децентрализация. Наш клиент вообще может ничего не знать о серверах. Возможна реализация асинхронной работы (клиент шлёт запрос и отваливает. Монитор изменений через какое-то время находит ответ и засовывает его куда нужно).

Минусы — может быть приличная временнАя задержка. До секунд — легко.

Ещё вариант — соединяем сервера по MQTT-бриджированию. Клиент дёргает один из серверов (он должен знать хотя бы один), шлёт по MQTT команду-запрос и слушает в ожидании ответа.

Плюсы — высокая скорость реакции. Возможность асинхронной работы.

Минусы — привязка к конкретным машинам, сложная логика синхронного клиента (сперва шлём запрос, потом слушаем...)

Вариант с p2p-FS, в которых можно мутабельные данные писать по ключу (FreeNet — может, ещё где-то есть). Скажем, когда мы первый раз получаем данные, потом сохраняем их в сеть по хешу от URL. Клиент же просто пытается получить данные по такому же своему ключу. Нету — тогда получает данные сам и, опять же, сохраняет по ключу.

Плюсы — распределённое хранение, отсутствие привязки к конфигурации сети и т.п.

Минусы — очень медленная работа, особенно в отсутствии файла в сети, невозможность асинхронной работы.

...............

Кто что ещё предложит?

★★★★★

Ответ на: комментарий от Deleted

rabbitmq или аналоги?

Это вариант с MQTT. То же самое, по сути (собственно, RabbitMQ умеет MQTT, кажется), только MQTT более широко распространён.

KRoN73 ★★★★★
() автор топика

Клиент шлёт запрос в виде файла в специальном каталоге запросов

Ты серьезно?

И вообще, разве твою задачу распределенного кеша не решили сто раз в каком-нибудь готовом memcached?

t184256 ★★★★★
()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от t184256

Ты серьезно?

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

разве твою задачу распределенного кеша не решили сто раз в каком-нибудь готовом memcached?

В централизованном виде с жёсткой конфигурацией. Мне же нужна децентрализованность с произвольной конфигурацией.

KRoN73 ★★★★★
() автор топика

Если интересно, для теста погонял первый вариант через синхронизацию через btsync. Всё оказалось даже хуже, чем ожидал, время двусторонней передачи (ping-pong) составляет 10-20 секунд, иногда — до 30 секунд.

syncthing+inotify не тестировал. Теоретически, скорость должна быть выше, но на практике периодически случаются полные подвисы синхронизации.

Теперь ломаю голову на счёт кластеров с «официальными» очередями сообщений. Mosquitto/MQTT позволяет делать только жёсткие централизованные связки. RabbitMQ cluster посмотрел — это Эрланг-ад, при чём прямо из коробки очень странно работает на некоторых машинах...

KRoN73 ★★★★★
() автор топика

Кажется, придумал компромиссный вариант.

Есть общий синхронизируемый пул, куда каждая нода кидает информацию о себе. В том числе — адрес для RPC-обращений.

Соответственно, когда нам что-то нужно, берём список нод из пула и опрашиваем всех прямыми запросами. Минус только в том, что ноды должны быть доступны по http снаружи. Ну да это для сабжевой задачи не критично.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

Соответственно, когда нам что-то нужно, берём список нод из пула и опрашиваем всех прямыми запросами.

гм, неужели какойнить etcd также работает?

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.