Какой механизм репликации выбрать в распределенной системе?

Question

Трудно понять несколько вещей. У меня есть два реплицированных хоста службы (A и B) (в будущем могут быть увеличены до 3) за шлюзом. Каждому хосту службы необходимо сохранить некоторые данные / состояние ( ключ-значение ) соответствующего хоста. Чтобы избежать SPOF, одно и то же состояние / данные должны быть реплицированы на оба хоста, чтобы, если один сервер выходит из строя, другой должен быть в состоянии обслуживать. Пожалуйста, предложите какой-нибудь механизм для решения этой проблемы. (чтобы быть очень конкретным c если есть распределенная структура)

введите описание изображения здесь

Репликация главный-подчиненный: хост A будет главным, а хост B - подчиненным. Но мой вопрос:

• Весь запрос на запись от хоста B будет маршрутизироваться через хост A, а затем, в конечном итоге, на B.
• Кроме того, допустим, что хост A выходит из строя, тогда произойдет быть без записи, и B будет зависать до тех пор, пока A не будет восстановлен.

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

Я думаю, что решение может быть реализовано с использованием другого подхода (с несколькими ведущими и без лидера), но я не смог прийти к какому-либо выводу. Я попытался сравнить несколько из них:

• Redis - по умолчанию это главный-подчиненный, но корпоративная версия также имеет конфигурацию мастер-мастер. Так что это могло быть возможным решением.
• Стиль Динамо - Риак, Кассандра, Волдеморт и др. c. Не уверен в задействованной сложности

Требование:

• Решение должно быть более простым и легким, не требуя значительных ресурсов хост-машины службы.
• Данные в формате "ключ-значение"
• Чтение / запись должны выполняться очень быстро. (предпочтительно в памяти)
• Возникновение / частота чтения / записи не очень высокая.
• Объем данных также очень мал. общий размер данных на любом хосте в любой момент не может превышать 1 Мб.

Answer 1

P2P-характер Cassandra дает ему очевидное преимущество перед другими, когда не нужно беспокоиться о том, как распределять ведущие и ведомые устройства таким образом, чтобы достигалась максимальная избыточность.

Использование Sentinel имеет один недостаток - если сам узел Sentinel выходит из строя, это затрагивает всю систему. Гораздо лучше масштабировать как по горизонтали, так и по вертикали, т.е. установка с несколькими ведущими и несколькими ведомыми устройствами, когда ведущие и ведомые устройства распределены по узлам.

Answer 2

Использование Redis в режиме кластера или в режиме дозорного будет вариантом.

Redis Cluster: вы можете настроить несколько узлов master-slave. И Redis будет обрабатывать отказоустойчивость при отказе главного сервера.

Redis Sentinel: вы можете настроить один или несколько узлов master-slave и сигнальный кластер. При аварийном переключении дозорный будет обрабатывать новые главные выборы.

И я не думаю, что вам нужна отдельная база данных для каждого хоста вашей службы. Вместо этого все хосты могут подключаться к одному кластеру Redis. Когда один из хостов или Redis-узлов не работает, это не повлияет на работу вашей службы.