Репликация и кэширование

Репликация

Репликация master-slave

• Главный, первичный узел (master), ответственный за обработку всех операций записи и управление данными.
• Подчинённый, вторичный узел, или реплика, слейв (англ. slave). Таких узлов может быть несколько. Они пассивно реплицируют данные от главного узла и обслуживают запросы на чтение в случае применения паттерна read-replica.

• приостановить свою работу до получения обновлений от ведущего;
• продолжать обслуживать возможно устаревшие данные, одновременно применяя последние изменения в фоновом режиме.

Паттерн read-replica

1. Когда Алиса создаёт заказ на сайте «Мегашоп», запрос отправляется в службу заказов.
2. Служба заказов создаёт запись о заказе на главном узле — это операция записи. Данные реплицируются в два подчинённых узла.
3. Алиса просматривает детали заказа. Данные считываются из подчинённого узла.
4. Алиса просматривает историю последних заказов. Данные для чтения передаются из подчинённого узла.

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

Репликация multi-master

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

• Сложность настройки и поддержки.
• Потенциальные задержки в данных.

Преимущества и недостатки репликации

Преимущества репликации

• Высокая доступность данных Данные дублируются на нескольких серверах, поэтому в случае выхода из строя одного сервера остальные продолжают обслуживать запросы, обеспечивая непрерывность работы системы.
• Высокая производительность системы Нагрузку на чтение можно распределить между несколькими репликами, что снижает нагрузку на основной сервер (мастер) и улучшает производительность.
• Отказоустойчивость (reliability) При сбое одного из серверов данные остаются доступными на других репликах, что минимизирует риск потери данных и простоев.
• Гибкость в распределении нагрузки Запросы на чтение можно будет отправлять в реплику, которая ближе всего к пользователю географически. Это снижает задержки и повысит скорость доступа к данным. Такая гибкость особенно важна в распределённых системах с географически разнесёнными серверами.

Ограничения репликации

• Сложности с консистентностью данных
  В случае задержек репликации данные на репликах могут быть устаревшими, что требует дополнительных механизмов синхронизации и управления конфликтами.
  Пример: допустим, у нас есть три сервера в кластере: сервер A (мастер), сервер B (реплика) и сервер C (реплика). Мы решили внедрить репликацию для повышения доступности и производительности системы. Сервер A является мастером и обрабатывает все запросы на запись, а серверы B и C являются репликами и обслуживают запросы на чтение. В случае задержек репликации данные на серверах B и C могут быть устаревшими.
  Если клиент обновляет информацию о своём заказе на сервере A, но запрос на чтение направляется на сервер B или C до завершения репликации, клиент увидит устаревшие данные. Это может вызвать путаницу и проблемы с данными, что требует дополнительных механизмов для синхронизации и управления конфликтами.
• Ресурсозатратность
  Поддержание нескольких копий данных требует дополнительных вычислительных и дисковых ресурсов. Это увеличивает затраты на инфраструктуру и администрирование, так как каждый сервер должен иметь достаточную ёмкость для хранения всех данных.
  Пример: если база данных занимает 1 ТБ, то три сервера в кластере потребуют 3 ТБ суммарного дискового пространства. Кроме того, каждая репликация данных потребляет сетевые ресурсы и процессорное время.
• Сложность управления
  Управление системой с несколькими репликами усложняется необходимостью мониторинга состояния каждой реплики, обеспечения их синхронизации и обработки сбоев. Администраторам необходимо следить за состоянием каждой реплики, проводить регулярные проверки их синхронизации и быстро реагировать на сбои.
  Пример: если сервер C выходит из строя, администраторы должны быстро восстановить его, чтобы он снова мог начать получать данные от мастера (сервера A). Такое важно быстро отслеживать, то есть потребуется настроить тщательный мониторинг.

Критерии для оценки целесообразности репликации

1. Требования к доступности
   Если система требует высокой доступности данных и минимизации простоев, репликация является подходящим решением. Она обеспечивает непрерывность работы даже при сбоях отдельных серверов.
2. Нагрузка на чтение
   В системах с высокой нагрузкой на чтение репликация помогает распределить запросы на чтение между несколькими серверами, снижая нагрузку на основной сервер и улучшая производительность.
3. Географическое распределение пользователей
   В системах с пользователями, распределёнными по различным географическим регионам, репликация позволяет направлять запросы на ближайшие реплики, что снижает задержки и улучшает пользовательский опыт.
4. Критичность данных
   Для систем, где потеря данных недопустима, репликация обеспечивает дополнительный уровень защиты за счёт дублирования данных на нескольких серверах.

Реализация репликации на базе MongoDB

