Масштабный импорт может завершиться сбоем из-за обрыва соединения, некорректных данных или ограничения времени выполнения процесса. Если все изменения зависят от одной транзакции, система может слишком долго удерживать блокировки и потерять всю работу, подтверждённую только в конце. Если же сохранять каждую строку отдельно, не предусмотрев план восстановления, сбой может привести к несогласованности данных.
Проектирование пакетных транзакций при импорте данных в PHP заключается в выборе единиц работы, которые можно безопасно фиксировать, регистрировать и выполнять повторно. Это не означает, что весь импорт становится атомарным: обычно каждый пакет атомарен сам по себе, а процесс в целом может быть применён частично. Это различие должно учитываться и в реализации, и в операционных сценариях.
Почему одна транзакция может быть неуместна
Длительная транзакция может удерживать блокировки, увеличивать нагрузку на журнал транзакций и конкурировать с запросами приложения. Если импорт обрабатывает миллионы строк, также трудно понять, сколько работы осталось и что делать после сбоя. Точное поведение зависит от СУБД, уровня изоляции и объёма записей, поэтому его следует измерять в реальной среде.
Фиксация каждой строки сокращает длительность отдельной транзакции, но может увеличить затраты на фиксации и привести к частичному применению зависимых друг от друга строк. Пакет служит промежуточным вариантом: если операция в группе завершается ошибкой и исключение передаётся дальше, откатывается эта группа; ранее зафиксированные пакеты сохраняются. Приложение должно сообщать о частичном прогрессе, а не об общем успехе или полном откате.
Выбор подходящей границы транзакции
Единица работы не обязательно должна всегда содержать фиксированное число строк. Она должна представлять изменения, которые можно согласованно проверить и сохранить. Если каждая запись независима, может быть достаточно пакета строк. Если несколько записей составляют бизнес-сущность — например, заголовок и его строки, — их обработка в одной транзакции позволит не сохранять неполную сущность.
Выбирая размер пакета, оценивайте длительность его обработки, объём памяти, конкуренцию за общие таблицы, частоту ошибок и стоимость повторной обработки. Большой пакет сокращает число фиксаций, но обрабатывается дольше и увеличивает объём работы, которую придётся повторить при сбое. Маленький пакет ограничивает эти затраты, но увеличивает накладные расходы и может снизить производительность. Универсального размера нет: начните с настраиваемого значения и корректируйте его по результатам репрезентативных нагрузочных тестов.
В PHP не загружайте весь файл в память, если его можно читать последовательно. Считайте ограниченную группу строк, проверьте их поля, начните транзакцию, выполните записи и зафиксируйте её. При ошибке откатите транзакцию пакета и классифицируйте сбой. Например, с PDO управление транзакцией можно реализовать с помощью beginTransaction(), commit() и rollBack(); обработка исключений должна гарантировать, что для неудачной транзакции не будет предпринята попытка фиксации.
Сохранение прогресса для надёжного возобновления
Контрольная точка показывает, какая часть источника была обработана и зафиксирована. Это может быть стабильный идентификатор, позиция в файле или составной ключ — при условии, что он позволяет продолжить обработку, не полагаясь на меняющийся порядок. При постраничном чтении обычно безопаснее использовать стабильный ключ, а не смещение, которое может измениться, если во время процесса записи добавляются или удаляются.
Прогресс и изменения пакета должны быть согласованы. Если это возможно, сохраняйте бизнес-изменения и новую контрольную точку в одной транзакции. Тогда при сбое процесса до фиксации не будет зарегистрирован прогресс, который база данных не применила; при фиксации курсор также продвинется. Если состояние выполнения находится в другой системе, такой автоматической атомарности нет: нужно спроектировать механизм согласования или допустить повторную обработку пакетов и обеспечить их идемпотентность.
Также сохраняйте идентификатор импорта, его статус, контрольную точку, счётчики и, если необходимо, ссылку на версию или хеш файла. При возобновлении убедитесь, что используется тот же входной файл и выполнение можно восстановить. Определите явные статусы, например «ожидает», «выполняется», «завершено» и «завершилось ошибкой», а также порядок действий для обнаружения заброшенных запусков. Не помечайте импорт как завершённый только потому, что процесс завершился без исключения: проверьте, что достигнут ожидаемый конец.
Изоляция ошибок и управление повторами
Заранее решите, должен ли некорректный объект останавливать весь процесс, исключаться из него или помечаться для проверки. Для ожидаемых ошибок формата может быть полезно провести валидацию до открытия транзакции и записать причину вместе с идентификатором строки. При ошибках сохранения откатывайте затронутый пакет. Продолжать обработку следующих пакетов разумно только в том случае, если их данные независимы и импорт можно явно обозначить как частичный.
Различайте постоянные ошибки — например, отсутствие обязательного значения — и временные сбои, такие как восстанавливаемый обрыв соединения. Повторная попытка после постоянной ошибки расходует ресурсы и затрудняет диагностику. Для временного сбоя, напротив, можно использовать ограниченное число попыток с увеличивающейся задержкой. Если все попытки исчерпаны, сохраните достаточно состояния и контекста, чтобы выяснить причину и возобновить обработку, не скрывая исходную ошибку.
При неосторожной реализации повторы могут привести к повторной записи данных. Используйте бизнес-ключи или идентификаторы источника, чтобы распознавать уже импортированные записи, и определите, должна ли повторная обработка добавлять запись, обновлять её, пропускать или отмечать конфликт. Уникальные ограничения в базе данных могут подкрепить это решение, но не заменяют бизнес-логику. Не полагайтесь только на контрольную точку как на механизм защиты от дубликатов: она может устареть или не учитывать изменения, внесённые другим способом.
Если пакет также отправляет электронные письма, публикует сообщения или вызывает API, транзакция базы данных не может отменить эти внешние эффекты. Не выполняйте такие операции так, будто они входят в несуществующую распределённую транзакцию. Один из вариантов — записывать ожидающее событие в транзакционную таблицу исходящих сообщений, а затем обрабатывать его с повторами и идемпотентными идентификаторами. Если внешний эффект не удаётся выполнить, состояние должно позволять восстановить обработку, не дублируя операцию и не утверждая, что пакет завершён полностью.
Проверка согласованности, прогресса и восстановления
Тесты должны охватывать не только штатный сценарий. Имитируйте сбои до начала транзакции, во время записи, непосредственно перед фиксацией и после фиксации, но до обновления любого внешнего состояния. Проверьте, какие данные сохраняются, какая контрольная точка остаётся и приводит ли возобновление к ожидаемому результату. Включите дубликаты записей, некорректные строки, пустые пакеты и ошибки сохранения.
В репрезентативном тесте измеряйте длительность обработки пакета, потребление памяти, частоту ошибок, время удержания блокировок и прогресс. Также убедитесь, что счётчики различают прочитанные, принятые, отклонённые и зафиксированные строки: показатель «обработано» может быть неоднозначным, если в него входят отменённые изменения. В метриках и журналах следует указывать идентификаторы импорта и пакета, не записывая конфиденциальные данные, не нужные для диагностики.
Контрольный список перед запуском в production
- Единица транзакции соответствует согласованной бизнес-единице.
- Размер пакета настраивается и проверен на репрезентативных данных и нагрузке.
- Контрольная точка продвигается только после фиксации соответствующего пакета.
- Стратегия возобновления использует стабильный ключ и распознаёт исходные данные.
- Для постоянных и временных ошибок предусмотрены разные способы обработки, позволяющие отслеживать их.
- Повторные операции идемпотентны или явно обнаруживают конфликты.
- Внешние эффекты обрабатываются с помощью отдельной стратегии, допускающей восстановление.
- Тесты проверяют сбои на разных этапах, а не только выполнение целиком.
Цель не в том, чтобы исключить любые сбои, а в том, чтобы ограничить их последствия и явно показывать итоговое состояние. Продуманные границы транзакций, согласованные контрольные точки и безопасные повторы позволяют восстановить импорт в PHP, не принимая частичный прогресс за завершение и не применяя повторно уже зафиксированные изменения.
