Memcached презентация

является строка, а данные представляют собой неинтерпретируемый массив байтов.
Free & open source
Высокопроизводительная
Распределенная система
Широкого назначения
Прежде всего – для ускорения работы веб-приложений за счет снижения нагрузки на базу данных
Кеширование результатров запросов к БД, вызовов внешних API, отрендеренных страниц и др.
Простота применения
Простые API

Java, Python, Ruby, Perl, .NET, MySQL, PostgreSQL, Erlang, Lua, и др.)
Используется в: YouTube LiveJournal, Wikipedia/Wikimedia, Amazon.com, Wikia, SourceForge, Metacafe, Facebook, Twitter, Fotolog, The Pirate Bay etc.

– до 1 мегабайта
Клиенты заполняют массив данными, в дальнейшем их запрашивают
Клиенты используют специальные библиотеки доступа для контакта с сервером, по умолчанию с портом 11211
Каждый клиент имеет информацию о всех серверах
Серверы не взаимодействуют между собой
Логика хранения распределяется между клиентом и серером
Для чтения или записи по ключу клиент вычисляет хеш ключа для определения номера сервера
Обращается к серверу
Сервер в свою очередь вычисляет хеш ключа для поиска данных во внутренних структурах

старые значения удаляются (алгоритм least recently used (LRU))
Memcached надо рассматривать как промежуточное хранилище, нужного объекта в нем может и не оказаться
Расширение MemcacheDB поддерживает постоянное хранение
Типичная среда – несколько серверов и множество клиентов, однако, ничего не мешает клиенту и серверу находиться на одной машине
Время выполнения определенного операций – примерно постоянная величина
Существенных задержек нет
Конструктивно memcached выполнен как отдельный процесс, взаимодействие с которым ведётся через сокеты по простому протоколу на базе «сырых» TCP или UDP.
Немного упрощаяя, можно сказать, что memcached это удалённая реализация интерфейса java.util.Map на базе хэш-таблицы.

каждый клиентский запрос порождается отдельный экземпляр интерпретатора
без использования внешних механизмов два выполняющихся запроса не могут иметь доступ к одним и тем же объектам, так как имеют не связанные между собой адресные пространства
Традиционно в мире LAMP для кэширования использовалась база данных
HTTP-сессии: либо хранить все сессионные данные в БД, тем самым ещё больше увеличивая на неё нагрузку, либо хранить эти данные локально (в файле), теряя их в случае отказа узла в кластере

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

проблему согласованности кэша внутри кластера
+ это отдельный процесс, а значит он спокойно переживает перезапуск серверов приложений
+ он более эффективно расходует память, что заметно при хранении большого количества больших объектов
Это делает целесообразным хранение в memcached объектов «высокого уровня готовности» типа фрагментов веб-страниц, количество обращений к которым при выполнении одного запроса будет не столь высоким, как если кэшировать отдельные мелкозернисные объекты.
+cуществует аппаратная реализация memcached от Gear6
(в виде отдельной коробочки по формату серверной стойки), которая позволяет хранить гиганский объём данных

реализованного на уровне прикладных сервисов или даже презентационной логики.
Второй вариант прячет детали работы с memcached внутри привычных механизмов и инструментов
Реализация кэша второго уровня Hibernate на базе memcached
Реализация менеджера HTTP-сессий Tomcat

(async) for one hour
c.set("someKey", 3600, someObject);
// Retrieve a value (synchronously).
Object myObject=c.get("someKey");

MemcachedClient(
AddrUtil.getAddresses("server1:11211 server2:11211"));

// Try to get a value, for up to 5 seconds, and cancel if it doesn't return
Object myObj=null;
Future