У меня 4 сервера, все в безопасной локальной сети.
Каждый сервер запускает script.php (каждую минуту).
script.php читает из локального каталога с именем / arc, выполняет проверку файла и записывает новый файл обратно в / arc.
(Это небольшие текстовые файлы размером 2 КБ, которые создаются со скоростью около 20 в секунду на каждом сервере).
Я бы хотел, чтобы все каталоги 4 / arc были объединены в один.
Например, когда script.php запускается на server1, я хотел бы, чтобы он знал обо всех файлах во ВСЕХ каталогах / arc, а не только о том, который находится на локальном компьютере. И когда server1 записывает файл в свой локальный каталог / arc, серверы server2-4 теперь должны видеть его в своих каталогах / arc.
Также следует отметить, что эти файлы являются скоропортящимися и очищаются каждые 10 минут.
ОБНОВЛЕНИЕ: в настоящее время я собираюсь попробовать смонтировать все каталоги через NFS. Каталоги arc также являются tmpfs, так что это должно быть довольно быстро. Если кто-то не думает, что есть более быстрый способ, я попробую следующее:
1) на каждой машине я буду монтировать каталоги / arc на всех остальных машинах по NFS. Итак, 1 локальный и 3 NFS.
2) когда script.php запускается на любой из машин, будет несколько команд "cp" для каждого каталога arc. это гарантирует, что на каждой машине всегда будет последний кэшированный вывод. (Является ли 20 копий в секунду X 4 местоположения по NFS узким местом? Надеюсь, что нет.)
3) поскольку кэшированный вывод копируется на все локальные машины, это означает, что script.php никогда не должен читать файл через монтирование NFS. Локальное чтение кэша дуги занимает 0,37 секунды. Сколько времени потребуется, чтобы прочитать файл через NFS? дольше, чем это? Вот что произойдет, если я скопирую в одно центральное место.
Итак, я обмениваю несколько команд копирования на чтение. Но я ДУМАЮ, что это хорошая сделка, поскольку цель состоит в том, чтобы запросы script.php выполнялись как можно быстрее, что означает минимизацию времени, необходимого для чтения кэшированного файла.
Двадцать 2k файлов в секунду ... на 4 машинах. Похоже, что вам действительно нужен сервер базы данных.
MySQL, Postgres, SQLServer легко справляются с такой частотой обновления.
Если с каждой машины нужно скопировать на другие 3, то вам понадобится n-1 копия для каждого файла. Итак, 4 машины, генерирующие 20 файлов в секунду, составляют 120 копий в секунду. Если вам когда-нибудь понадобится 5-я машина, количество удваивается. Шестая машина снова удвоится. Вы можете не думать, что вырастете в будущем, но вы будете.
Если бы ты собирался scp каждый файл после его создания, это будет 3 scp команды каждый раз при запуске script.php. Учитывая, сколько времени требуется scp для аутентификации сеанса, это может занять 1-2 секунды на запуск. Это 60 scpс в секунду.
Вместо этого вы можете просто создать файлы и запустить другой процесс. rsync в петле. Каждый раз при запуске rsync выбирает новые файлы. Время между созданием файла и его отправкой на другие серверы составляет секунды или минуты. Это нормально, если вы хотите делать резервные копии данных и можете выдержать некоторую потерю данных в случае незапланированного отключения. Недостаточно, если вы хотите, чтобы другие серверы получали информацию немедленно.
С другой стороны, если вы используете базу данных, все 3 машины будут иметь кэшированные соединения с базой данных, и обновления будут очень быстрыми. Данные будут доступны мгновенно.
rsync предназначен для односторонней синхронизации между 1 источником и 1 местом назначения. Он не подходит для надежной двусторонней синхронизации между 4 хостами.
Инструмент синхронизации, такой как SyncThing или BitTorrent Sync, может работать, хотя скорость изменения ваших файлов (20 в секунду) может быть слишком высокой для таких инструментов.
Я предлагаю назначить один из серверов "главным" (в качестве альтернативы, настроить 5-ю машину или NAS) и подключить к сети (например, NFS). /arc со всех других машин на этот мастер, поэтому сценарий на каждой машине фактически работает в одном каталоге.
Другой вариант, если вы не можете полагаться на одну машину, на которой размещен каталог, - это использовать что-то вроде DRBD для создания распределенного блочного устройства, которое может реплицироваться на уровне блоков по сети.
Если у вас есть хороший контроль над своими серверами, то я думаю, что создание сервера обмена сообщениями, такого как RabbitMQ, может быть лучшим решением. Вместо того чтобы создавать файлы, вы помещаете сообщения в очередь, и ваш сценарий подписывается на эти события очереди, выполняет обработку, а затем помещает результаты обратно в очередь, чтобы их забрали другие серверы.
Я не думаю, что rsync - лучший вариант. lsyncМодель может быть интересна тем, что отслеживает события ядра на предмет изменений, но это схема «главный / подчиненный», и я не уверен, что она сработает в вашей ситуации.
Как предлагает @Andy, вам может быть лучше с какой-то общей сетевой файловой системой. (NFS, GFS, Gluster) приходят на ум, и их гораздо больше. Однако будьте осторожны с проблемами блокировки и с тем, что произойдет, если соединение с файловым сервером будет прервано.
Ответ @ TomOnTime, вероятно, правильный, поскольку он говорит, что файловая система, вероятно, неправильный выбор. Основное достоинство решения на основе SQL заключается в том, что у вас, вероятно, уже настроен сервер БД. Однако существует больше ловушек, чем вы можете себе представить, делая подобные вещи эффективными в SQL.
РЕДАКТИРОВАТЬ:
Если, как вы говорите, это система кеширования, вы также можете посмотреть memcached, redis или даже varnish.
Знают ли ваши приложения заранее, что они ожидают в кэше, без необходимости запрашивать список?