Comments 7
Лучшая отказоустойчивость — чем больше узлов вы используете в своем кластере, тем надежнее будет ваш кластер. Например, если вы запускаете свой набор данных в кластере из 3 узлов, а один узел деградирует, это 1/3 вашего кластера не работает; но если вы запускаете свой набор данных в кластере из 9 узлов и один узел деградирует, это всего лишь 1/9 вашего кластера не работает.
Ну во всём мире это ухудшение отказоустойчивости.
А в какой логике это ухудшает отказоустойчивость?
В логике авторов данные всегда размазаны по Redis Cluster равномерно, соответственно если одна машина выходит из строя, то чем больше машин было в кластере изначально, тем большая часть данных по прежнему доступна.
Вероятность, что хотя бы одна машина выйдет из строя растет при количестве машин, то есть если буквально читать, как написано в переводе, то мы чаще будем сталкиваться с недоступностью в части данных.
В оригинале используются слова "not performing" - здесь это употреблено в контексте репликации, то есть когда данные на всех узлах одинаковы. Соответственно, вы теряете в скорости чтения, но доступность всех данных сохраняется.
P.S.
Также по тексту "multiprocessing" переведено как "многопроцессорная", хотя здесь это "многопроцессная" в противопоставлении с многопоточной.
Спасибо за "многопроцессный", исправил.
Да, если добавить пометку, что речь про шардированный и реплицированный Redis Cluster, то абзац станет менее спорным :)
Я так понимаю ДрагонФлай просто обертка над форком многопоточного редиса - LevelDB?
И странный вопрос в общем у топика если давно есть LevelDB , многие им пользуются .
И еще "Итог" в середине статьи - это конечно...
Декларируется, что Dragonfly написан с нуля, а не является чьим-о форком.
Вопрос с одной стороны риторический, потому что вряд ли кто-то будет сейчас именно переписывать Redis. С другой стороны создатели продолжают топить, что потоки от лукавого, однопоточный Redis крут, масштабируйтесь горизонтально и все в таком роде :)
Нужна ли Redis новая архитектура? (13 лет спустя)