Масштабируемый алгоритм для обнаружения устаревших данных - PullRequest
2 голосов
/ 16 августа 2011

Вот проблема:

«Агенты», установленные на разных серверах, посылают сигналы «пульса» на центральный сервер каждые 5 секунд. Как я могу найти тех, кто пропустил свое сердцебиение более 10 секунд, и подать сигнал тревоги?

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

Однако это решение нельзя масштабировать для миллионов агентов.

Я ищу алгоритмы или технологии, которые делают это возможным.

Ответы [ 3 ]

2 голосов
/ 17 августа 2011
  1. Использовать карту: AgentId -> LastHearbeatTime
  2. Использовать 11 наборов (при условии, что достаточно разрешения в 1 секунду), каждый из них содержит идентификаторы агентов, о которых сообщалось в 1-секундном окне.

Каждый раз, когда агент сообщает о сердцебиении: 1. Найти его на карте 2. Удалить его из соответствующего набора 3. Обновить его на карте 4. Добавить его в соответствующий набор

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

Я считаю, что его можно реализовать без блокировок (возможно, вам потребуется 12 наборов).

1 голос
/ 17 августа 2011

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

Скажем, у вас есть две переменные, представляющие наборы, A и B.

Каждый тактовый импульс удаляет идентификатор агента из набора AКаждые 5 секунд другой поток генерирует предупреждение для каждого идентификатора агента в B, затем устанавливает B = A, и, наконец, что не менее важно, создает набор со всеми идентификаторами агентов и устанавливает A равным этому (если число агентовИдентификаторы действительно велики, вы можете подготовить новый набор между одной проверкой и другой и только спать в течение оставшегося времени).Блокировка потребуется только при изменении переменных, указывающих на каждый набор, при условии, что вы используете коллекцию наборов без блокировки.Производительность будет в значительной степени зависеть от алгоритмической сложности указанной реализации, и если вы пойдете по этому пути, вам следует отдать предпочтение той, которая имеет лучшую производительность (не обязательно лучшую big-O, например, если для вас важна задержка в случае выполнения), для удалений.

В качестве примечания: если память не является проблемой, или сбоев относительно мало, когда вы проверяете, должны ли вы вызывать оповещения и делать это, вы можете сделать это в отдельном потоке и получить интересный интерес.повышение производительности (опять же, платформа и время выполнения имеют значение, поскольку в Erlang это было бы очень просто, но в Windows стоимость создания полноценного нового потока может превысить выигрыш в производительности, если сбоев мало) за счет сохранения старогоB установлен в память.

0 голосов
/ 17 августа 2011

MongoDB отлично подходит для этого типа использования.Хотя это и не совсем алгоритм, он отвечает всем требованиям фундаментальной технологии, необходимой для создания этой услуги.Мы используем его здесь, на CopperEgg, для нашего продукта RevealCloud , чтобы сделать именно то, что вы говорите - мы отправляем уведомление, когда система отключается в течение некоторого времени - выборка каждые 5 секунд.Я хотел бы услышать больше о ваших мыслях и использовании.Можете ли вы предоставить более подробную информацию?

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