Проект системы для агрегирования в почти в реальном времени, N самых популярных статей за последние пять минут, последний час и последний день? - PullRequest
2 голосов
/ 12 июня 2019

Мне недавно задали вопрос об устройстве системы в интервью:

Предположим, что приложение позволяет пользователям делиться статьями с 3-го партийные сайты с их связями. Предположим, что все акции делятся через общий путь кода на сайте приложения (обслуживается несколькими серверами в географически разнообразных колосах). Разработать систему для агрегирования в почти в реальном времени, N самых популярных статей за последние пять минут, последний час и последний день. Предположим, что количество уникальных общих статей в день от 1 до 10 млн.

Итак, я придумал следующие компоненты:

  • Существующий уровень обслуживания, который обрабатывает события общего доступа
  • Агрегирование
  • Хранилище данных
  • Некоторые механизмы транспорта для отправки уведомлений о событиях общего доступа в службу агрегирования

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

И интервьюер спросил меня, почему вы выбрали здесь Кафку и как Кафка будет работать, например, какие темы вы будете создавать и сколько у него будет разделов. Так как я был сбит с толку, поэтому не мог ответить правильно. По сути, он пытался получить представление о модели «точка-точка» против публикации-подписки или модели «push-to-pull»?

Теперь я начал говорить о том, как работает служба агрегации. Одно из решений, которое я дал, состояло в том, чтобы хранить счетчики для каждого общего URL-адреса по 5-минутному интервалу за последние 24 часа (244 сегмента по URL-адресу). По мере того как происходят события каждого общего ресурса, увеличивайте текущий интервал и пересчитывайте 5 минут, час и день. итоги. Обновите списки Top-N по мере необходимости. После ввода каждого нового общего URL-адреса удалите все URL-адреса, которые не были обновлены в течение 24 часов. Теперь я думаю, что все это можно сделать на одной машине.

Интервьюер спросил меня, можно ли все это сделать на одной машине? Также можно ли обслуживать отслеживаемые акции 1M-10M на одной машине? Если нет, то как бы вы разделить? Что произойдет, если он выйдет из строя и как вы восстановитесь? По сути, я был сбит с толку, как служба агрегации на самом деле будет работать здесь? Как он получает данные от Kafka и что на самом деле будет с этими данными.

Теперь, что касается хранилища данных, я не думаю, что нам нужно постоянное хранилище данных, поэтому я предложил использовать Redis с разделением и избыточностью.

Интервьюер спросил меня, как вы будете разделять и иметь избыточность здесь? И как экземпляр Redis будет обновляться из всего потока и как Redis будет структурирован? Я был смущен этим также. Я сказал ему, что мы можем записать выходные данные службы агрегации в этот экземпляр Redis.

Было несколько вещей, на которые я не смог ответить, так как я запутался в том, как будет работать весь поток. Может ли кто-нибудь помочь мне понять, как мы можем разработать такую ​​систему распределенным способом? И что я должен был ответить на вопросы, которые задавал мне интервьюер.

1 Ответ

1 голос
/ 13 июня 2019

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

Я постараюсь поделиться одним вероятным ответом на эту проблему. Предположим, у меня есть распределенная постоянная система типа Cassandra. И я собираюсь поддерживать статус обмена в любой момент, используя мою инфраструктуру Cassandra. Я буду поддерживать кластер Redis до уровня персистентности для кэширования LRU и поддерживать сегменты в течение 5 минут, 1 часа и дня. Выселение будет настроено с использованием срока действия. Теперь моей службе агрегации нужно обрабатывать только минимальные данные, присутствующие в моем кэше Redis LRU. Установка распределенного кластера Kafka с высокой пропускной способностью будет перекачивать данные из общего обработчика. И Кафка передает данные в кластер Redis, а оттуда - в Кассандру. Чтобы поддерживать вывод почти в реальном времени, мы должны поддерживать пропускную способность кластера Kafka, соответствующую ему.

...