Создайте общий планировщик заданий

Question

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

Я прочитал много ресурсов в Интернете, но вам нужно определенное руководство в продвижении вперед.

Создайте общий планировщик заданий для компании X (которая является одной из крупных современных технологий ).

Прецеденты

Создание/чтение/обновление/удаление заданий

Исследовать рабочие места, которые были бежать в прошлое (тип работы, время, проведенные, деталь)

сдерживающего

Сколько рабочих мест будет выполняться в системе в секунду?

= # работа/час из-за пользователей + # Работа/час из-за машин

= 1м * 0,5/день/24/3600+ 1м/50 * 20/24/3600

~ = 12 рабочих мест/сек

Сколько данных система должна хранить?

Рассуждение: Я только хранение задания деталей исполнения, фактическая работа (выполнение скрипта) выполняется> на других машинах, а некоторые из данных, собранных является время окончания, успех статус/неисправность, и т.д.. Это> все, скорее всего, текст, возможно, с графикой для иллюстрации. Я будет хранить данные>> все работы, выполняемые на в системе через планировщик заданий (т.е. в течение последних 10 лет)

= (размер страницы, где детали заданий устанавливаются + размер данных, собранных о работе) * # рабочих мест * 365> дней * 10 лет = 1 MB * 900 000 * 365 * 10

~ = 3600 000 000 MB

= 3600 000 GB

= 3600 ТБ = 3.6 PB

Аннотация дизайн

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

Накладной слой: обслуживает запросы, показывает детали пользовательского интерфейса.

хранения данных слоя: Действует как большой хэш-таблицы: Сохраняет отображения ключ-значение (ключ будет рабочие места, организованные DATETIME они бегут, в то время как значения будут показывать подробности этих работ). Это позволит легко найти исторические и/или запланированные задания .

Узкие:

трафика: 12 рабочих мест/сек не слишком сложно. Если это всплески, мы можем использовать балансировщик нагрузки для распределения заданий на разные серверы для выполнения .

Данные: при 3,6 ТБ нам нужна хеш-таблица, которая может быть легко запрошена для быстрого доступа к заданиям, которые были выполнены в приложении .

Масштабирование абстрактный дизайн

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

Для обработки трафика у нас может быть сервер приложений, который обрабатывает 12 запросов/сек, а резервная копия - в случае сбоя. В будущем мы можем использовать балансировщик нагрузки, чтобы уменьшить количество запросов , идущих на каждый сервер (при условии, что> 1 сервер находится в производстве). Преимущество в этом случае - уменьшить количество запросов/сервер, увеличить доступность (в случае, если один сервер терпит неудачу и обрабатывает трафик spike-y хорошо).

Для хранения данных, чтобы хранить 3,6 ТБ данных, нам понадобится несколько машин , чтобы хранить их в базе данных. Мы можем использовать db noSQL или SQL db. Учитывая, как последний имеет более широкое использование и поддержку сообщества, что помогло бы в решении проблем и использовалось крупными фирмами в данный момент, I выберет mySQL db.

По мере роста данных, я бы принять следующие стратегии для обработки его:

1) Создать уникальный индекс на хэш

2) Шкала MySQl дБ по вертикали, добавив больше памяти

3) Разделите данные путем оштукатуривания

4) Используйте стратегию репликации ведущего-ведомого с репликацией master-master , чтобы обеспечить избыточность данных

Заключение

Таким образом, это будет мой дизайн компонентов планировщика заданий.

Answer 1

Большинство широкомасштабных планировщиков заданий учитывают аспекты, не охваченные в вашем документе.

Некоторые из ключевых вопросов, являются: (в произвольном порядке)

