Комментарии: Обзор memcached

Автор: Main | highload

Main | highload — Tue, 10 May 2011 09:21:05 +0000

[...] На уровне приложений обычно производится кэширование объектов любого языка программирования. Этот метод позволяет вовсе избежать существенной части запросов к СУБД, сильно снижая нагрузку на нее. Как и сами приложения такой кэш должен быть независим от конкретного запроса и сервера, на котором он выполняется, то есть быть доступным всем серверам приложений одновременно, а еще лучше — быть распределенным по нескольким машинам для более эффективной утилизации оперативной памяти. Лидером в этом аспекте кэширования по праву можно назвать memcached, о котором я в свое время уже успел подробно рассказать. [...]

Автор: Алексей

Алексей — Sat, 09 Oct 2010 11:42:47 +0000

Спасибо, очень интересная статья.

Автор: Иван Блинков

Иван Блинков — Thu, 22 Apr 2010 08:36:12 +0000

CyberMax, не будут, смысл есть.

Автор: CyberMax

CyberMax — Wed, 14 Apr 2010 07:00:08 +0000

А если у меня на сервере уже установлен XCache то есть ли смысл memcached устанавливать? А они не будут конфликтовать?

Автор: Иван Блинков

Иван Блинков — Wed, 16 Sep 2009 09:07:21 +0000

В рамках одного memcached-сервера кэш общий, если все потоки используют один и тот же сервер — они будут пользоваться одним общим кэшем.

Автор: Вадим

Вадим — Tue, 15 Sep 2009 16:14:04 +0000

Спасибо! Отличная статья.
Вот только один вопрос остался для меня не проясненным.
Если использовать memcached в контексте веб-приложения, скажем, написанного на php, то будет использоваться один общий кэш для всех потоков php, либо для каждого будет создаваться своя «песочница»?

Автор: Сергей

Сергей — Fri, 05 Jun 2009 07:01:16 +0000

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

Автор: Alexandre

Alexandre — Mon, 27 Apr 2009 08:31:32 +0000

протокол memсache реализован на двух демонах
- memcached
- memcachedb
в отличие от первого — второй умеет сохранять хеш-данные на диски, что повышает надежность при случайном сбое системы

Автор: freelancer

freelancer — Wed, 15 Apr 2009 10:56:00 +0000

Действительно просто. Думаю для проектов меншего масштаба можно использовать обычный ассоциативный массив с некоторой логикой удаления устаревших данных вместо memcache

Автор: ReLoader

ReLoader — Wed, 15 Oct 2008 15:31:18 +0000

