Асинхронная работа ZipArchive (::addFromString) теряет файлы, как победить?

Question

[Vertexis]

Входные данные:
OS: Debian 9
PHP: v7.4
Есть директория с ~1КК файлов {unixtime}.json размером до 1Мб.
Делаю переименование файлов с его изменением внутреннего содержимого, а потом пытаюсь запаковать их все в один архив с помощью метода addFromString.
Суть проблемы в том, что при асинхронном использовании методов ZipArchive, на выходе я получаю нужных архив, но только с последним обработанным файлом в рамках асинхронности (Если быть совсем точным, то в архив попадает N/t файлов, где N - всего файлов к добавлению, t - количество потоков обработки)

Привожу ниже упрощенную схему работы ($dir,$newFileName, $stringData определены к этому моменту ):

$za = new \ZipArchive();
 ($za->open($zipFile, \ZipArchive::CREATE) !== TRUE) {
      throw new \Exception('Cannot create a zip file');
 } 
$arFile = $dir . '/' . $newFileName . '.json';
$result = $za->addFromString($arFile, $stringData);
$error = $za->getStatusString( );
$arIndex = $za->locateName($arFile);
$arInfo = $za->statName($arFile);
$closeResult = $za->close();
 var_dump($error, $arIndex, $arInfo, $closeResult);

Вывод

4 => string(8) "No error"
int(0)
array(8) {
["name"]=>
string(23) "/orders/01_01_2021.json"
["index"]=>
int(0)
["crc"]=>
int(0)
["size"]=>
int(1006)
["mtime"]=>
int(1617438268)
["comp_size"]=>
int(1006)
["comp_method"]=>
int(0)
["encryption_method"]=>
int(0)
}
bool(true)

Как видно, файл успешно добавляется , имеет свой индекс и существует до момента закрытия архива.
Еще момент, при асинхронном добавлении получается, что в рамках числа потоков добавляемые файлы имеют один и тот же индекс (в моем случае 0), что по видимому и приводит к "потере" добавляемых файлов. Возможно это не правильное назначение индексов , но повлиять я на нее не могу. Как это можно победить?
PS- записывать промежуточные файлы не хотелось бы. Изначальное наличие архива не меняет ситуацию.
Спасибо за помощь!

Comments

[Дмитрий]

ну и где код асинхронности?

[Vertexis]

Так проблема не с асинхронностью, с ней все хорошо. Реализация через proc_open.
В теории можно выполнить код асинхронно и через баш

[Дмитрий]

Vertexis, сделайте сначала без асинхрона рабочий код, я бы использовал для этого RecursiveDirectoryIterator
Возможно ошибка где то в коде, не явная

[Vertexis]

Дмитрий, в один поток все работает и сохраняет нормально. Но соответственно это выливается в более долгий по времени процесс. При наличии кучи ядер процесса, трудится только один.
PS - был еще вариант использования exec для работы с ZIP силами шела операционки, но это костыльный метод

[Дмитрий]

Vertexis, а как вы делите файлы между потоками?

[Vertexis]

Дмитрий, они все обозначены в БД, по ней и ориентируюсь о категории файла и был ли он обработан мной или нет

[Дмитрий]

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

[Vertexis]

Дмитрий, Давай соберу пример из 6 файлов (index.php, run.sh, file1.json, file2.json, file3.json, file4.json) и дам пощупать. Только это сделаю завтра

[Vertexis]

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

[Дмитрий]

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

[Vertexis]

Дмитрий, Нет, не совсем так:
1) документация говорит, что "ZipArchive::CREATE (int) Создавать архив, если он не существует." .т.е. не надо менять метод открытия в зависимости от наличия архив-файла;
2) Уже экспериментировал и писал в общем описании. Как писал в описании основной проблемы "Изначальное наличие архива не меняет ситуацию."

Answer 1

[s5656]

Ну давайте обратимся к документации и попробуем понять в какой момент происходят изменения в конечном файле:

ZipArchive::close — Close opened or created archive and save changes. This method is automatically called at the end of the script.

То есть либо при вызове ZipArchive::close, либо в конце скрипта (так как автоматически вызывается ZipArchive::close).

Сам по себе ZipArchive — синхронный.
Если в одном потоке, то вы создаете и редактируете один архив, через один объект ZipArchive и когда вызываете close — все сохраняется в файл, на диск.
Если вы работаете в нескольких потоках, то у вас создается несколько ZipArchive, которые друг о друге ничего не знают и когда вы вызываете close — каждый из них пытается сохранить свои изменения и здесь уже кто последний тот и папа сохранил свою версию.

Нужно либо как-то передавать экземпляр ZipArchive между вашими потоками, либо писать свою (или найти готовую) библиотеку для асинхронной работы с zip архивами.

Как более простой вариант — делать работу с файлами асинхронно (во временной директории?), а затем их архивировать через тот же zip (консольную утилиту).

Comments

[Vertexis]

Использовать шел, это как раз тот вариант от которого пытаюсь уйти ,т.к. он далек от IoC
"и когда вы вызываете close — каждый из них пытается сохранить свои изменения и здесь уже кто последний тот и папа сохранил свою версию". Сохраняют то все и статусы у всех успешные, но получается это не у всех по факту. Да понятие последнего очень размывчато, т.к. в рамках потоков одни джобы заменяютя на другие плавно и без простоев. И последний, а точнее крайний всегда один в конце списка.
PS - Сейчас сделал костыль, который не дает закрыться джобу, пока по факту не появится файл в архиве. Как говорится, доверяй, но проверяй..

[s5656]

Vertexis,

Сохраняют то все и статусы у всех успешные, но получается это не у всех по факту.

Ок, объясню проще: у вас создается столько архивов, сколько у вас потоков, но все они в памяти, до поры до времени. Затем каждый поток пытается их сохранить в один и тот же файл. И они перезаписывают один и тот же файл.

Использовать шел, это как раз тот вариант от которого пытаюсь уйти ,т.к. он далек от IoC

Тогда может и БД не пользоваться?) Использование внешних средств не противоречит чему бы то ни было, вопрос в реализации.