Pull to refresh

Comments 15

Некоторые проекты уже заточены под memcached. И эта возможность будет весьма кстати.

Кстати, насколько оперативно данный форк синхронизируется с последней версией memcached?
Он был ответвлен в момент 1.4.13-stable. Думаю, не проблема подтянуть его до последнего 1.4.15.
Постараюсь сегодня это и сделать.
Подтянул к HEAD, теперь актуальный.
Redis, tarantool и т. п. решения отлично подходят когда необходимы гарантии. По-умолчанию же эти решения, насколько мне известно, не содержат (или отключают) вытеснение ключей, а наоборот (для обеспечения этих самых гарантий) — хранят все до последнего, пишут write-ahead-log'и и просто плохо ведут себя при заполнении всей ОЗУ. Да, есть патчи к tarantool и, наверняка, есть настройки к Redis'у, что легко гуглится. (кстати, уже тот факт что оно гуглится говорит что проблема есть). Кстати, не знаю как ведет себя Redis, но tarantool при восстановлении данных опирается на абсолютный TTL, что скорее мешало в моем случае.

Memcached, напротив, — простой кэш. Вытесняет по LRU, четко соблюдает объемы памяти, ничего лишнего не пишет и вдобавок, обладает отличной производительностью.
Мне показалось что когда есть такое зарекомендовавшее себя средство, то проще потратить день на его допиливание. Зато клиентскую стророну, протестированную на тот момент, менять не пришлось.
Couchbase же есть, зачем так извращаться? :)
Сейчас, глядя на него, не могу вспомнить почему пропустил. Видимо, сыграло именно желание «покодить».
Собственно, да — это бывший membase, казалось бы — те же корни что и у memcached.
Спасибо что напомнили!
Какой-то костыль, простите. В таком варианте consistency весьма и весьма eventual.

Вообще можно (нужно) держать несколько серверов memcached на разных физических машинах и тогда потеря одного сервера не должна портить погоду. Иначе «сервис не сможет выдержать нагрузку» по-умолчанию.
Тут много «если» появляется. Есть у Вас 10 серверов с 64Gb на каждом под кэш.
Что если они в одном датацентре и там что-то произошло с питанием?
Приходим к тому что надо разделять/реплицировать и т.д. и т.п. Между тем, дешевые диски простаивают.
Если что-то произошло с питанием, то вы не успели сбросить кеш на диск → fail.
Имеется дамп, скажем, от нескольких часов назад. Чем он хуже если дает все тот же hitrate?
Есть много задач где это подойдет, например, кэш поисковика.
mongodb тоже может быть использовано для кеширования. С постоянным хранилищем и кучей приятных фич, таких как репликация и шардинг.
Даже статья была тут habrahabr.ru/post/124212/

Проект не поддерживается с 2008 года.
Кроме того, вот эти цитаты не могли не смутить: «It is NOT a cache solution» и "*NO* expiration. For memcache protocol compatible, still reserved, but we do nothing".

Собственно, последняя цитата из офф. документации «Totally for persistent. Transaction, replication, we do our best to achieve persistent» характеризует большинство альтернативных memcached-у решений: они не про простой и эффективный кэш, они про СУБД и гарантии записи. Про типизацию данных и оптимизацию последовательных чтений. Про внутренние скрипты и прочие вкусности. При более близком знакомстве вы понимаете что они не так просто эксплуатируются и вставляются в проект как memcache.
Я конечно извиняюсь за самопиар, но также хочу порекомендовать мою тулу memcached-itool, которая может отобразить дамп на экран. У вас более persistent вариант, но у меня более пригодный для отладки.
Sign up to leave a comment.

Articles