Здравствуйте
есть вопрос по memcache

есть данные которые часто меняются (постоянно)
блокировка выглядит следующим образом



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

заранее благодарю

Добавлено через 2 минуты и 28 секунд
забыл сказать, что инкремент в кеше делать нельзя т.к. в данном примере в кеше хранится обычный массив, но на деле там массивы нескольких уровней
типа
$cache[$id]['shows']
$cache[$id]['outs']
и т.д.

создавать кеши для каждого типа
$memcache->add('id_shows_'.$id, 0, false, 10)
и потом инкрементиться, я даже не знаю... можно так делать? ведь таких записей может быть сотни миллионов...

Может Вам стоит посмотреть в сторону предназначенных для ваших действий программ MySQL и InnoDB/MyISAM?
 Или же, хотя бы, для начала рассказать какую цель вы преследуете, что бы таким образом изгаляться над бедным Мемкешем.

Это сообщение отредактировал(а) IZ@TOP - 4.3.2009, 15:55

базы и так задейтвованы в виде бекендов, из мискуля считывается если нет в кеше
а цель простая, вывод информеров (баннеров если хотите), сейчас на данном варианте добился миллиона показов баннеров, нагрузка держется в районе 0.8 - 1.2 (LA), помоему сильно грузится
в таком варианте как написал, при тесте ab -c 10 -n 300 "url" выдает 14 запросов в секунду, мало...

или я не прав?

Только я не представляю для чего здесь вообще локи нужны. Если у вас просто вывод информера, вы можете вообще его через ssi подключать, при этом кэшируя Nginx-ом в Memcached напрямую.

А если вас интересует подсчет количества показов информеров, это уже совершенно другой разговор. И в любом случае, подобным образом не решается. Один из противоречащих моментов использования Memcached в качестве сборщика статистики то, что он не гарантирует 100% хранение.

да именно учет статистики
статистика сбрасывается в базу каждые 2 минуты (можно и чаще/реже)

вопрос остается открытым

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

Добавлено через 14 минут и 50 секунд
Пообщался немного с коллегами.
В принципе, вариант не совсем мертвый. Но, есть несколько замечаний:

1. Исключить деадлок (убрать usleep).
2. Собрать Memcached с ключом, который гарантирует 100% хранение. Однако, если кончится память - записать в него вы уже ничего не сможете.
3. Собирать статистику по ключам indexXXXXX с использованием increment/decrement.

Такие соображения.

Еще говорят, что в следующем релизе Memcached будут встроенные локи.

сам с нетерпением жду локов встроеных 

по пунктам:
1. в моем варианте в цикле, если совсем убрать паузу, нагрузка 100% на мемкеш, пусть и доли секундная, но есть
2. что за ключ? можно поподробнее?
3. а если ключей будет миллионы? что тогда? не умрет сервак?


спасибо за советы, буду пробывать 

1. Просто вы сразу отрезали довольно большую часть запросов. 100 мс, это одна десятая секунды, первый запрос лочит все последующие на 100 мс. Ну и т.п.
2. Гугл и оф. доки в помощь 
3. Если у вас есть в БД набор ID, т.е. они Вам известны, то не должно ничего случиться. Делаете выборки ID, частями, и пошли считать. Если Memcached упрется в max connections, советую погуглить facebook memcached. 

сенькс, буду пробывать
тем немения если кто-то сможет дать пример, буду очень благодарен 

ну, идея состоит в том, чтобы сделать избыточное хранение в мемкеше на нескольких серверах.



в мемкеще скорость доступа O(1) независимо от кол-во хрянящихся в нем объектов. В max connections конечно можно упереться, но спасение через multi_request имхо есть.

Добавлено @ 18:29
P.S. Я бы так и делал, т.е. инкерементировал бы значения и иногда скидывал бы их в базу. Можно разбить систему на кластеры - поставить несколько веб-серверов и для каждого свои мемкешы сделать. Тогда масштабируемость же любая.

2Wowa спасибо за идею, буду пробывать 

смотреть стоит в сторону инкремента .
IZ@TOP верно заметил что надо собирать составной ключ ( т.е. изменить структуру хранения массива ),  к примеру 
$cache[$id]['shows']  будет иметь ключ "cache_$id_shows", само поле считать инкрементом ( если нужны счетчики ), так ты отвяжешься от пересчетов данных

если счетчики не нужны, а нужно сохранять промежуточную информацию, алгоритм скриптов надо выстраивать так, чтобы при любом раскладе в памяти оказывалась последняя (нужная) информация. 



Это сообщение отредактировал(а) Alexm6 - 7.9.2009, 15:01