Как решить проблему обращений в мемкеш в одну единицу времени (многопоточность)?

Question

[sandrain]

Привет.
Как решить проблему обращений в мемкеш в одну единицу времени (многопоточность).
Суть проблемы - так называемый dog-pile effect (протухание кеша).

Есть вариант основаный на CAS
php.net/manual/ru/memcached.cas.php

Вкраце: данные лочатся, затем обновляются и лок убирается, в момент лока остальные потоки ждут.

Нужен ли при таких потерях времени вообще memcached в многопоточности? Может писать просто в базу ? Потери те же по времени.

Answer 1

[Станислав]

Да нужен, т.к. читать потом придется не из "медленной" базы, а из "быстрого" кэша.

Answer 2

[Алексей Сундуков]

Потери те же по времени.

Да ну? А мужики то и не знаю... memcached-ы разные используют...

Comments

[sandrain]

А если серьёзно? Аргументировано

[Алексей Сундуков]

@sandrain

Может писать просто в базу ? Потери те же по времени.

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

[sandrain]

Многопоточка возникла от долгого отклика сторонних ресурсов, это парсер...результаты которые он возвращает в потоках нужно сохранять. Может посоветуете как удобней. Спасибо

Answer 3

[Виталий Желтяков]

Во-первых, какого рода данные хранятся в кэше? Если данные имеют несложную структуру, то лучше использовать файлы.
Во-вторых, если возникает проблема конкурентного доступа к кэш, то зачем он нужен.

Comments

[sandrain]

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