Ответ 1

Переход к хранилищу данных, скорее всего, будет дороже, чем переход через 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 истечет, скорее всего, вам не нужен счетчик "high concurrency": )

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

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

Ответ 2

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

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

• Храните счетчик memcache только по причинам высокой производительности.
• сохранить журнал, а затем получить более точные показатели.