IPFS: независимые копии выпуска
Один закреплённый выпуск на одном компьютере остаётся одной копией. Библиотека хочет пережить отказ устройства и уход поставщика. В уроке подготовим опись независимых реплик и собственного архива, сохраняя возможность получить тот же корень без зависимости от одного домена.
Никакие аккаунты не создаются, услуги не оплачиваются, API не вызываются. Пример описывает требования к будущему хранению. Текущая работа не подтверждает фактическое наличие внешних реплик.
Независимость копий
Два URL не обязательно означают два независимых места хранения. Они могут обращаться к одному серверу, одному аккаунту или тому же неполному источнику. Для резервирования важно, кто действительно располагает байтами и какая общая причина отказа может затронуть копии.
Определим три места: собственный постоянный blockstore, хранитель A и хранитель B. У каждого есть отдельный статус. Дополнительно библиотека хранит переносимый архив CAR и исходный каталог выпуска. Архив позволяет восстановить блоки, а исходники — повторить подготовку при сохранённом профиле.
| Копия | Основание наличия | Общая зависимость |
|---|---|---|
| Собственное хранилище | Опись и чтение нужного набора | Устройство и оператор |
| Хранитель A | Завершённое закрепление и получение | Аккаунт и инфраструктура A |
| Хранитель B | Независимый завершённый набор | Аккаунт и инфраструктура B |
| Архив | Сохранённые байты и корни | Место архивного хранения |
Таблица показывает, что статусы нельзя вывести из одной записи uploaded=true. Завершение загрузки на сервер ещё не доказывает поддержку всего DAG или независимость копии.
Проверка состава
Для маленького выпуска можно перечислить файлы и контрольные суммы. Для block-архива также нужно определить корни и полноту достижимого набора. Если два хранителя имеют только release.json, учебные страницы могут отсутствовать, хотя обе проверки манифеста проходят.
Критерий полноценной реплики — способность восстановить объявленные файлы по выбранному маршруту. Для долгосрочного архива полезна также возможность экспортировать данные в переносимом формате. Если сервис выдаёт файлы только через закрытый собственный API, стратегия ухода должна это учитывать.
Сверка проводится с доверенным досье, а не с метаданными, которые поставщик сам прислал рядом с объектом. Иначе подмена корня может быть согласованной внутри ответа. Сеть реестра и объявленный SHA-256 манифеста остаются независимым основанием идентичности.
Последовательность выпуска
Сначала подготовлены байты и профиль. Затем построено представление и получены вычисленные значения. Затем реплики достигают подтверждённой стадии хранения. После этого редакция объявляет выпуск для читателей. Если объявление предшествует хранению, сайт должен честно показать стадию подготовки.
Второй хранитель получает тот же объект, а не новую сборку с текущим временем в HTML. Если импорт повторяется из исходников, сверяется профиль и корень. Если корень отличается, нужно выяснить причину до заявления, что это идентичная реплика.
Архив выпуска создаётся из уже определённого набора и связывается с его корнем. Сам архив может иметь собственную файловую контрольную сумму. Это значение относится к байтам контейнера и не заменяет корневой CID внутреннего DAG.
Статусы и сроки
У каждой реплики сохраняем время последней сверки и договорный срок хранения. Старый успешный ответ не доказывает текущую доступность. Поставщик может изменить тариф, удалить задачу после прекращения договора или оказаться недоступным.
Для редакции полезны состояния requested, complete, degraded, unknown и retired. Неизвестность после тайм-аута не означает немедленное удаление байтов. Вместо удаления записи сохраняем последнее основание и новую причину невозможности сверки.
Если один хранитель отказал, второй может продолжать выдачу. Но система должна начать восстановление необходимого количества копий, а не жить бесконечно в ухудшенном состоянии. Число копий — выбранная политика библиотеки, которую периодически пересматривают по реальным условиям.
Переезд поставщика
CID позволяет обращаться к содержанию у нового места без изменения самого объекта. Однако сначала новый хранитель должен получить все необходимые данные. Старую копию не удаляем только потому, что новый аккаунт создан и получил имя.
Сохраняем переход: запрос переноса, подтверждение нового набора, независимое получение, обновление операционных указателей, затем прекращение старого договора. Публичные ссылки на конкретный шлюз могут требовать изменения, но идентификатор выпуска остаётся прежним.
IPNS или DNSLink могут помочь управлять текущим указателем, однако не создают копии. Их изменение относится к обнаружению и рекомендации. Резервирование относится к байтам и возможностям выдачи.
Два адреса с одной точкой отказа
Предположим, библиотека записала два шлюза: один быстрый региональный адрес и один резервный. Оба принадлежат одному поставщику и читают из одного внутреннего хранилища. Отказ общего аккаунта или удаление закрепления способен затронуть оба адреса одновременно. Различие DNS-имён не доказывает независимость байтовых копий. Для нашей описи это два маршрута выдачи одной административной реплики, если иное не подтверждено устройством хранения.
Теперь добавим собственный CAR на отдельном носителе. Он создаёт независимый путь восстановления при условии полноты и исправности самого архива. Пока носитель отключён и данные не предоставляются сети, он не заменяет доступный HTTP-ответ для обычного читателя. Поэтому опись различает оперативную копию и восстановительный запас. Обе полезны, но отвечают на разные вопросы: что можно получить сейчас и из чего можно восстановить выдачу позже.
Для каждой административно независимой копии записываем владельца, корень, объём охвата, срок удержания и способ доступа. Если внешняя услуга зависит от единственного аккаунта редакции, потеря полномочий может лишить управления всеми закреплениями этого аккаунта. Содержательно правильные CID не восстановят токен и не продлят договор хранения. Процедура резервирования полномочий поэтому соседствует с архивом данных, не смешиваясь с ним.
При смене поставщика сначала обеспечивают новый набор, затем подтверждают требуемое получение, и лишь после согласованного перехода прекращают прежнее удержание. Нельзя назвать намерение создать копию готовой репликой. Расходы оцениваются по фактическим условиям, объёму и маршрутам, без обещания универсальной бесплатной вечности. Результат для библиотеки — ясная матрица зависимостей: доступность по двум адресам, самостоятельное хранение у разных участников и возможность восстановления из проверяемого собственного архива учитываются отдельно.
Результат описи
Для библиотеки готова модель: вычисленный корень, точные байты манифеста, профиль импорта, три независимых статуса и архив. Пока нет выполненного импорта и внешних операций, реальные поля остаются незаполненными. Мы не называем это состоявшимся резервированием.
Подходы описаны в документации удалённого pinning и спецификации CAR. После урока два красивых адреса перестают быть достаточным доказательством двух копий. Следующая страница разберёт асинхронную задачу закрепления и её промежуточные состояния.