Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Масштабировать легко. Часть вторая — кэширование

Anna | 3.06.2014 | нет комментариев
В предыдущей части мы говорили об основных архитектурных тезисах построения масштабируемых порталов. Сегодня побеседуем об оптимизации верно построенного портала. Выходит: 1-й вид оптимизации — локальный кэш.

Часть вторая. Кэширование

Как я теснее упоминал в предыдущей части, мы говорим, в первую очередь, о B2C порталах. У этих порталов есть всеобщее качество: преимущество читающих запросов над пишущими. И неоднократно, преимущество 10-кратное и больше. ?сно, отчего кэширование представляется таким перспективным инструментом.

Кэши — тема увлекательная и фактически безмерная. Следственно я испробую обрисовать ее довольно коротко, для первого раунда оптимизации, не вдаваясь в подробности о кэше 1 и 2 яруса, распределенном кэше (distributed cache) и т. д. Так как нам необходимо кэшировать чтение объекта, пока мы пропустим и кэш записи (write cache).

Когда мы начинаем локальное кэширование, перед нами традиционно стоит выбор: query либо object cache (кэширование вызова либо объекта). Query cache (либо method cache) — это кэш, тот, что дозволено применять «снаружи»: он записывает итоги вызовов способов (query), а мы полагаем, что идентичные запросы вызывают идентичные результаты. При повторении одного и того же запроса несколько раз, дозволено, начиная со второго раза, пропустить трудную и длинную обработку, и легко воротить предшествующий итог. Преобладание таких кэшей в том, что они не зависят ни от архитектуры, ни от домена, то есть интегрируются как утилита (скажем, aspect) в готовый продукт, не крепко его изменяя. В противовес этому превосходству, у них целый ряд недостатков:

  • Они неэффективны, когда у нас богатые интерфейсы, у которых есть несколько способов чтения одного и того же объекта. Повод — они кэшируют путь к объекту, а не сам объект.
  • Их размер зависит не от числа допустимых объектов (итогов), а от числа допустимых запросов, и потому они традиционно тяжелее, чем альтернативы. Их размер и число нужной памяти трудно планировать.
  • Они уродливы.

Вовсе напротив обстоит дело с объектными кэшами: их тяжелее встроить, но они и значительно результативнее. Безупречная имплементация кэша объекта — это коллекция (список либо уйма зависит от требований), которая содержит все объекты, управляемые этим сервисом, в их объектном виде. В идеале сервис должен быть в состоянии ответить на всякий запрос при помощи кэша и без обращения к внешней персистентности (скажем, базе данных). К сожалению, такая 100% кэшируемость редко достигаема, но там, где ее дозволено применить, она неизменно рентабельна. Наилучший пример для 100% кэша — учетные записи пользователей. Они, как правило, маленькие (состоят из id, почты, имени, времени регистрации и т.д.) и непрерывно требуются в различных местах приложения.

Кэшируем то, чего нет

Ещё одна пригодная форма кэша — так называемый нуль-кэш, либо негативный кэш. В большинстве случаев объектные кэши наполняются во время работы приложения, для того, Дабы был допустим так называемый «леденящий старт» и создание новых объектов в базе, при одновременном существовании нескольких инстанций одного и того же обслуживания. В итоге, обращения к приложению могут «пробиваться» через кэш и доходить до базы. В случае, если такое «пробивание» будет протекать непрерывно, это может привезти к перегрузке базы. Тогда все наши кэши, выстроенные с таким трудом, утратят всяческую результативность и охраняющую функцию. Для борьбы с сходственной перегрузкой существуют негативные кэши, которые запоминают некогда бесплодно опрошенные объекты, тем самым давая сервису вероятность при дальнейшем запросе перестать их обработку на ранней стадии.

Кэшируем то, что меняется

Иная подкатегория кэшей — ExpiryCaches. Они основаны на постулировании того, что объект либо его части не будут менять свое состояние в течение какого-то интервала времени. Классический пример такого объекта — профиль пользователя на сайте онлайн знакомств. Если пользователь А редактирует свой профиль, то для пользователя Б, тот, что просматривает профиль пользователя А, не твердо значимо, увидит ли он эти метаморфозы через 5, 30 либо 60 секунд (исключительно, если эти пользователи не контактируют). Тем самым мы можем зафиксировать состояние профиля пользователя А на время, незначительное для человека, но длинное с точки зрения машины, и трудиться с зафиксированной версией.

Источник: programmingmaster.ru

Оставить комментарий

Ваш email не будет опубликован. Обязательные поля помечены (обязательно)

Вы можете использовать это HTMLтеги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2014 © BB3x.ru - русская поддержка форума phpBB