Предыдущая статья《Опыт устранения неполадок параллелизма FastDFS«Представляет опыт устранения неполадок с параллелизмом в рабочей среде. Некоторые люди могут не иметь специального представления о FastDFS, поэтому я планирую написать несколько статей, чтобы полностью представить это программное обеспечение.
Зачем использовать распределенную файловую систему?
Ну, это хороший вопрос, в чем преимущества его использования для нас? Давайте рассмотрим этот вопрос:
Автономная эпоха
На начальном этапе из-за нехватки времени и ограниченных ресурсов обычно создается статическая папка непосредственно в каталоге проекта, чтобы пользователи могли хранить файловые ресурсы в проекте. Если они разделены на разные типы, вы можете создать разные подкаталоги в каталоге проекта, чтобы различать их. Например:resources\static\file,resources\static\imgЖдать.
преимущество: Это удобнее делать, на проект можно напрямую ссылаться, а также просто реализовать, без каких-либо сложных технологий, а также очень удобно сохранять записи в базе данных и доступ.
недостаток: Если он используется только в фоновой системе, проблем обычно нет, но в качестве внешнего веб-сайта будут недостатки. С одной стороны, файлы и код связаны друг с другом, и чем больше файлов хранится, тем более хаотичен он; с другой стороны, если трафик относительно велик, доступ к статическим файлам будет занимать определенное количество ресурсов, влияя на нормальную работу. бизнес-операций и не способствует быстрому развитию веб-сайта.
Автономный файловый сервер
По мере того как бизнес компании продолжает расти, недостатки размещения кода и файлов на одном сервере будут становиться все более и более очевидными. Чтобы решить вышеуказанные проблемы и ввести независимый сервер изображений, рабочий процесс выглядит следующим образом: при загрузке файлов в проект сначала загрузите файлы в определенный каталог сервера изображений через ftp или ssh, а затем получите доступ к файлам в этот каталог через ngnix или apache и вернуть URL-адрес изображения независимого доменного имени, который считывается через этот URL-адрес, когда внешний интерфейс использует файл.
преимущество: доступ к изображениям потребляет много ресурсов сервера (поскольку он будет включать переключение контекста операционной системы и дисковые операции ввода-вывода). После разделения сервер веб-приложений может больше сосредоточиться на возможностях динамической обработки; независимое хранилище более удобно для делать расширение емкости, аварийное восстановление и миграцию данных, удобен для балансировки нагрузки запросов на доступ к изображениям, легко применять различные стратегии кэширования (HTTP Header, Proxy Cache и т. д.), а также удобнее мигрировать на CDN.
недостаток: узким местом в производительности является одна машина, а аварийное восстановление и вертикальная масштабируемость немного хуже.
Распределенная файловая система
Некоторые проблемы можно решить с помощью отдельного файлового сервера.Что, если служба, которая хранит файлы, внезапно выйдет из строя в один прекрасный день? Вы можете сказать, что файловая система регулярно резервируется.Когда эта машина не работает, можно быстро переключиться на другую машину, но этот процесс требует ручного вмешательства. Кроме того, что мне делать, если объем сохраненных файлов превышает 100T? Проблемы с производительностью на одном сервере? На этот раз мы должны рассмотреть распределенную файловую систему.
Бизнес продолжал развиваться, и хранилище и отклик одного сервера вскоре стали узким местом.Новому бизнесу требовался доступ к файлам с высокой скоростью отклика и высокой доступностью для поддержки системы. Распределенная файловая система обычно делится на три части для взаимодействия: хранилище служб, система арбитража доступа, система хранения файлов и система аварийного восстановления файлов.Система арбитража эквивалентна мозгу файлового сервера и определяется в соответствии с определенному алгоритму.За сохранение файлов отвечает место хранения файлов, файловая система хранения, а за взаимное резервное копирование файловой системы и самой себя — система аварийного восстановления.
преимущество: Масштабируемость: Несомненно, масштабируемость является важнейшей характеристикой распределенной файловой системы; высокая доступность: В распределенной файловой системе высокая доступность состоит из двух уровней, один — это доступность всей файловой системы, а другой — целостность данные и согласованность; эластичное хранилище: вы можете гибко увеличивать или уменьшать объем хранилища данных, а также добавлять или удалять ресурсы в пуле хранения в соответствии с потребностями бизнеса, не прерывая работу системы.
недостаток: система немного сложнее и требует больше серверов
FastDFS
То, что FastDFS принадлежит к той распределенной файловой системе, которую мы представили выше, сомнений не вызывает, рассмотрим ее подробнее:
Что такое FastDFS
FastDFS — это легковесная распределенная файловая система с открытым исходным кодом. Он решает проблемы хранения больших объемов данных и балансировки нагрузки. Он особенно подходит для онлайн-сервисов со средними и маленькими файлами (рекомендуемый диапазон: 4 КБ
FastDFS — это облегченная распределенная файловая система с открытым исходным кодом, реализованная на чистом языке C. Она поддерживает Linux, FreeBSD и другие системы UNIX, такие как google FS. Это не обычная файловая система, и доступ к ней возможен только через проприетарные API. Предоставляется. API предназначен для интернет-приложений, решает проблему хранения файлов большой емкости и обеспечивает высокую производительность и высокую масштабируемость. FastDFS можно рассматривать как систему хранения пар ключ-значение на основе файлов, это служба распределенного хранения файлов.
Возможности FastDFS:
- Файлы не хранятся блоками, а загружаемые файлы находятся во взаимно однозначном соответствии с файлами в файловой системе ОС
- Поддерживается только одна копия файлов с одинаковым содержимым, что экономит место на диске.
- Загружаемый файл поддерживает протокол HTTP, вы можете использовать встроенный веб-сервер или использовать его с другими веб-серверами.
- Поддержка онлайн-экспансии
- Поддержка файлов master-slave
- Атрибуты файлов (метаданные) могут быть сохранены на сервере хранения. Сетевая связь версии 2.0 использует libevent, поддерживает большой одновременный доступ и имеет лучшую общую производительность.
Понятия, связанные с FastDFS
Сервер FastDFS имеет три роли: сервер отслеживания, сервер хранения и клиент.
tracker server: Сервер отслеживания, в основном для планирования и балансировки нагрузки. Информация о состоянии всех групп хранения и серверов хранения в кластере записывается в память, которая является центром взаимодействия между клиентом и сервером данных. По сравнению с мастером в GFS он более компактен, не записывает информацию об индексе файла и занимает небольшой объем памяти.
Трекер является координатором FastDFS и отвечает за управление всеми серверами хранения и группами.После запуска каждого хранилища он подключается к Трекеру, информирует себя о группе и другой информации, к которой оно принадлежит, и поддерживает периодические пульсации.Трекер устанавливает группы в соответствии с к информации пульса хранилища.==> Таблица сопоставления [список серверов хранения].
Трекеру нужно управлять очень небольшим количеством метаинформации, и вся она будет храниться в памяти; кроме того, метаинформация на трекере генерируется информацией, сообщаемой хранилищем, и не требует сохранения каких-либо данных, что делает трекер очень легко расширяется и напрямую увеличивает трекер Машина может быть расширена, чтобы служить в качестве кластера трекеров Все трекеры в кластере полностью равны Все трекеры принимают информацию о сердцебиении от stroage и генерируют информацию метаданных для предоставления услуг чтения и записи .
storage server: сервер хранения (также известный как узел хранения или сервер данных), файлы и атрибуты файлов (метаданные) сохраняются на сервере хранения. Сервер хранения напрямую использует вызовы файловой системы ОС для управления файлами.
Сервер хранения (далее хранилище) организован в группы (тома, группы или тома).Группа состоит из нескольких машин хранения, и данные резервируются друг для друга.Место хранения основано на хранилище с наименьшим объемом в несколько хранилищ должны быть настроены одинаково, чтобы не тратить место в хранилище.
Организация хранилища в группы может облегчить изоляцию приложений, балансировку нагрузки и настройку количества копий (количество серверов хранения в группе — это количество копий группы).Например, за счет хранения разных данных приложений в разных группах, данные приложения могут быть изолированы.В то же время приложения могут быть распределены по разным группам для балансировки нагрузки в соответствии с характеристиками доступа приложений; недостаток заключается в том, что емкость группы ограничена емкостью хранения одной машины, и когда машина в группе сломана, восстановление данных может полагаться только на внутреннюю группу.Для других машин время восстановления будет очень долгим.
Хранилище каждого хранилища в группе зависит от локальной файловой системы.Хранилище может быть настроено с несколькими каталогами хранения данных.Например,есть 10 дисков,которые соответственно смонтированы на/data/disk1-/data/disk10, вы можете настроить эти 10 каталогов как каталоги хранения данных.
Когда хранилище получает запрос на запись файла, оно выбирает одну из директорий хранилища для хранения файлов в соответствии с настроенными правилами (описанными ниже). Чтобы избежать слишком большого количества файлов в одном каталоге, при первом запуске хранилища в каждом каталоге хранилища данных будет создано два уровня подкаталогов, по 256 подкаталогов на каждом уровне, всего 65536 файлов. записанные файлы будут хешированы.Метод направляется в один из подкаталогов, а затем данные файла сохраняются непосредственно в каталоге как локальный файл.
client: Клиент, как инициатор сервисного запроса, использует протокол TCP/IP для обмена данными с сервером трекера или узлом хранения через собственный интерфейс. FastDFS предоставляет пользователям базовые интерфейсы доступа к файлам, такие как загрузка, загрузка, добавление, удаление и т. д., которые предоставляются пользователям в виде клиентских библиотек.
Два других понятия:
group: Группа, также известная как том. Файлы на серверах в одной группе абсолютно одинаковы, и серверы хранения в одной группе одинаковы, и такие операции, как загрузка и удаление файлов, могут выполняться на любом сервере хранения.
meta data: Атрибуты, связанные с файлом, в формате пары "ключ-значение", например width=1024,heigth=768 .
Трекер эквивалентен мозгу FastDFS. Будь то загрузка или загрузка, ресурсы распределяются через трекер; клиенты обычно могут использовать статические серверы, такие как ngnix, для вызова или выполнения части кеша; сервер хранения внутренне разделен на тома (или группы). , тома Поскольку тома находятся в параллельных отношениях, их можно увеличить в любое время в соответствии с использованием ресурсов, а серверные файлы в томах резервируются синхронно друг с другом для достижения цели аварийного восстановления.
механизм загрузки
Сначала клиент запрашивает у службы Tracker IP-адрес и порт сервера хранения, а затем клиент запрашивает загрузку файла в соответствии с возвращенным IP-адресом и номером порта.После того, как сервер хранения получает запрос, файл создается, а содержимое файла записывается на диск и возвращается клиенту file_id, информация о пути, имя файла и другая информация, клиент сохраняет соответствующую информацию и загружает ее.
Внутренний механизм выглядит следующим образом:
1. Выберите сервер трекера
При наличии в кластере более одного трекер-сервера, поскольку трекеры полностью равны, клиент может произвольно выбирать трекер при загрузке файлов. Выберите сохраненную группу Когда трекер получит запрос на загрузку файла, он присвоит файлу группу, которая может сохранить файл.Поддерживаются следующие правила выбора групп:
- 1. Круговой опрос, опрос между всеми группами
- 2. Указанная группа, указать определенную группу
- 3. Баланс нагрузки, оставшееся место для хранения имеет больший групповой приоритет
2. Выберите сервер хранения
При выборе группы трекер подбирает сервер хранения в группе к клиенту, который поддерживает следующие правила выбора хранилища:
- 1. Round robin, опрос между всеми хранилищами в группе
- 2. Первый сервер отсортирован по ip, отсортирован по ip
- 3. Первый сервер отсортирован по приоритету, отсортирован по приоритету (приоритет настраивается на хранилище)
3. Выберите путь хранения
После того, как сервер хранения будет выделен, клиент отправит запрос на запись файла в хранилище, и хранилище выделит каталог хранения данных для файла, который поддерживает следующие правила:
- 1. Циклический опрос, опрос между несколькими каталогами хранения
- 2. Предпочтение отдается тому, у которого больше всего свободного места для хранения.
4. Создать идентификатор файла
После выбора каталога хранилища хранилище сгенерирует Fileid для файла, который объединяется с IP-адресом сервера хранилища, временем создания файла, размером файла, CRC32 файла и случайным числом, а затем base64 кодирует двоичную строку и преобразует ее в печатную форму. нить. Выберите двухуровневый каталог Когда каталог хранилища выбран, хранилище назначит файлу идентификатор файла. В каждом каталоге хранилища есть два уровня подкаталогов 256 * 256. Хранилище будет дважды хешировать (угадывать) в соответствии с идентификатором файла и направлять в один из подкаталогов. Затем сохраните файл в подкаталоге с идентификатором файла в качестве имени файла.
5. Создайте имя файла
Когда файл хранится в подкаталоге, считается, что файл успешно сохранен, и тогда для файла будет сгенерировано имя файла, состоящее из группы, каталога хранения, двухуровневого подкаталога, идентификатора файла и файла. суффикс (указывается клиентом. , в основном используется для различения типов файлов) соединяются вместе.
Механизм загрузки
Клиент передает информацию об имени файла, чтобы запросить службу Tracker для получения IP-адреса и порта сервера хранения, а затем клиент запрашивает загрузку файла в соответствии с возвращенным IP-адресом и номером порта, а сервер хранения возвращает файл. клиенту после получения запроса.
Как и при загрузке файла, клиент может выбрать любой сервер трекера при загрузке файла. Когда трекер отправляет запрос на загрузку трекеру, он должен передать информацию об имени файла.Трек анализирует группу файлов, размер, время создания и другую информацию из имени файла, а затем выбирает хранилище для запроса, чтобы обслуживать запрос на чтение . Так как файлы в группе синхронизируются асинхронно в фоновом режиме, может оказаться, что файлы не были синхронизированы с какими-то серверами хранения при их чтении.Чтобы максимально избежать обращения к такому хранилищу, трекер выбирает читаемые файлы в группе по следующим правилам хранения.
- 1. Исходное хранилище, в которое загружается файл — пока исходное хранилище существует, оно должно содержать файл, а исходный адрес закодирован в имени файла.
- 2. Временная метка создания файла == временная метка, с которой синхронизируется хранилище и (текущее время - временная метка создания файла) > максимальное время синхронизации файла (например, 5 минут) - после создания файла считается, что после прошло максимальное время синхронизации, оно должно быть синхронизировано с другим хранилищем.
- 3. Отметка времени создания файла
- 4. (Текущее время - Отметка времени создания файла) > Пороговое значение задержки синхронизации (например, один день). - По истечении порогового времени задержки синхронизации файл считается точно синхронизированным.
Синхронизированное управление временем
Когда файл успешно загружен, и клиент немедленно инициирует запрос на загрузку (или запрос на удаление) файла, как трекер выбирает подходящий сервер хранения? На самом деле каждый сервер хранения должен регулярно сообщать трекеру собственную информацию, которая включает в себя локальное время синхронизации (то есть отметку времени последнего синхронизированного файла). Трекер может знать, был ли только что загруженный файл синхронизирован в группе хранения, в соответствии с отчетным состоянием каждого сервера хранения. Информация о синхронизации сообщается следующим образом:
При записи файла, когда клиент записывает файл на сервер хранения в группе, файл считается успешно записанным.После того, как сервер хранения закончит запись файла, фоновый поток синхронизирует файл с другими серверами хранения в группе. та же группа.
После того, как каждое хранилище запишет файл, одновременно будет записан бинлог.Бинлог не содержит файловых данных, а содержит только метаинформацию, такую как имя файла.Этот бинлог используется для фоновой синхронизации.После перезапуска он может продолжаться для синхронизации с прогрессом последнего времени; прогресс записывается в виде временных меток, поэтому лучше следить за тем, чтобы часы всех серверов в кластере оставались синхронизированными.
О ходе синхронизации хранилища будет сообщаться трекеру как часть метаданных, и трекер будет использовать ход синхронизации в качестве ссылки при выборе чтения хранилища. Например, в группе есть три сервера хранения A, B и C. A синхронизируется с C с прогрессом T1 (файлы, записанные до T1, были синхронизированы с B), а B синхронизируется с C с отметкой времени T2. (T2 > T1), когда трекер получает эту информацию о ходе синхронизации, он сортирует ее и использует наименьшую из них в качестве метки времени синхронизации C. В этом примере T1 — это метка времени синхронизации C, то есть T1 (это то есть все данные, записанные до T1), были синхронизированы с C), точно так же, согласно приведенным выше правилам, трекер сгенерирует временную метку синхронизации для A и B.
Сложный файл ID-FID
Когда дело доходит до загрузки, мы должны упомянуть гениальный дизайн файлового индекса (также известного как: FID). Структура файлового индекса показана на рисунке ниже и представляет собой индексную информацию, возвращаемую сервером хранения клиенту после того, как клиент загрузит файл, которая используется для доступа к файлу в будущем. Информация индекса файла включает: имя группы, путь к виртуальному диску, двухуровневый каталог данных и имя файла.
- Имя группы: имя группы хранения, в которую загружен файл.После успешной загрузки файла сервер хранилища возвращается, и клиент должен сохранить его самостоятельно.
- Путь к виртуальному диску: виртуальный путь к конфигурации сервера хранения, соответствующий опции диска store_path*.
- Двухуровневый каталог данных: двухуровневый каталог, созданный сервером хранения для каждого пути виртуального диска для хранения файлов данных.
- Имя файла: отличается от того, когда файл был загружен. Он генерируется сервером хранения в соответствии с определенной информацией, а имя файла включает в себя: IP-адрес исходного сервера хранения, отметку времени создания файла, размер файла, случайное число, расширение файла и другую информацию.
Быстро найти файлы
Зная состав FID FastDFS, давайте посмотрим, как FastDFS находит файлы, к которым необходимо получить доступ через этот деликатный FID.
- 1. Средство отслеживания имен групп может быстро найти группу серверов хранения, к которой клиент должен получить доступ, и выбрать соответствующий сервер хранения для предоставления доступа клиенту;
- 2. Сервер хранения может быстро найти каталог, в котором находится файл, в соответствии с «путем виртуального диска хранилища файлов» и «двухуровневым каталогом файла данных», а также найти файл, к которому клиент должен получить доступ, в соответствии с именем файла.
Как собрать FastDFS? Обратитесь к этой статье в моем блогеКонфигурация установки кластера FastDFS, на следующем рисунке схематически представлена архитектура, созданная пользователем
Картинки в тексте взяты из интернета.
Ссылаться на
Официальный сайт
документ конфигурации
Java-клиент
Принцип построения распределенной файловой системы FastDFS
FASTDFS
Если вам понравилась моя статья, обратите внимание на мой публичный номер