Memcache краснеет, вы теряете свой счетчик. ОЙ. Использование базы данных mysql или решения NOSQL решит эту проблему с возможным ударом по производительности. (Redis, Tokyotyrant, MongoDB и т.д.) может не иметь этого удара производительности.

Имейте в виду, что вы можете выполнить 2 действия:

1. держите счетчик memcache только по причинам высокой производительности.
2. Ведите журнал, а затем получайте из него более точные метрики.

Обращение к хранилищу данных, вероятно, будет дороже, чем обращение к memcache. Иначе memcache не был бы настолько полезен в первую очередь :-)

Я бы рекомендовал первый вариант.

Если у вас разумная частота запросов, вы можете реализовать его еще проще:

1) update the value in memcache
2) if the returned updated value is evenly divisible by N
2.1) add N to the datastore counter
2.2) decrement memcache by N

Это предполагает, что вы можете установить достаточно длительный тайм-аут для вашего memcache, чтобы прожить между последовательными событиями, но если события настолько редки, что ваш memcache не успевает, есть шанс, что вам не понадобится счетчик "высокого параллелизма": -)

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

При использовании memcache, однако, следует помнить, что некоторые клиентские API будут считать, что тайм-аут в одну секунду означает, что значения нет. Если пакет TCP SYN к экземпляру memcache будет отброшен, это означает, что ваш запрос будет ошибочно считать, что данных нет. (Аналогичные проблемы могут возникнуть с UDP для memcache)