Установленный Redis Cluster с Twemproxy, я действительно не понимаю, почему некоторые команды SET перемещаются
Я установил Redis-Cluster с версией 3.0.5 Redis-Server (Ubuntu 14.04)
Для простоты мы будем игнорировать репликацию. У меня есть три экземпляра Redis, работающие на локальном хосте, порты 7001, 7002 и 7003. Все они сделаны мастерами кластера с этой командой
redis-trib.rb create 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003
Мне нравится идея использования twemproxy
twemproxy-config.yml
twem-1:
listen: 127.0.0.1:22121
hash: fnv1a_64
distribution: ketama
redis: true
preconnect: true
servers:
- 127.0.0.1:7001:1
- 127.0.0.1:7002:1
- 127.0.0.1:7003:1
Я инициализирую twemproxy с nutcracker -c twemproxy-config.yml -d и тогда я могу получить доступ к twemproxy с redis-cli -h 127.0.0.1 -p 22121
Пожалуйста, посмотрите на этот вход и выход
127.0.0.1:22121> set hello 4542342342424
OK
127.0.0.1:22121> set goodbye 345353535545
(error) MOVED 9354 159.203.136.204:7002
127.0.0.1:22121> get hello
"4542342342424"127.0.0.1:22121> get goodbye
(error) MOVED 9354 159.203.136.204:7002
Я обеспокоен тем, что это может работать неправильно. Если я обойду twemproxy и подключусь с помощью redis-cli -c -h 127.0.0.1 -p 7001Я вижу, как происходит автоматическая пересылка. Вот так;
127.0.0.1:7001> get hello
"4542342342424"
127.0.0.1:7001> get goodbye
-> Redirected to slot [9354] located at 127.0.0.1:7002
(nil)
127.0.0.1:7002> set goodbye 3240923842094840
OK
127.0.0.1:7002> get goodbye
"3240923842094840"Ссылка
Интересно почитать на code.hootsuite.com об использовании twemproxy (примерно на полпути вниз страницы)
Конечная цель
Моя конечная цель — использовать кластер redis для хранения данных сеанса PHP на нескольких веб-серверах за балансировщиком нагрузки. В php.ini я бы session.save_handler = redis а также session.save_path = tcp://127.0.0.1:22121 (экземпляр twemproxy будет работать на каждом веб-сервере). Бит конфигурации сеанса PHP еще не установлен.
Надеюсь, у меня есть смысл. Я использую правильный код хеширования? Я действительно хотел бы, чтобы twemproxy возвращал Хорошо вместо Перенесено.
Спасибо!
Благодаря ответу @ the-real-bill я установил redis на двух узлах со стандартным redis-портом 6380 и часовым портом 16380, один из которых является ведущим, а другой — подчиненным. Смотря логи, все выглядит хорошо.
Я смотрел на predis а также phpredis
Это то, в чем я все еще немного не уверен, и я уверен, что если мне дадут больше времени, я это решу. Запросы могут быть записаны только на ведущий, а запросы могут быть прочитаны только от ведомого. У нас есть Sentinel, продвигающий одно или другое в зависимости от доступности — как обработчик сеанса узнает, в какой из них он может писать? Конечно, мне нужно предоставить два IP-адреса ..
Решение
Redis Cluster — это клиент-ориентированный шаблон. В Redis Cluster клиент всегда больше всего подключается к «правильному» узлу для данного ключа. MOVED ответ сообщает клиенту, какой узел обслуживает этот ключ. Первоначально ожидается, что клиент будет извлекать текущую топологию при подключении, а затем обновлять, если он получит MOVED. Это самый эффективный шаблон, так как в нем нет прокси.
Однако это означает, что вы не можете использовать какой-либо существующий прокси-сервер перед настройкой Redis Cluster. Как вы уже видели, Twemproxy просто проксирует одни команды и отказывает другим. Чтобы Twemproxy мог справиться с этим, ему нужно реализовать API кластера и сделать все, что делает клиент. Это не делает, и вы не должны ожидать, что он сделает это в ближайшее время. Любой другой прокси, такой как nginx или HAProxy, должен будет делать то же самое (гипотетически с openresty или пользовательским модулем, который вы мог сделать это в Nginx проще, чем остальные).
Кроме того, в последний раз я проверял, что клиенты PHP не поддерживают Redis Cluster.
Тем не менее, для вашего случая использования я сомневаюсь, что вам действительно нужен Redis Cluster. Конфигурирование Redis в модуле (master + slave) с помощью Sentinel для управления отработкой отказа в сочетании с поддержкой Sentinel на стороне клиента, скорее всего, удовлетворит ваши потребности. Я считаю, что PRedis имеет поддержку, но я уверен, что phpredis нет.
Если вы настроены на сложность работы с общим кластером, тогда используйте обычный Redis + Sentinel за Twemproxy и позвольте Twemproxy подключиться через алгоритм совместного использования, который вы ему указали использовать. Это еще одна проблема при попытке использовать Tweproxy — он делает то, что делает Redis Cluster, но в качестве прокси. В сущности, вы пытаетесь дважды разделить набор данных. Я уверен, что вы можете себе представить, как это катастрофично. 😉
Если вы не можете получить надлежащую поддержку или не хотите, чтобы Twemproxy управлял совместным использованием для вас, последний вариант (если вы не добавляете поддержку клиента самостоятельно) — это настроить прокси-сервер, который настраивается Sentinel. Например, вы можете использовать HAProxy, настроенный для указания на мастер. В случае сбоя Sentinel может выполнить скрипт для вас.
Этот скрипт может затем обновить вашу конфигурацию HAProxy и перезапустить ее для вас, таким образом обеспечивая правильное поведение повторного подключения. Есть много способов сделать это, и поиск в Google в сочетании с документами Redis Sentinel и применением их в вашей среде покажет вам путь.
Другие решения
Вы не можете использовать Redis кластер а также twemproxy в то же время. В Redis кластер В этом режиме клиент должен отправить запрос нужному мастеру. Когда вы запрашиваете ключ у неверного мастера, он всегда отправляет обратно ПЕРЕЕХАТЬ ответ, перенаправив вас к нужному мастеру.