Шаблон кэширования Membase, когда один сервер в кластере недоступен

Question

У меня есть приложение, которое запускает один сервер Membase (1.7.1.1), который я использую для кэширования данных, которые я бы выбрал из нашей центральной базы данных SQL Server. У меня есть одно ведра по умолчанию, связанное с сервером Membase и следовать традиционной схеме данных, Вычитывание:

1. Когда конкретные данные запрашиваются, выполните поиск соответствующего ключа в Membase
2. Если данные возвращаются, используйте его.
3. Если данные не возвращается, извлекать данные из БД
4. магазин вновь возвращаемые данные в Membase

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

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

От моего понимания, если один сервер опускается (назовите его сервером A), в течение периода, когда он не работает, но все еще подключен к кластеру, будет отсутствовать ключ кеша (если активен активный ключ на сервер A, а не на сервер B). В этом случае в приведенном выше шаблоне выборки данных я не получал бы никаких данных, возвращаемых и получаемых непосредственно с SQL Server. Но когда я попытаюсь сохранить данные обратно в мой кластер Membase, сохранит данные на сервере B и переназначит этот ключ на сервер B на следующей выборке?

Я понимаю, что как только я помечаю сервер A как «не пройденный», ключ реплики сервера B станет активным, но я не понимаю, как обрабатывать прерывистую ситуацию, когда сервер A недоступен, но еще не отмечен как не удалось.

Любая помощь очень ценится!

Answer 1

Это довольно старая версия. Но несколько вещей, чтобы уточнить.

1. Если вы выполняете кэширование вы, вероятно, используете Memcached ведро, и в этом случае является нет реплик.
2. Узлы всегда считаются прикрепленными к кластеру до тех пор, пока они не будут явно удалены административным действием (попытка автоопределения автоматически автоматизирует это административное действие для вас, пытаясь удалить узел из кластера, если определено, что оно опущено для n количество время).
3. Если сервер не работает (но не сработал), вы не получите «Cache Miss» как таковой, а какую-то другую ошибку подключения от вашего клиента. Многие старые клиенты memcached не делают этого различия и просто возвращают NULL, False или аналогичные значения для любого рода сбоев. Я предлагаю вам использовать подходящего клиента Couchbase для вашего приложения, которое должно помочь разграничить их.
4. Что касается Couchbase, маршрутизация данных для любых операций остается неизменной. Поэтому, если вы не смогли достичь элемента на сервере A., потому что он недоступен, вы столкнетесь с этой же проблемой при попытке сохранить его снова.Другими словами, если вы попытались получить данные от Server A, и он не работал, попытка сохранить данные до Сервер A будет работать не таким же образом, если только сервер не был провален между последней выборкой и текущей попытка хранения - в этом случае клиент определит это и направит запрос на соответствующий сервер.

В «новых» версиях Couchbase (> 2.x) есть специальные прибудут-из-реплик команд доступны для использования с couchbase (или Membase) -Style ведром, которые позволяют явно считывать информацию с реплики. Обратите внимание, что вы все еще не можете писать на такой узел.

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