• Replicaset Механизм работы Replicaset подобен multi-master, но затраты на поддержание берёт на себя полностью СУБД. Replicaset обеспечивает высокую доступность и горизонтальное масштабирование. В реплике каждый узел может выполнять операции чтения и записи, что позволяет распределять нагрузку и поддерживать постоянную доступность данных.
• Master-slave  Этот тип репликации был доступен до версии 3.6 и предлагал более простую настройку, но имел ограничения в плане доступности и масштабирования.

Как работает репликация в MongoDB

• Запись и чтение с основного сервера Драйвер клиентского приложения выполняет операции чтения и записи на основном узле, в MongoDB его называют primary node. Затем информация, записанная на primary, асинхронно копируется на вторичный узел — secondary node, или слейв.
• Чтение с реплики Драйвер может считывать данные с secondary-нод, что позволяет уменьшить нагрузку на основной сервер (тот самый подход read-replica).

Практика: настройте репликацию для MongoDB

version: '3'
services:
  mongodb1:
    image: mongo:latest # docker образ
    container_name: mongodb1
    restart: always
    ports:
      - "27017:27017"
    networks:
      app-network:
        ipv4_address: 173.17.0.10
    volumes:
      - mongodb1-data:/data/db
    command:
      [
        "--replSet",
        "rs0",
        "--bind_ip_all",
        "--port",
        "27017"
      ] #команда для создания реплики
    healthcheck:
      test: [ "CMD", "mongo", "--eval", "db.adminCommand('ping')" ]
      interval: 5s
      start_period: 10s

  mongodb2:
    image: mongo:latest
    container_name: mongodb2
    restart: always
    ports:
      - "27018:27018"
    networks:
      app-network:
        ipv4_address: 173.17.0.9
    volumes:
      - mongodb2-data:/data/db
    command:
      [
        "--replSet",
        "rs0",
        "--bind_ip_all",
        "--port",
        "27018"
      ]
    healthcheck:
      test: [ "CMD", "mongo", "--eval", "db.adminCommand('ping')" ]
      interval: 5s
      start_period: 10s

  mongodb3:
    image: mongo:latest
    container_name: mongodb3
    restart: always
    ports:
      - "27019:27019"
    networks:
      app-network:
        ipv4_address: 173.17.0.8
    volumes:
      - mongodb3-data:/data/db
    command:
      [
        "--replSet",
        "rs0",
        "--bind_ip_all",
        "--port",
        "27019"
      ]
    healthcheck:
      test: [ "CMD", "mongo", "--eval", "db.adminCommand('ping')" ]
      interval: 5s
      start_period: 10s

networks:
  app-network:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 173.17.0.0/16

volumes:
  mongodb1-data:
  mongodb2-data:
  mongodb3-data: 

docker-compose up -d  

docker exec -it mongodb1 mongosh 

> rs.initiate({_id: "rs0", members: [
{_id: 0, host: "mongodb1:27017"},
{_id: 1, host: "mongodb2:27018"},
{_id: 2, host: "mongodb3:27019"}
]}) 

Кэширование

1. Приложение проверяет наличие нужных данных в кэше.
2. Если данных там нет, то запрос направляется в хранилище.
3. На обратном пути данные передаются в кэш, а запрос возвращается пользователю.

• При высокой нагрузке на чтение для текущих ресурсов Определить, является ли нагрузка высокой, можно, посмотрев на графики утилизации процессора, памяти, дисков. Использование кэширования при низких нагрузках только усложнит систему.
• При наличии редко изменяемой информации, которую необходимо часто получать из хранилища На практике получение такой информации занимает от минуты и дольше. Это могут быть предпочтения пользователя, статический контент. Если информация постоянно меняется, то преимущество кэширование будет «съедено» затратами на поддержание актуальности контента в кэше.

Redis Cluster для кэширования данных

 redis_1:
    image: "redis:latest"
    container_name: redis_1
    ports:
      - "6379"
    volumes:
      - redis_1_data:/data
      - ./redis/redis.conf:/usr/local/etc/redis/redis.conf
    command: [ "redis-server", "/usr/local/etc/redis/redis.conf" ]
    networks:
      app-network:
        ipv4_address: 173.17.0.2

  redis_2:
    image: "redis:latest"
    container_name: redis_2
    ports:
      - "6379"
    volumes:
      - redis_2_data:/data
      - ./redis/redis.conf:/usr/local/etc/redis/redis.conf
    command: [ "redis-server", "/usr/local/etc/redis/redis.conf" ]
    networks:
      app-network:
        ipv4_address: 173.17.0.3

  redis_3:
    image: "redis:latest"
    container_name: redis_3
    ports:
      - "6379"
    volumes:
      - redis_3_data:/data
      - ./redis/redis.conf:/usr/local/etc/redis/redis.conf
    command: [ "redis-server", "/usr/local/etc/redis/redis.conf" ]
    networks:
      app-network:
        ipv4_address: 173.17.0.4

  redis_4:
    image: "redis:latest"
    container_name: redis_4
    ports:
      - "6379"
    volumes:
      - redis_4_data:/data
      - ./redis/redis.conf:/usr/local/etc/redis/redis.conf
    command: [ "redis-server", "/usr/local/etc/redis/redis.conf" ]
    networks:
      app-network:
        ipv4_address: 173.17.0.5

  redis_5:
    image: "redis:latest"
    container_name: redis_5
    ports:
      - "6379"
    volumes:
      - redis_5_data:/data
      - ./redis/redis.conf:/usr/local/etc/redis/redis.conf
    command: [ "redis-server", "/usr/local/etc/redis/redis.conf" ]
    networks:
      app-network:
        ipv4_address: 173.17.0.6

  redis_6:
    image: "redis:latest"
    container_name: redis_6
    ports:
      - "6379"
    volumes:
      - redis_6_data:/data
      - ./redis/redis.conf:/usr/local/etc/redis/redis.conf
    command: [ "redis-server", "/usr/local/etc/redis/redis.conf" ]
    networks:
      app-network:
        ipv4_address: 173.17.0.7

