Без заголовка

Удивительная вещь - до появления memcached никто, как будто бы, и не знал о существовании разделяемой памяти. Сейчас memcached почему-то называют лучшим решением. Это не так - у этого решения есть особенности, которые в некоторых проектах делают его не лучшим выбором. Memcached хорош двумя вещами - он позволяет держать данные в едином хранилище (например, несколько frontend делят общий кеш) и объединять несколько серверов (масштабируемость). Другие его особенности делают его выбор в некоторых проектах нерациональным (в других - напротив, лучшим решением), а именно: отсутствие блокировок (нельзя заблокировать какой-то ключ, прочитать, вычислить новое значение, разблокировать) и работа через TCP/IP.

Кроме того, у memcached есть особенность, которую тоже надо учитывать. Есть случаи, когда memcached может удалить данные из кеша, вот комментарий разработчика Анатолия Воробья:

Есть набор классов по величине памяти - например, в самом простом и дефолтном варианте, есть класс размером в 128 байт, потом 256 байт, потом 512, 1k, 2k итд. до 1Mb. Если какая-то запись (ключ+значение+ дополнительные заголовки) занимает, скажем, 1.5k, под нее отводится кусок из класса в 2k, т.е. кусок размером в 2k, и она в него пишется.

У каждого класса отдельно есть своя LRU queue всех записей в этом классе - каждый раз, когда кто-то просит прочесть какую-то запись, она перемещается в начало списка своего класса. Таким образом, в конце списка находятся те записи, которых давно никто не просил - их куски освобождаются, когда нужно место для новой записи в этом классе, и нельзя больше согласно конфигурации попросить памяти у системы.


Ссылки на другие способы доступа к разделяемой памяти есть в аннотации к модулю PEAR System::SharedMemory.
17 ноября 2006 20:00

Ваше имя или адрес блога (можно OpenID):

Текст вашего комментария, не HTML: