Cassandra Architecture & Стратегия фактора репликации

Содержание:

Anonim

Cassandra предназначена для обработки больших данных. Основная функция Cassandra - хранить данные на нескольких узлах без единой точки отказа.

Причина такой архитектуры Cassandra заключалась в том, что отказ оборудования может произойти в любой момент. Любой узел может быть отключен. В случае отказа могут быть использованы данные, хранящиеся на другом узле. Следовательно, Cassandra разработана с ее распределенной архитектурой.

Cassandra хранит данные на разных узлах с одноранговой распределенной архитектурой моды.

Все узлы обмениваются информацией друг с другом по протоколу Gossip . Сплетни - это протокол в Cassandra, с помощью которого узлы могут общаться друг с другом.

В этом руководстве вы узнаете:

  • Компоненты Кассандры
  • Репликация данных
  • Запись Операция
  • Читать операцию

Компоненты Кассандры

В Cassandra есть следующие компоненты;

Схема архитектуры Кассандры
  • Узел

    Узел - это место, где хранятся данные. Это основной компонент Кассандры.

  • Дата центр

    Набор узлов называется центром обработки данных. Многие узлы относятся к категории центров обработки данных.

  • Кластер

    Кластер - это совокупность множества центров обработки данных.

  • Журнал фиксации

    Каждая операция записи записывается в журнал фиксации. Журнал фиксации используется для восстановления после сбоя.

  • Mem-таблица

    После записи данных в журнал фиксации данные записываются в Mem-таблицу. Данные временно записываются в Mem-таблицу.

  • SSTable

    Когда Mem-table достигает определенного порога, данные сбрасываются в файл на диске SSTable.

Репликация данных

Поскольку может возникнуть проблема с оборудованием или связь может быть отключена в любой момент во время обработки данных, требуется решение для обеспечения резервной копии, когда возникнет проблема. Таким образом, данные реплицируются, чтобы гарантировать отсутствие единой точки отказа.

Cassandra размещает копии данных на разных узлах на основе этих двух факторов.

  • Где разместить следующую реплику, определяется стратегией репликации .
  • При этом общее количество реплик, размещенных на разных узлах, определяется фактором репликации .

Один коэффициент репликации означает, что существует только одна копия данных, а три фактора репликации означают, что есть три копии данных на трех разных узлах.

Чтобы гарантировать отсутствие единой точки отказа, коэффициент репликации должен быть равен трем.

В Cassandra есть два типа стратегий репликации.

SimpleStrategy

SimpleStrategy используется, когда у вас всего один центр обработки данных. SimpleStrategy размещает первую реплику на узле, выбранном секционером. После этого оставшиеся реплики размещаются по часовой стрелке в кольце узлов.

Вот графическое изображение SimpleStrategy.

СетьТопологияСтратегии

NetworkTopologyStrategy используется, когда у вас более двух центров обработки данных.

В NetworkTopologyStrategy реплики настраиваются для каждого центра обработки данных отдельно. NetworkTopologyStrategy размещает реплики по часовой стрелке в кольце, пока не достигнет первого узла в другой стойке.

Эта стратегия пытается разместить реплики на разных стойках в одном центре обработки данных. Это связано с тем, что иногда в стойке может произойти сбой или проблема. Затем реплики на других узлах могут предоставлять данные.

Вот графическое изображение стратегии топологии сети.

Запись Операция

Координатор отправляет репликам запрос на запись. Если все реплики работают, они получат запрос на запись независимо от их уровня согласованности.

Уровень согласованности определяет, сколько узлов ответят подтверждением успеха.

Узел ответит подтверждением успеха, если данные будут успешно записаны в журнал фиксации и memTable.

Например, в одном дата-центре с коэффициентом репликации, равным трем, три реплики получат запрос на запись. Если уровень согласованности равен единице, только одна реплика ответит подтверждением успеха, а остальные две останутся бездействующими.

Предположим, что если оставшиеся две реплики потеряют данные из-за сбоев узла или какой-либо другой проблемы, Cassandra сделает строку согласованной с помощью встроенного механизма восстановления в Cassandra.

Здесь объясняется, как процесс записи происходит в Cassandra,

  1. Когда на узел приходит запрос на запись, он, прежде всего, записывается в журнал фиксации.
  2. Затем Кассандра записывает данные в мем-таблицу. Данные, записываемые в mem-таблицу при каждом запросе записи, также отдельно записываются в журнал фиксации. Mem-table - это временно сохраненные данные в памяти, в то время как журнал фиксации регистрирует записи транзакций для целей резервного копирования.
  3. Когда mem-table заполнена, данные сбрасываются в файл данных SSTable.

Читать операцию

Есть три типа запросов на чтение, которые координатор отправляет репликам.

  1. Прямой запрос
  2. Дайджест-запрос
  3. Прочитать запрос на ремонт

Координатор отправляет прямой запрос на одну из реплик. После этого координатор отправляет дайджест-запрос на количество реплик, указанное уровнем согласованности, и проверяет, являются ли возвращенные данные обновленными данными.

После этого координатор отправляет дайджест-запрос всем оставшимся репликам. Если какой-либо узел выдает устаревшее значение, запрос на восстановление фонового чтения обновит эти данные. Этот процесс называется механизмом восстановления при чтении.

Резюме

В этом руководстве объясняется внутренняя архитектура Cassandra и то, как Cassandra реплицирует, записывает и считывает данные на разных этапах. Кроме того, здесь объясняется, как Cassandra поддерживает уровень согласованности на протяжении всего процесса.