Какие термины применимы для горизонтального масштабирования?

Термины горизонтального масштабирования (Horizontal Scaling)

Горизонтальное масштабирование (scale-out) — это добавление новых серверов/узлов вместо увеличения мощности существующего сервера. Это ключевая концепция в современных распределённых системах.

Основные термины

Sharding

Определение: Разделение данных между несколькими серверами по какому-то ключу (shard key).

Даннные пользователей (1B записей) на одном сервере → слишком медленно

Шардирование по user_id:
- Shard 1: user_id 1-250M
- Shard 2: user_id 250M-500M  
- Shard 3: user_id 500M-750M
- Shard 4: user_id 750M-1B

Каждый шард на отдельном сервере = 4x параллелизм

def get_shard(user_id, num_shards=4):
    return (user_id % num_shards) + 1  # Возвращает номер шарда

# user_id=123 → shard 4
# user_id=456 → shard 1
# user_id=789 → shard 2

Проблемы: Hot shards (неровное распределение), миграция при добавлении новых шардов

Replication (Репликация)

Определение: Копирование данных на несколько серверов для отказоустойчивости и масштабирования чтения.

Мастер (Master):
  ↓ (пишет)
  Slave 1 (читает)  
  Slave 2 (читает)
  Slave 3 (читает)

Типы:

• Master-Slave: Одна реплика для записи, остальные для чтения
• Master-Master: Обе реплики принимают запросы на запись (сложная синхронизация)
• Read Replicas: Много réplicas только для чтения

# Пример: распределение запросов
if query_type == 'SELECT':
    server = load_balanced_read_replica()  # Выбрать случайный slave
else:
    server = master  # Все UPDATE/INSERT идут в master

Partitioning (Partitioning)

Определение: Логическое разделение таблицы на части (обычно одного сервера).

-- Партиционирование по дате
CREATE TABLE orders (
    order_id INT,
    user_id INT,
    order_date DATE
) PARTITION BY RANGE (YEAR(order_date)) (
    PARTITION p_2023 VALUES LESS THAN (2024),
    PARTITION p_2024 VALUES LESS THAN (2025),
    PARTITION p_2025 VALUES LESS THAN (2026)
);

Отличие от sharding: Partitioning на одном сервере, sharding на нескольких

Consistent Hashing

Определение: Алгоритм распределения для уменьшения переключений при добавлении/удалении узлов.

Обычное хеширование (user_id % 4 nodes):
- Если добавить 5-й node → 80% данных переместится (bad!)

Consistent hashing:
- Кольцо с 360 позициями
- Добавить 5-й node → переместятся только 20% данных
- Лучше для горизонтального масштабирования

Load Balancing

Определение: Распределение запросов между несколькими серверами.

Запросы → Load Balancer → Сервер 1
                       → Сервер 2
                       → Сервер 3
                       → Сервер 4

Алгоритмы:

• Round Robin: По очереди 1, 2, 3, 4, 1, 2...
• Least Connections: На сервер с наименьшим количеством активных соединений
• IP Hash: По IP клиента (для sticky sessions)
• Weighted: С учётом мощности сервера

import random

servers = ['srv1', 'srv2', 'srv3', 'srv4']

# Round robin
index = (request_counter % len(servers))
selected = servers[index]

# Random
selected = random.choice(servers)

# Least connections
selected = min(servers, key=lambda s: get_connection_count(s))

Clustering

Определение: Группа серверов, работающих как одна система.

База данных кластер:
- Node 1 (Master)
- Node 2 (Slave) 
- Node 3 (Slave)
- Heartbeat: проверка живых ли nodes
- Failover: если Master падает → Slave становится Master

Distributed Cache

Определение: Cache (например, Redis) распределён между несколькими узлами.

Redis Cluster:
- Node 1: keys 0-5460
- Node 2: keys 5461-10922
- Node 3: keys 10923-16383

Клиент:
  1. Вычисляет hash(key)
  2. Определяет какому узлу отправить
  3. Отправляет туда GET/SET

Архитектурные паттерны

Horizontal Pod Autoscaling (HPA)

Определение: Автоматическое добавление/удаление контейнеров на основе нагрузки.

# Kubernetes HPA
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70  # Если CPU > 70% → добавить pod

