Распределённая соцсистема: протокол хранения файлов

Конкретный способ обеспечения избыточности скрыт конкретной реализацией. Это в рамки протокола не входит.

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

Система состоит из трёх основных классов нод:

• Собственно, файловые хранилища. Которые обеспечивают:
• Отдачу файла, запрошенного по системному URL.
• Преобразование UUID в системный URL
• Отдачу полного списка всех файлов в хранилище
• Диспетчеры, которые обеспечивают:
• Регистрацию хранилищ
• Определение хранилища и/или системного URL по UUID
• Определение UUID по оригинальному URL файла для случаев архивного хранения
• Архивные сервера для связки оригинальных URL и UUID/системных URL.

Возможные сценарии работы.

Объекты соцсети, взаимодействующие с файлами (аттачи топиков, кешированные картинки и т.п.) хранят для каждого объекта UUID и/или оригинальную ссылку.

Для варианта с UUID при компиляции в конечный HTML идёт запрос к диспетчеру, который для UUID возвращает системный URL на одном из файловых серверов.

TODO: необходимо продумать вариант обновления HTML при отказе назначенного файлового хранилища. Либо осуществлять такую замену динамически (естественно, с локальным кешированием)

Для варианта с исходной ссылкой:
— Транслятор в HTML запрашивает архивный сервер и получает системный URL.
— Если на архивном сервере нет зарегистрированного оригинального URL, он запрашивает его у диспетчера и если диспетчер знает такой, то вернёт от него UUID/системную ссылку
— Если диспетчер ссылку не знает, архивный сервер скачивает запрашиваемый файл с источника и сам определяет UUID.
— Полученный UUID запрашивается у диспетчера. Если найден, скаченный файл игнорируется, диспетчер и архив запоминают привязку оригинального URL и UUID
— Если по UUID файла в системе нет, архив заливает его либо диспетчеру для передачи в хранилище, либо прямо хранилищу, указанному диспетчером

TODO: продумать совмещение архивного сервера и диспетчера