[quote comment="1434"]народ, подскажите плиз, можно ли использовать memcached для хранения сессий если серверов несколько?
……………….
чувствую что-то здесь не так [/quote]
Выполняется достаточно просто — на одном сервере(любом, например фронтэнде или сервере БД) поднимаем демона мемкеша.
На бэкэндах к php доставляем модуль мемкэш (http://pecl.php.net/package/memcache), в php.ini заменяем строчку
session.save_handler = files
на
session.save_handler = memcache
session.save_path = «tcp://memcache-server:11211″
и добавляем
extension=memcache.so
[memcache]
memcache.dbpath=»/var/lib/memcache»

Это и переопределяет обработку сессий для всех пхп скриптов.
Недостаток — при падении/рестарте мемкэша теряем текущие сесии. Но как вариант можно делать дамп кэша в файл…

Автор: Иван Блинков

Иван Блинков — Thu, 09 Oct 2008 11:18:34 +0000

[quote comment="1433"]при мыслях об использовании мемкеша помните важные ограничения:
ключи не более 250 байт,
данные не более 1мб на ключ.[/quote]
Это уже детали… для того чтобы в них упереться надо сильно постараться, я на практике не сталкивался с ними ни разу, например…
[quote comment="1434"]народ, подскажите плиз, можно ли использовать memcached для хранения сессий если серверов несколько? у меня есть один прокси сервер и 3 backend сервера которые обрабатывают только PHP запросы. сейчас сессии лежат в БД что существенно присаживает базу (отдельный сервер). хочу перенести сессии в кеш, но как их синхронизировать между серверами — незнаю. и как-то не нашел никаких толковых решений. переопределял сам обработку сессиий в РНР, коннектился ко всем демонам, клал туда одинаковые данные…
чувствую что-то здесь не так [/quote]Зависит от языка программирования, но в целом можно, при желании можно даже нагуглить готовые решения.

Автор: Алексей

Алексей — Wed, 08 Oct 2008 18:50:55 +0000

народ, подскажите плиз, можно ли использовать memcached для хранения сессий если серверов несколько? у меня есть один прокси сервер и 3 backend сервера которые обрабатывают только PHP запросы. сейчас сессии лежат в БД что существенно присаживает базу (отдельный сервер). хочу перенести сессии в кеш, но как их синхронизировать между серверами — незнаю. и как-то не нашел никаких толковых решений. переопределял сам обработку сессиий в РНР, коннектился ко всем демонам, клал туда одинаковые данные…
чувствую что-то здесь не так

Автор: Nik

Nik — Wed, 08 Oct 2008 18:28:28 +0000

при мыслях об использовании мемкеша помните важные ограничения:
ключи не более 250 байт,
данные не более 1мб на ключ.

Автор: IT life» Архив блога » ссылки

IT life» Архив блога » ссылки — Mon, 06 Oct 2008 07:54:19 +0000

[...] http://www.insight-it.ru/unix-way/obzor-memcached/ [...]

Автор: Олег

Олег — Wed, 25 Jun 2008 19:09:01 +0000

Примерное месяца назад стал использовать мемкэш для разработки системы обмена сообщений между пользователями сайта. Вместе с UPDATE и memcache оказалось очень эффективной системой.
Если кэш вдруг исчезнет то всегда придет на помощь база данных.
Выигрыш: при частом обмене сообщений — только один быстрый запрос на UPDATE и ВСЕ!!!

Автор: Иван Блинков

Иван Блинков — Tue, 27 May 2008 16:40:19 +0000

[quote comment="806"]но интересно ваше мнение — кэшировать строки таблицы и/или «вспомогательные» сущности(модели) которые более затратны по выборке, но менее используемы?[/quote]Абстрагировавшись от конкретной задачи, отвечать на этот вопрос бессмысленно — к каждому проекту необходим индивидуальный подход.

Автор: Victor

Victor — Tue, 27 May 2008 14:39:21 +0000

До каких пор кэшировать… Тут вопрос в том что есть базовые сущности — объекты которые безусловно кэшируются (по сути сроки таблиц: мембера, заметки, ресторана и тд), и есть допустим «вспомогательные» сущности(модели), которые формируются из разных таблиц путем объединения, и тд. Их тоже хранить? или писать статические «классы-хелперы», которые будут выбирать и компоновать «вспомогательные» сущности непосредственно в коде из закэшированых базовых сущностей.
Пока писал, кое что понял), но интересно ваше мнение — кэшировать строки таблицы и/или «вспомогательные» сущности(модели) которые более затратны по выборке, но менее используемы?

Автор: Kudzu

Kudzu — Sun, 25 May 2008 22:52:21 +0000

[quote comment="241"]Как обычно я выступлю с вопросом о примере юзкейса. Техническая сторона освещена, но как это используется в интернет проектах на практике?

Ну хоть один пример.

Спасибо.[/quote]

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

Автор: Иван Блинков

Иван Блинков — Thu, 15 May 2008 20:05:25 +0000

[quote comment="717"]А как решать вопрос транзакций? Т.е. обновляем данные в базе, в кеше.
Но в случае ролбека данные в кеше остаются недостоверные.[/quote]От конкретного приложения зависит… либо не трогать кэш до commit’а, либо обновлять его параллельно с транзакцией, но в случае rollback’а принудительно синхронизировать с откатившейся базой все потенциально затронутые этим процессом объекты. Или, как вариант, можно держать в кэше две версии нужной части данных: текущую и на момент на начала транзакции, в случае rollback’а достаточно будет просто подменить одну другой (но это будет эффективно, возможно, только при большой вероятности окончания транзакции rollback’ом).

Автор: Сергей

Сергей — Thu, 15 May 2008 16:33:34 +0000

А как решать вопрос транзакций? Т.е. обновляем данные в базе, в кеше.
Но в случае ролбека данные в кеше остаются недостоверные.

Пока придумал только варинат накапливать изменения в программе, и только перед самым комитом делать массовый апдейт кеша. Еще есть идеи?