Memcache - проблемы в распределенной среде со многими узлами

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

По сути, у нас было многоузловое кольцо memcached, работающее более двух лет, и по большей части оно было беспроблемным. Установка memcache была недавно перенесена на выделенные серверы, а емкость увеличилась втрое (2x 1 ГБ до 2x3 ГБ). Сначала у нас были проблемы с тем, что я считаю проблемами с тем, как библиотеки php общались с серверами, либо проблемами с упорядочением списка серверов, либо их неправильным запуском.

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

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

Тем не менее, я следил за вещами в течение последних нескольких недель и заметил, что первый сервер, похоже, поражается много, много раз, чем второй (инструмент мониторинга PHP memcache сообщает, что в среднем 1200 посещений в секунду, в то время как второй только на 500).

Может кто-нибудь объяснить:

  • Во-первых, любая идея о том, что происходит выше, почему один сервер будет получать гораздо больше посещений в "распределенной" среде.
  • Во-вторых, каковы рекомендуемые настройки для клиентов memcache в распределенной ситуации?
    • Я правильно делаю, используя последовательное хеширование
    • Должен ли я использовать аварийное переключение?;
    • двоичное хранилище?;
    • или сжатие?
  • Как правильно выполнить процедуру сброса / перемещения живого кольца memcache?

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

заранее спасибо

Источник

2 ответа

Решение

Если ваши ключи имеют неравные шаблоны доступа, вы увидите неравный трафик на каждый узел memcached. Например, если у вас есть 2 ключа, один из которых a это получить / установить 500 раз в секунду и один b что получить / установить 250 раз в секунду, то узел, который содержит a будет иметь вдвое больше трафика, чем узел, который содержит b,

В моем случае у нас было 8 узлов memcached с несколькими тысячами ключей. Один из этих ключей выполнял около 800 операций в секунду при пиковом трафике, и почти каждый другой ключ выполнял менее 1 операции в секунду. Узел memcached, имеющий ключ занятости, демонстрировал значительно больший трафик, чем другие.

Если вы хотите сбалансировать трафик в равной степени для каждого из ваших узлов memcached, то вам необходимо:

  • Играйте в игры с помощью клавиш, чтобы убедиться, что ваши клавиши заняты правильно распределены.
  • Переключитесь на использование repcached или Membase для репликации ключей между несколькими узлами
Источник

Вы уверены, что внешние интерфейсы, взаимодействующие с Memcached, правильно синхронизировали записи конфигурации для вашего пула?

Могут ли все серверы установить чистое соединение с узлом Memcached, у которого проблемы со связью?

Убедитесь, что у вас включен Memcached::OPT_LIBKETAMA_COMPATIBLE.

Что касается конфигурации; если вы храните большие объекты, сжатие /igbinary ускорит процесс на стороне сетевого ввода-вывода, очевидно, что может быть недостаток, поэтому каждый случай индивидуален. Бенчмаркинг является ключом.

Источник
Другие вопросы по тегам