volumes:
  redis_1_data: {}
  redis_2_data: {}
  redis_3_data: {}
  redis_4_data: {}
  redis_5_data: {}
  redis_6_data: {} 

Механизм работы Redis

Дальнейшие настройки

port 6379
cluster-enabled yes #активация кластерного режима
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
 

docker-compose up -d 

docker exec -it redis_1
echo "yes" | redis-cli --cluster create   173.17.0.2:6379   173.17.0.3:6379   173.17.0.4:6379   173.17.0.5:6379   173.17.0.6:6379   173.17.0.7:6379   --cluster-replicas 1 

redis-cli cluster nodes  

Как сделать ещё лучше

> mkdir nodejs-api
> cd nodejs-api
> npm init -y
> npm install express mongoose redis
> touch index.js

const express = require('express');
const redis = require('redis');
const app = express();
const PORT = 3000;

const client = redis.createClient();

// работа Redis - достаём данные, если они есть по ссылке /api/products
const cache = (req, res, next) => {
  const cacheKey = req.originalUrl;
  client.get(cacheKey, (err, data) => {
    if (err) throw err;
    if (data !== null) {
      res.json(JSON.parse(data));
    } else {
      next();
    }
  });
};

// сбрасываем кэш в случае обновления данных
const invalidateCache = (cacheKey) => {
  client.del(cacheKey, (err, response) => {
    if (err) throw err;
    console.log(`Cache key "${cacheKey}" invalidated`);
  });
};

app.get('/api/products', cache, (req, res) => {
  
  const products = //логика получения данных из MongoDB

  // Сохраняем данные по ключу /api/products на 1 минуту
  client.setex(req.originalUrl, 120, JSON.stringify(products));

  res.json(products);
});

// При обновлении данных - сбрасываем кэш
app.post('/api/products', (req, res) => {
  //обновляем данные в MongoDB
  
  invalidateCache('/api/products');

  res.json({ message: 'Product data updated successfully' });
});

app.listen(PORT, () => {
  console.log(`Server is running on port ${PORT}`);
});
 

Реализация репликации в различных БД

• Базам, например, PostgreSQL, MySQL.
• Инструментам кэширования, например Memcached.

• Потоковая репликация
  Процесс копирования данных с основного сервера PostgreSQL на реплики. При этом используется WAL (журнал предзаписи транзакций), который позволяет восстановить данные в случае сбоя. Потоковая может быть синхронной или асинхронной.
  Для настройки потоковой репликации все серверы должны быть одной версии, работать на одной операционной системе и архитектуре.
• Логическая репликация
  Возможность настройки логической репликации появилась в PostgreSQL 10. Отличается от потоковой тем, что она оперирует записями в таблицах PostgreSQL, а не физическим уровнем данных. 
  Этот вид репликации основан на механизме публикации/подписки: один сервер публикует изменения, а другой подписывается на них.

Итоги

• Репликация (replication) — это создание и поддержание копий базы данных на нескольких серверах. Она бывает двух типов: мастер-слейв (master-slave) и мульти-мастер (multi-master). В первом случае главный сервер всегда один, а во втором их несколько. Выбор типа зависит от задачи и условий масштабирования.
• В облаке репликация часто преднастроена, однако на отдельном сервере может понадобиться настраивать её самостоятельно. Вы научились делать это в MongoDB.
• Кэширование — это ещё один метод горизонтального масштабирования, который позволяет сохранять часто используемые данные в кэш.
• Redis — один из популярных и стабильных сервисов для кэширования. Он позволяет реплицировать и шардировать данные — разбивать на сегменты. Вы научились настраивать кэширование в Redis.

Что почитать про Redis