2017-01-20 6 views
0

Как справиться с этой ситуацией.Redis высокая доступность - приращение синхронизации при сбое ведущего узла

1) есть установка 1 Master (M) и 2 Ведомые (S)

2) выполнение приращения значения (а затем использовать его в качестве уникального идентификатора)

3) он увеличивает на Мастере, но не удается синхронизировать с ведомые (т.е. задержка сети или проблема)

4) Мастер умирает же время

5) Новый мастер был избран

6) Никакие узлы из кластера не знают об инкрементах, а при следующем включении оно добавит следующее значение, то есть дубликат.

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

ответ

1

В этом случае работнику необходимо будет вызвать WAIT после инкремента, чтобы гарантировать, что изменение синхронизировано.

+0

Я поддержал ваш ответ, большое спасибо за отзыв. Главный вопрос здесь - найти решение без ухудшения производительности. У вас есть опыт в этом, как влияет производительность на внедрение WAIT? –

+1

Стоимость выполнения обычно представляет собой еще один запрос Redis от клиента WAITing - в большинстве случаев это было бы незначительным, но вы должны проверить его на свой код. –