😃 RAFT - это про надежный master-slave 😃
«Но он же часто используется в мульти-мастер базах?» – вот в этом то и интересное противоречие, о котором расскажу в комментариях
#distributed #db #raft #cockroachdb #ydb #scylla
«Но он же часто используется в мульти-мастер базах?» – вот в этом то и интересное противоречие, о котором расскажу в комментариях
#distributed #db #raft #cockroachdb #ydb #scylla
Комментарии: 4
🦾
Вкратце, набор узлов базы выбирает лидера, все операции записи идут через него, но он не подтверждает запись пока большинство не согласится, в случае смерти лидера, один из последователей выбирается следующим лидером, а в случае развала сети, если где-то оказалось большинство, эта часть сети продолжит работать
Такой системе можно доверять и при падении она самовостановится
В данной ситуации из CAP, мы взяли Consistent и немного Partition tolerance
Если мы выбираем лидером узел на целую базу, то никакого мульти-мастер не будет, а вот для master-slave репликации это будет самая надежная схема, но в современных условиях еще потребует и механизма ассинхронной репликации, чтобы иметь уменьшать нагрузку для баз чисто для чтения
Если будем выбирать лидером узел на таблицу, то все станет еще хуже, потому что сцепленность данных будет просто тормозить абсолютно всю систему
«И что же тогда делать?» – есть другие протоколы распределенных систем, которые в своем корне предполагают мульти-мастер (Couchbase, Cassandra, ElectricSQL, etc.), а вот чтобы система на RAFT заработала в мульти-мастер, нам нужно добавить чуть больше магии
Например, как это реализовано в CoackroachDB, YDB и новой ScyllaDB, мы можем разбить нашу таблицу на более мелкие группы (например, range по id-шникам) и теперь каждый отдельный узел отвечает только за свою группу, получается, что за одну целую таблицу начинают отвечать сразу много узлов, но каждый по чуть чуть
Вот вам и мультимастер
Такой системе можно доверять и при падении она самовостановится
В данной ситуации из CAP, мы взяли Consistent и немного Partition tolerance
Если мы выбираем лидером узел на целую базу, то никакого мульти-мастер не будет, а вот для master-slave репликации это будет самая надежная схема, но в современных условиях еще потребует и механизма ассинхронной репликации, чтобы иметь уменьшать нагрузку для баз чисто для чтения
Если будем выбирать лидером узел на таблицу, то все станет еще хуже, потому что сцепленность данных будет просто тормозить абсолютно всю систему
«И что же тогда делать?» – есть другие протоколы распределенных систем, которые в своем корне предполагают мульти-мастер (Couchbase, Cassandra, ElectricSQL, etc.), а вот чтобы система на RAFT заработала в мульти-мастер, нам нужно добавить чуть больше магии
Например, как это реализовано в CoackroachDB, YDB и новой ScyllaDB, мы можем разбить нашу таблицу на более мелкие группы (например, range по id-шникам) и теперь каждый отдельный узел отвечает только за свою группу, получается, что за одну целую таблицу начинают отвечать сразу много узлов, но каждый по чуть чуть
Вот вам и мультимастер
I
⁃ Raft (extended), 2014: https://www.usenix.org/system/files/conference/atc14/atc14-paper-ongaro.pdf
⁃ Zookeeper, 2010: https://www.usenix.org/legacy/event/usenix10/tech/full_papers/Hunt.pdf
⁃ Spanner, 2012: http://nil.lcs.mit.edu/6.824/2020/papers/spanner.pdf
⁃ CockroachDB, 2020: https://dl.acm.org/doi/pdf/10.1145/3318464.3386134
⁃ COPS, 2011: http://nil.lcs.mit.edu/6.824/2020/papers/cops.pdf
⁃ Impossibility of Distributed Consensus with One Faulty Process, 1985: https://dl.acm.org/doi/pdf/10.1145/3149.214121
⁃ Time, clocks, and the ordering of events in a distributed system, 1978: https://dl.acm.org/doi/pdf/10.1145/359545.359563
⁃ Zookeeper, 2010: https://www.usenix.org/legacy/event/usenix10/tech/full_papers/Hunt.pdf
⁃ Spanner, 2012: http://nil.lcs.mit.edu/6.824/2020/papers/spanner.pdf
⁃ CockroachDB, 2020: https://dl.acm.org/doi/pdf/10.1145/3318464.3386134
⁃ COPS, 2011: http://nil.lcs.mit.edu/6.824/2020/papers/cops.pdf
⁃ Impossibility of Distributed Consensus with One Faulty Process, 1985: https://dl.acm.org/doi/pdf/10.1145/3149.214121
⁃ Time, clocks, and the ordering of events in a distributed system, 1978: https://dl.acm.org/doi/pdf/10.1145/359545.359563
I
I