Rqlite и CAP-теорема: почему выбрали согласованность, а не доступность

На иллюстрации показана схема работы rqlite в контексте теоремы CAP: выделена консистентность (Consistency) над доступностью (Availability), изображены серверы в распределённой сети, логотип rqlite и четыре уровня согласованности чтения — Weak, Strong, Linearizable и None.

В мире распределённых систем CAP-теорема — это не просто теоретическая заметка в учебнике, а практическая развилка, где каждое решение влечёт архитектурные последствия. База данных rqlite — отличный пример того, как разработчики сознательно выбирают CP-подход, жертвуя доступностью ради согласованности.

🧩 Что такое rqlite

• ⚙️ Движок хранения — SQLite, проверенный и лёгкий.
• 📝 Язык реализации — Go.
• 🔄 Протокол согласования — Raft, который обеспечивает единый порядок операций во всём кластере.

Это не «распределённый SQLite» в лоб, а полноценный кластерный уровень поверх него, который управляет репликацией и отказоустойчивостью.

🔍 Почему CP, а не AP

По CAP в условиях сетевого разделения можно либо:

• 📏 Обеспечить согласованность (CP), при этом меньшинство узлов перестанет работать;
• 📡 Сохранить доступность (AP), рискуя получить расхождение данных.

rqlite выбирает первое: при разделении сети отвечает только та часть, где есть большинство узлов. Это значит, что:

• нет конфликтов при синхронизации,
• данные всегда корректны,
• но клиент, попавший на «меньшинство», получит отказ, а не устаревший результат.

📚 Четыре режима согласованности чтения

rqlite даёт разработчику тонкую настройку — можно выбрать баланс между скоростью и актуальностью данных:

• 🟦 weak (по умолчанию) — быстро, почти всегда свежо, но при коротком «окне ложного лидерства» возможны устаревшие ответы.
• 🟥 strong — чтение через журнал Raft, 100 % свежести, но медленно; годится для тестов.
• 🟨 linearizable — проверка лидерства с кворумом, почти скорость weak, но с гарантиями strong; идеальный компромисс.
• 🟩 none — мгновенно, напрямую из локальной SQLite, без гарантий; полезно для read-only узлов.

💡 Мой взгляд

Решение rqlite — это про доверие к данным, а не про «работать любой ценой». В финансовых системах, медицинских сервисах или IoT-инфраструктуре ошибка из-за устаревшего состояния может стоить дороже, чем кратковременная недоступность.

Особенно ценным считаю то, что rqlite даёт выбор на уровне запроса — можно сделать важное чтение linearizable, а вспомогательное — weak или none, экономя ресурсы. Это подход, который стоило бы перенять многим другим CP-системам.

🔗 Источник:

1. Consistency over Availability: How rqlite Handles the CAP theorem