• Аннулирование - Вы часто хотите, чтобы убить долго идущую работу, или предотвратить один запуск.
• Приоритет - вы часто хотите, чтобы задания с высоким приоритетом выполнялись в соответствии с заданиями с низким приоритетом. Но реализовать это так, чтобы задания с низким приоритетом не ожидали вечно в системе, где сгенерировано множество заданий, является «нетривиальным»
• Ресурсы - некоторые задания могут планироваться только в системах с определенными ресурсами. Например. для некоторых из них потребуются большие объемы памяти или быстрый локальный диск или быстрый доступ к сети. Выделение их эффективно сложно.
• Зависимости - некоторые задания могут выполняться только после завершения других заданий и, таким образом, не могут быть запланированы до заданного времени.
• Сроки - некоторые рабочие места должны быть завершены к заданному времени. (или, по крайней мере, начинаться с определенного времени.)
• Права доступа - некоторые пользователи могут оставлять свои объявления в определенных группах ресурсов или с определенными свойствами или определенным количеством рабочих мест и т. д.
• Квоты - некоторые системы предоставляют пользователям определенное количество системного времени, и выполнение задания вычитается из этого. Это может существенно повлиять на цифры в вашем примере.
• Подвеска - некоторые системы позволяют выполнять задания с проверкой и приостановкой и возобновлением позже.

Я уверен, что есть куча больше - попробуйте просматривал документы на slurm или grid-engine для большего количества идей.

Другие вещи, чтобы рассмотреть следующие вопросы:

1. Ваш абстрактный дизайн, вероятно, нуждается в кучу более подробно, чтобы поддержать эти дополнительные понятия.
2. Вам не нужно часто обращаться к большинству данных 3.6 ТБ - разделить его на последние и старые данные, и у вас будет гораздо более управляемый размер базы данных, если вы разрешите доступ к старым данным медленнее (и нажмите диск).
3. Возможно, у вас есть разные категории пользователей, по крайней мере, «администраторы» и «пользователи». Что это означает для структуры приложения.
4. Реальное приложение планирования заданий способно обрабатывать больше запросов в секунду - slurm предлагает устойчивую 33/секунду с более высокими очередями, но я понимаю, что она может значительно превышать это.
5. Обычно требуется отправлять задания или запрашивать состояние задания через интерфейсы, отличные от веб-страницы, - что это означает для структуры вашего приложения. (Я бы использовал простой API-интерфейс для основного ядра и имел веб-интерфейс как немой переводчик, и все дополнительные методы используют один и тот же API или используют REST API с простым веб-интерфейсом)
6. Как вы обнаруживаете сбой сервера? Достаточно ли для этого достаточно двух серверов? Обычно для этого используются методы, основанные на кворуме, или тесты на подключение к третьему серверу. Что вы делаете, если неудавшийся сервер возвращается в сеть?

Answer 2

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

Если вы используете автобус, вы можете легко сжать свою очередь. Это может замедлить процесс обработки, что означает, что вам нужно будет искать параллелизм.

Часто считается, что писать такую ​​услугу легко. Это не.

Некоторые другие вещи, чтобы думать о ..

Что произошло, когда выходит из строя сообщение. Заблуждается? Вы откатываете? Как вы масштабируете свою архитектуру. Можете ли вы легко добавить новых клиентов/потребителей?

Answer 3

Значительная часть того, что вы описали, была реализована различными структурами для планирования заданий и их выполнения. Тот, о котором я знаю - Quartz. Хотя я бы реализовал несколько вещей по-разному в Quartz, это хорошо документировано и даст вам много идей о рабочих местах и ​​обструкциях, с которыми они сталкиваются обычно.

Подход, который вы описываете, хорош, но я бы исключил из него проблемы, связанные с конкретным доменом (такие как параллельная обработка, очертание, масштабирование). Если на разных машинах будут выполняться задания, это связано с тем, что конкретный случай (например, задание для финансового банка) не может вписаться в одну машину. Я не думаю, что вы, как разработчик механизма работы, должны беспокоиться об этом. Причина в том, что вы разрабатываете инфраструктуру, а не продукт.

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

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