Организация работы воркеров через распределённую файловую систему

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

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

существует REDIS - это его типичное дело (одно из). Раздавать задачи воркерам и собирать отчёты.

а файлы хранят в файловом хранилище :-) других способов хранить файлы мир ещё не знает. RAID-массив, сетевой NAS, облако..тебе не пофик ? сохранилось и ок

Чтобы всё корректно работало, чтение/запись в дерево должны выполняться через транзакции.

Переименование файла/каталога операция атомарная. Думаю, на этом можно наворотить любую нужную транзакцию.

Файловая система плохая абстракция для распределенных(сетевых) систем. По возможности избегай её.

Это кажется более наглядным и удобным для дебага, чем миллион разных очередей и файловое хранилище в облаке.

Если это какая-то исследовательская работа, то аргумент. Если это система для использования в реальном мире, то это не аргумент. А для дебага напиши себе тулзу, которая будет выводить данные в виде дерева, если оно тебе так нравится

Володя, всё это пытались городить ещё в 80-х и оттуда ушли к базам данных.

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

а чтение содержимого каталога и открытие файла на чтение/запись не атомарны. можно прочитать каталог, а потом влезть в файл, который уже удален/перемещен :)

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

Ну так захватывай «блокировку» перед тем как читать/удалять файл.

ФС подойдет для публикации (в режиме write once) и хранения данных. Если один и тот же файл будет активно перезаписываться (упаси боже, ещё и по частям разными воркерами), то ФС может и не подойти, может быть с БД будет лучше, поскольку у БД хотя бы внятный transaction isolation level есть.

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

Если ты что-то серьезное пытаешься делать, то лучше возьми готовую реализацию task queue / message broker, с готовыми отладочными инструментами.

Я понимаю что распределённая файловая система это боль. Делать вид будто можно работать с чем-то асинхронным по своей природе через синхронный интерфейс это дорога в ад.

С другой стороны, сама задача прямо приглашает организовать данные иерархически.

Я надеялся что есть что-то похожее на файловую систему, пусть и не совсем она.

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

Не-не, реальную ФС я не собирался использовать.