ЗАМЕР
bench/valkey-cluster/apidiff.py
Скрипт, которым получены числа в статье, и запись прогона. Файл читается на сборке из репозитория — это тот самый код, который запускали, а не его копия.
- Цитируется в статье
- /ru/system-design/caching/valkey-clustering
- Как запустить
python3 bench/valkey-cluster/discovery.py # блоки 1-4 python3 bench/valkey-cluster/apidiff.py # блоки 5-7 python3 bench/valkey-cluster/failover.py # блоки 8-10 python3 bench/valkey-cluster/notready.py # блоки 11-12 python3 bench/valkey-cluster/quorum.py # блок 13 python3 bench/valkey-cluster/databases.py # блоки 14-16 python3 bench/valkey-cluster/boundaries.py # блоки 17-19
Запись прогона
Замеры для статьи «Два способа собрать Valkey из нескольких узлов»
| Файл | Что делает |
|---|---|
common.py |
подъём узлов в обоих режимах, разговор с ними, печать блоков. Общий модуль, сам ничего не печатает |
discovery.py |
как клиент находит узел: MOVED против SENTINEL get-master-addr-by-name, и что клиент делает на самом деле — блоки 1–4 |
apidiff.py |
какие команды в кластере перестают работать и почему — блоки 5–7 |
failover.py |
отказ мастера в обоих режимах глазами клиента, и что бывает, когда старый мастер возвращается — блоки 8–10 |
notready.py |
окно между «кластер собран» и «кластер переживёт отказ» — блоки 11–12 |
quorum.py |
кворум против большинства: почему одно число не заменяет другое — блок 13 |
databases.py |
нумерованные базы в кластере: два кластера с разным cluster-databases — блоки 14–16 |
boundaries.py |
три утверждения статьи, проверенные на границах — блоки 17–19 |
python3 bench/valkey-cluster/discovery.py # блоки 1-4
python3 bench/valkey-cluster/apidiff.py # блоки 5-7
python3 bench/valkey-cluster/failover.py # блоки 8-10
python3 bench/valkey-cluster/notready.py # блоки 11-12
python3 bench/valkey-cluster/quorum.py # блок 13
python3 bench/valkey-cluster/databases.py # блоки 14-16
python3 bench/valkey-cluster/boundaries.py # блоки 17-19
Нужен собранный Valkey — путь к нему берётся из VALKEY_BIN (по умолчанию
/usr/local/valkey912/bin). Узлы поднимаются во временных каталогах на
случайных портах и убиваются в finally; после себя скрипты не оставляют ни
процессов, ни файлов. Весь набор идёт около шести минут: переключений надо
дождаться несколько раз, и торопить их нечем.
Откуда здесь Valkey 9.1.2
В системных пакетах лежит 7.2.13 — ветка, к которой половина того, что стоит
писать про кластер, уже не относится. Обычный путь за свежей версией закрыт:
dl.google.com и сайт проекта недоступны из этой среды. Зато доступен GitHub, а
Valkey собирается из исходников одной командой:
git clone --depth 1 --branch 9.1.2 https://github.com/valkey-io/valkey.git /tmp/valkey912
cd /tmp/valkey912 && make -j2 BUILD_TLS=no
install -D /tmp/valkey912/src/valkey-{server,cli,benchmark} -t /usr/local/valkey912/bin
Отдельного двоичного файла для sentinel нет и не нужно: это тот же
valkey-server, запущенный с конфигом и флагом --sentinel. Свойство, а не
деталь сборки, — и в блоке 7 видно, чем режимы при этом отличаются.
Что здесь важно прочитать правильно
Абсолютные секунды не переносятся никуда. Узел считается упавшим через
секунду молчания (down-after-milliseconds 1000) вместо тридцати по умолчанию,
а cluster-node-timeout стоит 2000 мс вместо 15 000. Это сделано ровно затем,
чтобы набор укладывался в минуты. Содержательны порядок событий, текст ответов
сервера и знак разницы — но не число секунд.
Порты выбираются ниже 55535, и это не придирка. Узел кластера слушает два порта: обычный и шинный, ровно на десять тысяч больше. Порт из эфемерного диапазона даёт шинный порт больше 65535, и узел не поднимается вовсе.
Опрос идёт «глупым» клиентом. Везде, где печатается ответ сервера, он снят
через valkey-cli без флага -c. Библиотека-клиент прячет ровно то, что здесь
интересно: сама ходит за картой слотов, сама повторяет запрос, сама спрашивает
sentinel. Настоящие клиентские библиотеки используются только в блоках 3 и 4 —
там вопрос как раз в том, что делает клиент, и считают это сами узлы.
Что получилось
Как клиент находит узел
| нативный кластер | Sentinel | |
|---|---|---|
| кто знает топологию | каждый узел данных | отдельная служба |
| что клиент спрашивает | любой узел, обычной командой | SENTINEL get-master-addr-by-name |
| как узнаёт про чужой ключ | MOVED 12182 127.0.0.1:43425 |
никак: вопрос не к узлу |
| что нужно в конфиге клиента | один живой адрес узла | адреса sentinel и имя набора |
В блоке 3 видно, что клиент кластера, получив ОДИН адрес из шести, сходил за
CLUSTER SLOTS и дальше писал напрямую нужному узлу. В блоке 4 порядок
обратный: сначала вопрос службе, потом команда данным.
Что ломается в кластере из привычного
| команда | в кластере | под sentinel |
|---|---|---|
MSET foo 1 bar 2 |
CROSSSLOT Keys in request don't hash to the same slot |
OK |
MSET {u}:a 1 {u}:b 2 |
работает: общая скобка кладёт ключи в один слот | OK |
SELECT 1 |
ERR DB index is out of range — но см. ниже |
OK |
SWAPDB 0 1 |
ERR SWAPDB is not allowed in cluster mode |
OK |
Две формы отказа различаются не случайно: SWAPDB запрещён как таковой, а
SELECT 1 — выход за границу. За какую именно границу, блок 6 сам по себе не
говорит, и на этом первая версия статьи ошиблась.
Нумерованные базы: настройка, а не режим
Из SELECT 1 → ERR DB index is out of range в первой версии был сделан вывод
«в кластере база ровно одна». Это правило Redis и Valkey до 9.0; в Valkey 9.0
нумерованные базы в кластере появились, а их число задаёт неизменяемая
настройка cluster-databases со значением по умолчанию 1. Блоки 14–16
поднимают два кластера, отличающихся ровно этой строкой:
| кластер А | кластер Б | |
|---|---|---|
cluster-databases |
1 | 16 |
SELECT 1 |
ERR DB index is out of range |
OK |
SELECT 15 |
ERR DB index is out of range |
OK |
SELECT 16 |
ERR DB index is out of range |
ERR DB index is out of range |
Номер базы в адресацию не входит: один ключ в базах 0 и 1 держит разные
значения при одном слоте 12182. А вот чего базы не дают — общего на кластер
представления о себе: DBSIZE и SCAN считают только ту часть базы, что лежит
на узле, куда пришла команда, SWAPDB остаётся запрещён.
Границы трёх утверждений
Блоки 17–19 перемеряют места, где статья сказала шире измеренного:
«никогда» из блока 12 снимается настройкой cluster-replica-validity-factor 0
(реплика повышается за четыре секунды, но пустой); границу кворума и
большинства заранее показывает SENTINEL CKQUORUM; узел под sentinel знает не
«ничего», а свою пару репликации — не знает он только авторитетного ответа
службы.
Отказ мастера
| нативный кластер | Sentinel | |
|---|---|---|
| кто замечает | сами узлы, по шине | отдельные наблюдатели |
| кто решает | большинство мастеров | большинство sentinel |
| что получает клиент в этот момент | CLUSTERDOWN, потом MOVED на новый адрес |
молчание старого адреса |
| как клиент узнаёт новый адрес | из ответа любого живого узла | только спросив sentinel |
| вернувшийся старый мастер | сразу реплика, отдаёт MOVED |
мастер на 10 с, принимает записи |
Последняя строка — самое опасное место режима Sentinel и содержание блока 10.
Вернувшийся узел поднимается мастером, отвечает OK на записи, а после
перевода в реплику полная синхронизация их стирает. Клиент при этом не видит ни
одной ошибки.
Два состояния готовности
Блоки 11 и 12 — про находку, ради которой стоило ронять узлы вручную. Между
«слоты розданы» (cluster_state:ok) и «есть кому повышаться»
(master_link_status:up у реплик) прошло 6,07 секунды. Мастер, упавший
внутри этого окна, не заменяется НИКОГДА: у реплики, ни разу не подключавшейся,
отметка «когда упал канал» осталась нулевой, возраст её данных считается от
начала эпохи Unix, и она отказывается повышаться:
Currently unable to failover: Disconnected from primary for longer than
allowed. Please check the 'cluster-replica-validity-factor' configuration
option.
Условие видно в исходнике (src/cluster_legacy.c):
if (server.repl_state == REPL_STATE_CONNECTED) {
data_age = (mstime_t)(server.unixtime - server.primary->last_interaction) * 1000;
} else {
data_age = (mstime_t)(server.unixtime - server.repl_down_since) * 1000;
}
Практический вывод про эксплуатацию: «кластер поднялся» и «кластер держит
отказ» — разные проверки, и вторая смотрит на master_link_status каждой
реплики.
Кворум и большинство
Пять sentinel, кворум 2, погашены три. Кворум выполнен — и переключения всё равно нет:
+odown master cache 127.0.0.1 48147 #quorum 2/2
+try-failover master cache 127.0.0.1 48147
+vote-for-leader c92cd70b21a9dd26ec40e67185371e78ee502f9a 1
-failover-abort-not-elected master cache 127.0.0.1 48147
Стоило поднять одного из погашенных — большинство появилось, и переключение состоялось за две секунды. Кворум при этом не менялся вовсе.
Источники
- Valkey. Cluster specification — https://valkey.io/topics/cluster-spec/
- Valkey. High availability with Valkey Sentinel — https://valkey.io/topics/sentinel/
- Valkey. Sentinel client spec — https://valkey.io/topics/sentinel-clients/
- Valkey. Atomic slot migration — https://valkey.io/topics/atomic-slot-migration/
- Valkey. Numbered Databases in Valkey 9.0 — https://valkey.io/blog/numbered-databases/
- Redis. CLUSTER MIGRATION — https://redis.io/docs/latest/commands/cluster-migration/
- Исходники Valkey 9.1.2 — https://github.com/valkey-io/valkey/tree/9.1.2
Скрипт
166 строк"""Чем отличается набор доступных команд — блоки 5-7.
ГЛАВНОЕ, ЧТО ЗДЕСЬ ПРОВЕРЯЕТСЯ. «Перейдём на кластер» звучит как решение про
эксплуатацию, а оказывается решением про КОД: часть команд, работавших годами,
в кластере перестаёт работать, и перестаёт по-разному. Что-то отказывает
всегда, что-то — только когда ключи легли в разные слоты, то есть в проде и
через полгода.
ПОЧЕМУ ЭТО НЕ «ОГРАНИЧЕНИЯ VALKEY», А СЛЕДСТВИЕ ПРЕДЫДУЩИХ БЛОКОВ. Все три
отказа ниже выводятся из одного: в кластере адресуется не узел, а слот, и
команда выполняется ЦЕЛИКОМ на одном узле. Значит, команда, которой нужны два
ключа из разных слотов, не может быть выполнена нигде. А в режиме Sentinel
узел один, и тех же ограничений нет вовсе.
ЧТО ЗДЕСЬ ПЕЧАТАЕТСЯ. Дословные ответы сервера на одни и те же команды,
отправленные в двух режимах. Ни одного измерения времени.
ЗАПУСК: python3 bench/valkey-cluster/apidiff.py
"""
from __future__ import annotations
import time
from common import Cluster, cli, free_port, head, note, preamble, role_of, row
SENTINEL_NAME = "cache"
PAD = 42
def pair(label: str, cluster_answer: str, sentinel_answer: str) -> None:
row(label, "", pad=PAD)
row(" в кластере", cluster_answer, pad=PAD)
row(" под sentinel", sentinel_answer, pad=PAD)
def block5(cport: int, sport: int) -> None:
head(5, "ОДНА КОМАНДА НА ДВА КЛЮЧА: ГДЕ ПРОХОДИТ ГРАНИЦА")
# Ключи подобраны так, чтобы разошлись по слотам: это видно из CLUSTER
# KEYSLOT прямо здесь, а не утверждается на словах.
row("CLUSTER KEYSLOT foo", cli(cport, "cluster", "keyslot", "foo"), pad=PAD)
row("CLUSTER KEYSLOT bar", cli(cport, "cluster", "keyslot", "bar"), pad=PAD)
row("CLUSTER KEYSLOT {u}:a", cli(cport, "cluster", "keyslot", "{u}:a"), pad=PAD)
row("CLUSTER KEYSLOT {u}:b", cli(cport, "cluster", "keyslot", "{u}:b"), pad=PAD)
print()
pair("MSET foo 1 bar 2",
cli(cport, "mset", "foo", "1", "bar", "2"),
cli(sport, "mset", "foo", "1", "bar", "2"))
print()
pair("MSET {u}:a 1 {u}:b 2",
cli(cport, "mset", "{u}:a", "1", "{u}:b", "2"),
cli(sport, "mset", "{u}:a", "1", "{u}:b", "2"))
note(
"""
Отказ не про «две записи сразу», а про два РАЗНЫХ слота: те же две
записи с общей фигурной скобкой проходят. Скобки — не украшение
имени, а указание хешировать только то, что внутри; поэтому
{u}:a и {u}:b попадают в один слот и оказываются на одном узле.
Отсюда правило проектирования ключей, которое дороже всего обходится
задним числом: в кластере набор ключей, которые понадобится трогать
одной командой, надо решать ДО первой записи. Под sentinel такого
решения принимать не надо вовсе — узел один, любые ключи рядом.
Ответ MOVED во второй строке второй пары — не отказ: узел сообщает,
что оба ключа лежат вместе, но не у него. Клиент кластера сходил бы
по адресу и выполнил команду целиком.
"""
)
def block6(cport: int, sport: int) -> None:
head(6, "НУМЕРОВАННЫЕ БАЗЫ: В ОДНОМ РЕЖИМЕ ЕСТЬ, В ДРУГОМ НЕТ")
pair("SELECT 1", cli(cport, "select", "1"), cli(sport, "select", "1"))
print()
pair("SWAPDB 0 1", cli(cport, "swapdb", "0", "1"), cli(sport, "swapdb", "0", "1"))
print()
pair("CONFIG GET databases",
" ".join(cli(cport, "config", "get", "databases").split()),
" ".join(cli(sport, "config", "get", "databases").split()))
note(
"""
Третья пара объясняет первые две: в кластере база ровно одна, и
SELECT 1 — это выход за границу, а не запрещённая команда. Формулировка
ответа тут важнее, чем кажется: сервер говорит про диапазон, то есть
SELECT 0 в кластере работает и будет работать.
Практическая цена этого пункта обычно недооценена. Разделение
окружений по номеру базы — «тесты в 1, кэш сессий в 2» — в кластере
не переносится вообще, и переписывать приходится не строчку конфига,
а привычку.
"""
)
def block7(cport: int, sport: int, sentinel_port: int) -> None:
head(7, "КОМАНДЫ УПРАВЛЕНИЯ: ТРИ РАЗНЫХ НАБОРА НА ОДНОМ ДВОИЧНОМ ФАЙЛЕ")
row("CLUSTER INFO", "", pad=PAD)
row(" узел кластера", cli(cport, "cluster", "info").splitlines()[0], pad=PAD)
row(" узел под sentinel", cli(sport, "cluster", "info").splitlines()[0], pad=PAD)
row(" сам sentinel", cli(sentinel_port, "cluster", "info").splitlines()[0], pad=PAD)
print()
row("SENTINEL get-master-addr-by-name cache", "", pad=PAD)
row(" узел кластера",
cli(cport, "sentinel", "get-master-addr-by-name", SENTINEL_NAME).replace("\n", ":"), pad=PAD)
row(" узел под sentinel",
cli(sport, "sentinel", "get-master-addr-by-name", SENTINEL_NAME).replace("\n", ":"), pad=PAD)
row(" сам sentinel",
cli(sentinel_port, "sentinel", "get-master-addr-by-name", SENTINEL_NAME).replace("\n", ":"), pad=PAD)
print()
row("GET foo", "", pad=PAD)
row(" узел под sentinel", cli(sport, "get", "foo") or "(пусто)", pad=PAD)
row(" сам sentinel", cli(sentinel_port, "get", "foo"), pad=PAD)
note(
"""
Один и тот же valkey-server в трёх ролях отвечает на одни и те же
команды тремя разными способами. Это и есть ответ на вопрос «а можно
ли совместить»: нельзя не потому, что кто-то запретил, а потому что
режимов три и набор команд у каждого свой.
Последняя пара — самая практическая. Sentinel не хранит данных, и
GET у него не просто пустой, а неизвестный. Клиент, по ошибке
настроенный на порт sentinel как на порт данных, не получит
«пусто» — он получит отказ на каждую команду.
"""
)
def main() -> None:
preamble("одни и те же команды в двух режимах, ответы сервера дословно")
cluster = Cluster()
try:
cports = [free_port() for _ in range(3)]
for p in cports:
cluster.start_data(p, cluster=True)
cluster.form_cluster(cports, replicas=0)
m = free_port()
rep = free_port()
sen = free_port()
cluster.start_data(m)
cluster.start_data(rep, replicaof=m)
cluster.start_sentinel(sen, m, quorum=1, name=SENTINEL_NAME)
time.sleep(2)
# Узел кластера для вопросов берётся первый; какие слоты на нём —
# неважно, потому что все три блока про то, что команда вообще
# ОТКЛОНЕНА, а не про то, где лежит ключ.
assert role_of(m) == "master"
block5(cports[0], m)
block6(cports[0], m)
block7(cports[0], m, sen)
finally:
cluster.stop_all()
if __name__ == "__main__":
main()