Блог

Я ищу предложения по эффективному решению проблемы открытия подключений к memcached с учетом цитаты из часто задаваемых вопросов:

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

Смотрите также: Инициализация Memcached-клиента и Управление объектами подключения.

Я рассматривал возможность использования singleton в нашей сборке кэширования для предоставления memcached-клиента, хотя я уверен, что должны быть методы получше, поскольку блокировки приведут к (ненужным?) накладным расходам.

Мне понятны шаблоны использования клиента, но я не совсем понимаю, как эффективно использовать клиент с точки зрения масштабируемости и производительности. Как другие люди справляются с использованием клиентов memcached?

За это вам полагается вознаграждение в размере 50.

У нас был аналогичный сценарий с клиентом redis, и первоначально нашим решением было иметь общий единственный экземпляр, к которому мы синхронизировали доступ через lock . Это было прекрасно, но чтобы избежать задержек и блокировок, мы в конечном итоге написали потокобезопасный конвейерный клиент, который позволяет одновременное использование без каких-либо блокировок. Я не так много знаю о протоколе men ached, но мне интересно, может ли что-то подобное применяться здесь. На самом деле у меня возникает соблазн попытаться выяснить, могу ли я добавить это в BookSleeve (наш пользовательский клиент OSS redis), если вы можете немного подождать.

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

Просматривая часто задаваемые вопросы, конвейер действительно возможен; и я полностью открыт для варианта написания асинхронного / конвейерного memcached-клиента внутри booksleeve. Большая часть необработанного ввода-вывода / мультиплексирования была бы довольно распространенной в redis. Другие приемы, которые вы можете рассмотреть, — это использование get_multi и т.д., А не отдельных gets, где это возможно — я не знаю, поддерживает ли это ваш текущий клиент, хотя (я не смотрел).

Но: я не знаю, как это отличается от memcached к redis, но в нашем случае переход на конвейерный / мультиплексированный API означал, что нам не нужно было использовать много пулов (много подключений) — одно соединение (правильно конвейерное) способно поддерживать множество одновременных операций с одного узла.