Синхронизация и развитие

Содержание

Двунаправленная синхронизация между KV-кластером и Git-репозиторием обеспечивает актуальность оперативных данных и их долгосрочную сохранность.

Направления синхронизации #

graph LR Git["Git-репозиторий"] KV["KV-кластер"] Git -->|"Git → KV
развертывание, восстановление"| KV KV -->|"KV → Git
периодическая фиксация"| Git style Git fill:#374151,color:#fff,stroke:#1f2937 style KV fill:#374151,color:#fff,stroke:#1f2937

Git → KV (применение желаемого состояния) #

Инициируется Root-нодой при развертывании или восстановлении сети. Root-нода считывает конфигурацию из Git и применяет ее к KV-кластеру, приводя оперативное состояние в соответствие с желаемым.

KV → Git (сохранение оперативных изменений) #

Core-ноды периодически фиксируют изменения из KV-хранилища в Git-репозиторий. Каждая Core-нода отслеживает свою область ответственности (статусы Entry-нод, ротированные пути) и при обнаружении изменений формирует коммит.

Поскольку несколько Core-нод могут одновременно записывать в Git, используется стратегия git pull --rebase перед пушем. Конфликты минимальны — Core-ноды работают в своих областях ответственности.

Консистентность #

Уровень	Механизм
KV-кластер	Строгая консистентность через протокол Raft
Git ↔ KV	Асинхронная периодическая синхронизация; Git может кратковременно отставать от KV
Приоритет	При расхождениях состояние Git считается правильным

Развитие #

Этап 1 — текущий #

KV-кластер (etcd) на Core-нодах
Git-репозиторий как источник истины
Базовая синхронизация Git ↔ KV
ACL для etcd, права доступа к Git
Базовые CLI-инструменты

Этап 2 — масштабирование #

Выделенный KV-кластер на отдельных узлах (при росте до сотен нод)
Возможная миграция на Consul (Service Discovery, Health Checking)
Расширенные CLI-инструменты, веб-интерфейс
Комплексный мониторинг и алертинг

Этап 3 — расширенные возможности #

Геораспределенный KV-кластер
Интеграция Git с CI/CD-пайплайнами
Продвинутые механизмы разрешения конфликтов