Distributed Queue

Определение: Очередь (RabbitMQ, Kafka) распределённая между узлами.

Производители → Kafka Topic (партиции на разных узлах) → Консьюмеры

Топик с 4 партициями = 4x параллелизм обработки

MapReduce

Определение: Парадигма распределённых вычислений (используется в Spark, Hadoop).

Map:   разделить задачу на части, обработать параллельно
Reduce: объединить результаты

Пример: count words in 1GB file
- Разделить на 100 чанков по 10MB
- Map: каждый chunk → count words
- Reduce: объединить все counts
- Результат за минуты вместо часов

Database Replication

Определение: Копирование данных между несколькими БД для масштабирования.

Master (запись) → Write-Ahead Log (WAL) → Slave 1 (чтение)
                                       → Slave 2 (чтение)
                                       → Slave 3 (чтение)

Ключевые концепции

CAP Theorem

Определение: В распределённой системе можно гарантировать максимум 2 из 3:

• Consistency: все узлы видят одни данные
• Availability: система всегда отвечает
• Partition tolerance: работает при разрыве сети

PostgreSQL master-slave:
- Consistency: да (master = source of truth)
- Availability: частично (если master падает → downtime)
- Partition tolerance: нет (при разрыве сети неприятности)

DynamoDB (AWS):
- Availability: да (работает везде)
- Partition tolerance: да (работает при разрыве)
- Consistency: нет (eventual consistency)

Eventual Consistency

Определение: Данные синхронизируются не мгновенно, но в итоге становятся согласованными.

User 1 пишет в Replica 1: "Name = Alice"
User 1 читает из Replica 2: может видеть "Name = Bob" на 100ms
И только через 100ms Replica 2 получит обновление

Удобно для масштабируемости, но требует в коде обработки несогласованности

Distributed Transaction

Определение: Транзакция, которая охватывает несколько узлов.

# Пример: перевод денег между шардами
# Shard 1: user_id=1 (Alice)
# Shard 2: user_id=5 (Bob)

BEGIN TRANSACTION
  SELECT balance FROM shard1 WHERE user_id=1  # -100
  SELECT balance FROM shard2 WHERE user_id=5  # +100
COMMIT

# Если упадём между UPDATE'ами → деньги потеряются!
# Решение: Two-Phase Commit (2PC), Saga pattern

Примеры технологий

Sharding:

• Vitess (MySQL sharding middleware)
• Citus (PostgreSQL sharding)
• MongoDB sharding

Replication:

• PostgreSQL streaming replication
• MySQL replication
• Redis sentinel

Distributed Cache:

• Redis Cluster
• Memcached
• Hazelcast

Message Queue:

• Kafka (партиции = шарды)
• RabbitMQ
• Apache Pulsar

Orchestration:

• Kubernetes (автоматическое масштабирование)
• Docker Swarm

Практические решения

Масштабирование базы данных

Проблема: 1 миллион запросов/сек, одна PostgreSQL 

Решение 1: Vertical Scaling (bad)
- Купить более мощный сервер
- Упирается в ceiling

Решение 2: Replication (good для reads)
- Master для записи
- 10 реплик для чтения
- 90% запросов идут на реплики

Решение 3: Sharding (best)
- 10 master shards (каждый handling 100K writes/sec)
- Каждый shard имеет 5 replicas
- Полная горизонтальная масштабируемость

Масштабирование приложения

Проблема: Python Flask app, 100 RPS

Решение:
- Запустить 10 реплик контейнера (за load balancer)
- Каждый контейнер handles ~10 RPS
- Kubernetes автоматически масштабирует при 70% CPU

Отказоустойчивость:
- Если 1 контейнер упадет → 9 остальных продолжат
- Graceful degradation

Итоги

Когда использовать горизонтальное масштабирование:

1. Нагрузка больше, чем может один сервер
2. Нужна отказоустойчивость
3. Нужна глобальная распределённость
4. Проект растёт и нужен способ масштабирования

Главные термины:

• Sharding — разделение данных
• Replication — копирование данных
• Load Balancing — распределение запросов
• Clustering — группа серверов как одна система
• Eventual Consistency — синхронизация "в итоге"

Сложность: Горизонтальное масштабирование сложнее вертикального, но более масштабируемо.