Redis Cluster против Twemproxy — ПЕРЕМЕЩЕННЫЕ ответы

Я хочу использовать Redis для определенного варианта использования. Я не уверен, что выберу Redis Cluster или Twemproxy + Sentinel.

Я знаю, что Cluster всегда выигрывает. Я просто настроен скептически из-за ПЕРЕМЕЩЕННЫХ ответов. В случае ответов MOVED клиент подключится к другому узлу, а в случае повторного разделения ему, возможно, придется снова подключить другой узел. Но в случае Twem он знает, где находятся данные, поэтому он никогда не получит ответ MOVED.

Существуют различные проблемы с Twem, такие как добавленный прыжок, который может увеличить общее время обработки, проблема с добавлением новых узлов или, если он извлекает некоторые узлы, он не сможет обслуживать запросы на ключи, присутствующие на этом узле. Дополнительная головная боль при обслуживании, например, наличие часовых для моих экземпляров Redis и механизма для HA самого twem.

Может ли кто-нибудь предложить мне, что мне выбрать: Twem или Cluster? Я думаю пойти с Twem, так как я не буду ходить туда-сюда в случае ПЕРЕМЕЩЕННЫХ ответов. Но я скептически отношусь к этому, учитывая вышеупомянутые опасения.

P.S. Я планирую использовать клиент Jedis для Redis (если это поможет).


person Tarun    schedule 01.11.2018    source источник


Ответы (1)


Прежде всего, я не знаком с Twemproxy, поэтому расскажу только о ваших проблемах с Redis Cluster.

Клиент Redis может получить полное сопоставление слотов и узлов, то есть расположение ключей, из Redis Cluster. Он может кэшировать сопоставление на стороне клиента и отправляет запрос на нужный узел. Поэтому в большинстве случаев он не будет перенаправлен, т. е. получит сообщение MOVED.

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

Приличная клиентская библиотека может использовать приведенную выше оптимизацию, чтобы сделать ее более эффективной. Поэтому, если ваша клиентская библиотека имеет эту оптимизацию, вам не нужно беспокоиться о штрафе MOVED.

person for_stack    schedule 01.11.2018
comment
Спасибо @for_slack. Из вашего ответа я понимаю, что это означает, что клиент будет периодически синхронизировать расположение ключей из кластера. Что, если у меня много ключей, сможет ли клиент загрузить все это в память? - person Tarun; 01.11.2018
comment
@ Тарун НЕТ. Клиенту требуется только сопоставление слот-узел, которое очень мало. Для заданного ключа клиент может динамически вычислить номер слота ключа, т. е. CRC16, просмотреть сопоставление слот-узел, чтобы найти соответствующий узел, и отправить запрос этому узлу. - person for_stack; 01.11.2018
comment
Спасибо. Я проверил салат и джедаев. Я мог найти это в джедаях, но не в салате. Я думаю, что все клиенты не предоставляют это тогда. В любом случае, я все равно собирался использовать Джедаев. Так что спасибо, что помогли мне здесь. - person Tarun; 02.11.2018