Распределённая комплексная система обработки Pluto

##Pluto: введение##

1. Pluto — это распределённая система распределения задач. Она включает в себя высокопроизводительный HTTP-сервер для статических файлов (но он не совершенен и не поддерживает продвинутые функции), который построен на основе фреймворка Apache Mina. Уровень управления HTTP использует стиль аннотаций, похожий на Spring MVC, поддерживает журналы и сохранение данных в реальном времени, а также восстановление данных.

2. Распределение задач осуществляется с помощью механизма предварительной отправки, который максимально использует возможности обработки клиента и поддерживает удалённое закрытие и перезапуск клиентов.

##История создания Pluto##

1. Раньше все задачи обрабатывались на сервере. Затем из-за увеличения сложности требований была добавлена функция периодических задач. Чтобы изолировать сервер, отдельно развернули программу обработки задач базы данных, что снизило нагрузку на сервер. Из-за роста сложности серверных функций и частого возникновения узких мест в производительности базы данных появился план разработки Pluto, предназначенный для обработки большого количества задач, требующих параллельной обработки, или массовых запросов на обновление данных.

2. По мере усложнения вычислений на одном компьютере время ожидания становится неприемлемым, поэтому было решено расширить Pluto для реализации распределённых вычислений, используя кластеры для ускорения сложных вычислений и статистики данных.

##Часть инициализации##

1. При запуске Pluto сначала запускается система журналов log4j, затем инициализируется конфигурация и отслеживаются изменения конфигурации (проверяется один раз в секунду, если есть изменение, выполняется соответствующий метод перезагрузки).

2. Далее инициализируется диспетчер задач, обрабатываются предварительно отформатированные файлы данных, запускается модуль журнала изменений задач. Если эта стадия завершается неудачно, происходит немедленный выход.

3. Затем инициализируется HTTP-сервер, сканируются аннотированные контроллеры, привязываются порты. В случае неудачи также происходит выход.

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

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

##HTTP-часть##

1. Когда модуль HTTP-сервиса запускается, он предварительно сканирует все пакеты, указанные во время инициализации, извлекает методы, содержащие конкретные аннотации, и связывает URL-адреса с методами. URL-адрес поддерживает регулярные выражения и подстановочные знаки. Если есть повторяющиеся адреса, запуск завершится неудачно.

2. После завершения сканирования классы, содержащие связанные методы, помещаются в пул объектов для инициализации для последующего выполнения.

3. Получив запрос, URL анализируется, выбирается соответствующий метод, анализируются параметры аннотаций и соответствующие данные извлекаются из контекста запроса.

4. Все контроллеры должны наследоваться от BaseController, этот родительский класс предоставляет контекстную информацию, обработку запросов и другие вспомогательные методы. На данный момент реализованы классы Admin и FileController, а также AJAXController для запросов AJAX.

5. Класс Admin содержит методы добавления задач, остановки и получения информации о состоянии сервера. Он в основном ориентирован на интерфейс управления сервером и будущие задачи будут выделены в отдельный класс задач.

6. FileController является основной частью статического сервера, этот метод анализирует URL и возвращает соответствующие ресурсы клиенту. При запросе файла сначала проверяется, был ли файл изменён. Если нет, возвращается статус 304, затем проверяется, является ли файл новым. Если да, файл загружается в память и создаётся задача мониторинга файла. Если файл изменяется, он перезагружается в память. В настоящее время этот класс содержит только два метода, которые обрабатывают текстовые (html, js, css) и графические (jpg, png, gif, swf) ресурсы.

7. AJAXController возвращает результаты других методов в формате JSON.

##Управление данными##

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

2. Распределённые вычислительные задачи не записывают данные в файлы или журналы, а временно хранят данные только в течение своего жизненного цикла.

##Коммуникационный клиентский сервис##

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

2. Во время первого подключения клиента к серверу определяется тип клиента (исполнитель, отправитель или резервный) на основе предоставленных клиентом данных о состоянии.

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

4. Когда событие изменения состояния задачи инициировано, все клиенты проверяются, выбираются те, кто находится в очереди выполнения, но не достиг предела, и у кого последний раз отправленная задача была самой давней. Один из них выбирается для получения задачи, и процесс повторяется до тех пор, пока все задачи не будут отправлены или не останется доступных клиентов для отправки задач.

5. Если подходящих клиентов нет, они добавляются в список ожидающих отправки и ждут следующего события изменения состояния задачи.

6. В настоящее время при завершении работы сервера по умолчанию все клиенты уведомляются об уничтожении выполняемых задач и закрываются.