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

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

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

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

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

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

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

Ответы [ 2 ]

2 голосов
/ 10 мая 2012

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

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

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

0 голосов
/ 24 марта 2012

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

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

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

...