Loser story

Прочитал любопытный пейпер https://www.usenix.org/system/files/conference/hotcloud17/hotcloud17-paper-arora.pdf

В общем как обрабатывать чтения в рафте?

Ну если достаточно консистентных, то можно из fsm любой ноды читать, если же нужны линеаризуемые

Можно, наивно -- захендлим так же как и записи, реплицуруя их лидером на кворум.
Этот подход может быть улучшен с помощью отсутствия реальных записей на диск для чтений, это как бы дефолт, описан в даже в сокращённой пдфке рафта (забавно что даже в просто чтении ошибались https://github.com/etcd-io/etcd/issues/741)

Другой достаточно популярный сейчас вариант, реализовать PreVote и CheckQuorum leader leases, тогда можно достичь того что в рафте никогда не будет существовать более одной ноды считающей(!) себя лидером => можем читать сразу из fsm лидера (стоит учитывать, что leader lease и election таймауты между участниками рафта должны быть подогнаны динамически под максимальный clock drift).
Почитать можно немного тут, в пейпере это не особо подробно описывается, так как довольно известный подход имеющийся в большинстве промышленных реализаций.

Проблема варианта с кворумом, что он имеет большое латенси, минимум 1 ртт, второго, что ограничен пропускной способностью лидера.
Собственно что же предлагается в пейпере?

1) Берём второй подход, используем его когда с клиента пришли на лидера
2) С некоторой вероятностью, есть формула, (ну и на мой взгляд в fallback случаях, например, таких как множество нод без лидера меньше majority, тайм-аут, етс) делаем редирект на лидера
3) Делаем с фолловеров чтение в виде чтения quorum каких-то фолловеров
4) там есть ещё взаимодействие с лидером для полноценных линеаризуемых чтений кворумом, но это неинтересный чисто технический нюанс, смотрите strong consistent reads

В целом выглядит прям хорошо, улучшая пропускную способность, вроде бы не так уж сильно ухудшая количество запросов в сети, особенно для небольших кластеров в 3-9 нод.

Основной нюанс изменение в latency, причём не столько его самого сколько его нестабильность: пришел на лидера, ответили сразу, пришел не на лидера подожди 1 ртт в лучшем случае (остальное зависит от реализации редиректа на лидера).

www.tgoop.com/reverse13/714

1.3K viewsedited  Oct 25, 2023 at 22:59

Прочитал любопытный пейпер https://www.usenix.org/system/files/conference/hotcloud17/hotcloud17-paper-arora.pdf

В общем как обрабатывать чтения в рафте?

Ну если достаточно консистентных, то можно из fsm любой ноды читать, если же нужны линеаризуемые

Можно, наивно -- захендлим так же как и записи, реплицуруя их лидером на кворум.
Этот подход может быть улучшен с помощью отсутствия реальных записей на диск для чтений, это как бы дефолт, описан в даже в сокращённой пдфке рафта (забавно что даже в просто чтении ошибались https://github.com/etcd-io/etcd/issues/741)

Другой достаточно популярный сейчас вариант, реализовать PreVote и CheckQuorum leader leases, тогда можно достичь того что в рафте никогда не будет существовать более одной ноды считающей(!) себя лидером => можем читать сразу из fsm лидера (стоит учитывать, что leader lease и election таймауты между участниками рафта должны быть подогнаны динамически под максимальный clock drift).
Почитать можно немного тут, в пейпере это не особо подробно описывается, так как довольно известный подход имеющийся в большинстве промышленных реализаций.

Проблема варианта с кворумом, что он имеет большое латенси, минимум 1 ртт, второго, что ограничен пропускной способностью лидера.
Собственно что же предлагается в пейпере?

1) Берём второй подход, используем его когда с клиента пришли на лидера
2) С некоторой вероятностью, есть формула, (ну и на мой взгляд в fallback случаях, например, таких как множество нод без лидера меньше majority, тайм-аут, етс) делаем редирект на лидера
3) Делаем с фолловеров чтение в виде чтения quorum каких-то фолловеров
4) там есть ещё взаимодействие с лидером для полноценных линеаризуемых чтений кворумом, но это неинтересный чисто технический нюанс, смотрите strong consistent reads

В целом выглядит прям хорошо, улучшая пропускную способность, вроде бы не так уж сильно ухудшая количество запросов в сети, особенно для небольших кластеров в 3-9 нод.

Основной нюанс изменение в latency, причём не столько его самого сколько его нестабильность: пришел на лидера, ответили сразу, пришел не на лидера подожди 1 ртт в лучшем случае (остальное зависит от реализации редиректа на лидера).

BY Loser story