IPFS: постоянное хранилище блоков
Клиент смог бы добавить выпуск, но где останутся его блоки после завершения программы? В уроке отделим память процесса от постоянного хранения, а также blockstore от служебного datastore. Результат — договор сохранения, который позволяет восстановить тот же выпуск без повторного импорта исходников.
Используем профиль API Helia 7 и каталог библиотеки. Никакие пакеты не устанавливаются, дисковое хранилище не открывается, браузерная база не создаётся. Мы описываем варианты и ожидаемое поведение, а не сообщаем о проверенном сохранении.
Память процесса
Хранилище в памяти удобно для короткого примера. После остановки или перезапуска его данные могут исчезнуть. Вычисленный CID при этом остаётся правильным именем ожидаемого объекта, но наличие имени не означает наличие байтов.
Представим, что редакция сохранила только строку ROOT_CID и закрыла программу с временным blockstore. Если независимых копий нет, читатель может не получить выпуск. Никакая обратная функция CID не восстановит полный учебник из короткого идентификатора.
Поэтому этап imported отличается от durably_stored. Первая стадия сообщает о построенном представлении. Вторая требует сохранения нужных блоков и подтверждённой процедуры дальнейшего доступа. Для готового выпуска библиотека должна достичь обеих стадий.
Блоки и служебные сведения
Blockstore хранит содержимое блоков по их идентификаторам. Datastore используется для необходимого служебного состояния выбранного клиента и модулей. Конкретная роль данных зависит от реализации, поэтому нельзя считать любой из двух каталогов взаимозаменяемой копией другого.
| Слой | Пример вопроса |
|---|---|
| Blockstore | Есть ли байты нужного файла и структурных узлов? |
| Datastore | Есть ли требуемые метаданные клиента и модулей? |
| Опись выпуска | Какие корни и профили объявлены? |
| Исходники | Можно ли повторить подготовку при потере блоков? |
Если сохранены только блоки, некоторые служебные решения вроде удержания или именования могут потребовать восстановления. Если сохранены только метаданные, ссылки не создадут отсутствующие байты. Досье перечисляет оба слоя и объясняет, что требуется конкретной операции.
Диск сервера
Для серверной подготовки выпуска удобно использовать постоянное дисковое хранилище совместимого модуля. Официальные реализации blockstore-fs и datastore-fs показывают соответствующие интерфейсы. В будущем проект закрепляет версии и задаёт отдельные пути, не смешивая их с временными файлам редактора.
Процесс должен открывать и завершать ресурсы по правилам модулей. Два независимых экземпляра, одновременно пишущие в одну структуру без поддерживаемой координации, могут иметь ограничения. Поэтому не используем общий путь как случайный способ объединить клиентов.
Права операционной системы определяют, кто может читать и изменять файлы. Открытые учебные материалы не требуют секретности содержания, но нарушение целостности или удаления может помешать доступности. Если хранятся зашифрованные контейнеры или служебные ключи, требования различаются и записываются отдельно.
Браузерное хранение
В браузере постоянные интерфейсы могут опираться на IndexedDB и другие поддерживаемые механизмы. Это удобнее памяти для повторного открытия страницы, но не даёт гарантии бессрочного архива. Пользователь может очистить данные, браузер применяет квоты, а origin влияет на доступ к хранилищу.
Учебная библиотека не должна обещать, что один просмотр автоматически сохранил все уроки для будущего офлайн-чтения. Клиент должен получить нужные части, дождаться сохранения и показать конкретный состав. Очистка одного сайта может удалить локальную копию, не затрагивая внешних хранителей.
Если разные выпуски открываются на разных поддоменах CID, их браузерные origin также различаются. Это важно для изоляции, но может влиять на повторное использование локального хранилища. Следующий раздел шлюзов вернётся к этому компромиссу.
Удержание и уборка
Постоянный диск сам по себе не означает, что все блоки будут сохраняться по выбранной политике уборки. Закрепление и сборка мусора — отдельные механизмы. Библиотека должна явно обозначить необходимые корни и процедуру удержания.
Один общий блок может использоваться несколькими выпусками. Удаление файла из нового каталога не означает, что блок больше никому не нужен. При уборке учитываются живые корни и ссылки. Ручное удаление по имени локального файла не заменяет понимание content-addressed-структуры.
Для старых редакций определяем срок доступности. Если они обещаны читателям как архив, их корни остаются в описи хранения. Если поддержка заканчивается, неизменный CID не начинает указывать на другую версию: просто может исчезнуть возможность получить данные у наших хранителей.
Остановка во время сохранения
Представим, что импортёр передал блоки хранилищу и процесс аварийно завершился до прикладного объявления готовности. При следующем открытии часть данных может присутствовать, но сама по себе эта ситуация не доказывает полный выпуск. Досье различает выполненную запись отдельного блока и подтверждённую стадию сохранения всего достижимого набора. Конкретные гарантии фиксации зависят от выбранного хранилища, поэтому здесь нельзя обещать универсальную транзакцию на весь DAG.
Прикладной журнал хранит завершённый корень только после достижения согласованного критерия. Если после сбоя статус неизвестен, будущий процесс исследует фактическое содержимое и продолжает подготовку либо восстанавливает копию. Он не меняет объявленный корень на новый только ради того, чтобы получить успешный ответ. Идентичность выпуска остаётся независимой от состояния локального диска.
В браузере похожий сценарий возникает при заполнении квоты. Успешно полученное оглавление и несколько сохранённых уроков ещё не означают, что все материалы доступны офлайн. Интерфейс полезно связывать с описью: какие элементы сохранены, какие не завершены и сколько данных требуется дополнительно. Если пользователь очистил хранилище, список локально доступных материалов пересматривается. Старый флаг интерфейса «скачано» не создаёт отсутствующие блоки.
Резервная копия диска также имеет разные уровни. Снимок blockstore сохраняет байты; служебные данные могут описывать удерживаемые корни и другие решения клиента. Внешняя опись выпуска позволяет заново связать сохранённые объекты с курсом. Исходники с профилем дают ещё один маршрут восстановления, но требуют повторной подготовки и проверки результата. Для библиотеки выбираем конкретный набор этих слоёв, а не называем любой каталог «полным бэкапом». Такой договор помогает понять, что именно будет восстановлено после потери процесса, браузерных данных или целого компьютера.
Критерий сохранения
Ожидаемый будущий разбор включает остановку клиента, повторное открытие с тем же профилем и чтение известного корня без повторного импорта. Для полного выпуска также проверяется доступность всех достижимых частей. Сейчас такой опыт не проведён, поэтому статус — подготовленная модель постоянного хранения.
Интерфейсы описаны в js-stores, включая blockstore-fs и blockstore-idb. После урока библиотека отличает сохранённое имя от сохранённых байтов и может определить, какие слои нужны для повторного получения выпуска.