Архитектура масштабируемой системы / Дизайн для чтения / анализа файлов

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

По сути, минимально подробный список имен файлов - это одна БД, и Клиенты должны получить доступ к списку, чтобы узнать, какие файлы необходимо проанализировать / преобразовать следующим. Файлы снова находятся на другом сервере / месте. В то время как большинство частей разработано, одна критическая часть, которая нуждается в пересмотре, - это схема передачи имен файлов различным клиентам.

У меня есть два варианта сейчас:

  1. Разработайте единый сервис, который будет расположен рядом с БД и направляет все запросы к именам файлов и передает клиентам. Таким образом, в этом случае клиенты общаются с сервисом (предопределенный протокол / формат) и получают список.

  2. Разработка клиентов для непосредственного общения с БД и осуществления синхронизации / распределения по каналам внутри клиентов.

Моя единственная проблема с первым вариантом - это масштабируемая архитектура / дизайн? Кто-нибудь имел дело с таким обстоятельством в масштабируемой архитектуре, когда один ресурс становится критическим при масштабировании (в моем случае это может быть один сервис, обслуживающий / обслуживающий всех клиентов)

Источник

2 ответа

Решение

Я хотел бы предложить вам посмотреть на очереди сообщений, такие как Rabbit MQ(http://www.rabbitmq.com), Microsoft Message Queue (http://bit.ly/GMo4iI) и IBM Message Queue (http://bit.ly/GMo6qY), в которой уже есть масштабирующие архитектуры.

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

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

Источник

Я предлагаю использовать распределенную сетку данных, такую ​​как GigaSpaces (http://www.gigaspaces.com/datagrid) поверх вашей БД. Таким образом, вы можете разделить ваши данные на несколько машин и снизить нагрузку на вашу БД - клиенты будут читать файлы, которые будут обрабатываться из разных экземпляров сетки данных. Масштабируемость становится возможной благодаря увеличению количества разделов сетки данных при увеличении нагрузки и принятии решения о том, как распределить данные между экземплярами сетки данных.

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

GigaSpaces также предлагает отличный инструмент мониторинга, чтобы вы могли контролировать свою нагрузку (живучесть, статистика и т. Д.)

Источник
Другие вопросы по тегам