В предыдущая часть мы говорили об основных архитектурных принципах построения масштабируемых порталов.
Сегодня мы поговорим об оптимизации правильно построенного портала.
Итак: первый вид оптимизации — локальный кэш.
Часть вторая.
Кэширование Как я уже упоминал в предыдущая часть Речь идет, прежде всего, о B2C-порталах.
У этих порталов есть общее свойство: преобладание запросов на чтение над запросами на запись.
Причем зачастую преобладание составляет 10 и более раз.
Понятно, почему кэширование кажется таким многообещающим инструментом.
Тайники — интересная и практически бесконечная тема.
Поэтому я постараюсь изложить это достаточно кратко для первого раунда оптимизации, не вдаваясь в подробности о кеше 1 и 2 уровня, распределенном кеше и т. д. Поскольку нам нужно кэшировать чтение объекта, мы пока пропустим кэш записи (кеш записи).
Когда мы запускаем локальное кэширование, мы обычно стоим перед выбором: кэш запроса или объекта (кэширование вызовов или объектов).
Кэш запросов (или кеш методов) — это кеш, который можно использовать «внешне»: он записывает результаты вызовов методов (запросов), и мы предполагаем, что одни и те же запросы вызывают одинаковые ответы.
При повторении одного и того же запроса несколько раз, начиная со второго раза, вы можете пропустить сложную и трудоемкую обработку и просто вернуть предыдущий результат. Преимущество таких кешей в том, что они не зависят ни от архитектуры, ни от домена, то есть интегрируются как утилита (например, аспект) в готовый продукт, не сильно его меняя.
В отличие от этого преимущества, они имеют ряд недостатков:
- Они неэффективны, когда у нас есть богатые интерфейсы с несколькими методами чтения одного и того же объекта.
Причина в том, что они кэшируют путь к объекту, а не сам объект.
- Их размер зависит не от количества возможных объектов (результатов), а от количества возможных запросов, поэтому они обычно тяжелее альтернатив.
Их размер и объем необходимой памяти сложно спланировать.
- Они некрасивы.
Идеальная реализация кэша объектов — это коллекция (список или набор в зависимости от требований), содержащая все объекты, управляемые этим сервисом, в их объектной форме.
В идеале служба должна иметь возможность отвечать на каждый запрос, используя кеш и не обращаясь к внешнему хранилище (например, к базе данных).
К сожалению, такое 100%-ное кэширование редко достижимо, но там, где его можно применить, оно всегда экономически эффективно.
Лучшим примером 100% кэширования являются учетные записи пользователей.
Они обычно небольшие (состоят из id, email, имени, времени регистрации и т.д.) и постоянно требуются в разных местах приложения.
Кэширование того, чего нет
Другой полезной формой кеша является так называемый нулевой кеш или отрицательный кеш.В большинстве случаев кэши объектов заполняются во время работы приложения, поэтому возможен так называемый «холодный старт» и создание новых объектов в базе данных, с одновременным существованием нескольких экземпляров одного и того же сервиса.
В результате обращения к приложению могут «пробить» кэш и достичь базы данных.
Если такое «пробитие» происходит постоянно, это может привести к перегрузке базы.
Тогда все наши тайники, построенные с таким трудом, потеряют всякую эффективность и защитную функцию.
Для борьбы с такой перегрузкой существуют отрицательные кеши, которые запоминают объекты, которые когда-то были неудачно запрошены, тем самым давая сервису возможность прекратить их обработку на раннем этапе при следующем запросе.
Кэшировать изменения
Еще одна подкатегория кешей — ExpiryCaches. Они основаны на постулате, что объект или его части не изменят своего состояния в течение определенного периода времени.Типичным примером такого объекта является профиль пользователя на сайте знакомств.
Если Пользователь А редактирует свой профиль, то для Пользователя Б, который просматривает профиль Пользователя А, не принципиально важно, увидит ли он эти изменения через 5, 30 или 60 секунд (особенно если эти пользователи не в контакте).
Таким образом, мы можем зафиксировать состояние профиля пользователя А на незначительное для человека, но длительное с точки зрения машины время и работать с фиксированной версией.
Тем самым мы предотвращаем обработку значительного количества запросов, которые, скорее всего, возвращали бы идентичный результат (ведь пользователи меняют свой профиль гораздо реже, чем, например, ищут или отвечают на сообщения), и экономим ресурсы.
Плата за эту экономию — это всего лишь риск того, что обновление в вашем профиле появится немного позже, чем в противном случае.
Особенно популярно этот прием используется на стороне клиента (веб-сервера) для экономии сетевого трафика (к базе данных или сервису) и, соответственно, времени.
Но это не единственный пример, когда целесообразно использовать Expiry Cache. Другой вариант использования — когда при обработке запроса мы предполагаем, что один и тот же объект будет запрошен много раз, но из мест кода, настолько удаленных друг от друга, что сохранение его значения в переменной невозможно или нецелесообразно.
Популярной технологией реализации таких промежуточных кешей является ThreadLocal (Java).
ExpiryCache — это не что иное, как обмен ресурсами (компромисс): мы жертвуем скоростью отображения изменений ради производительности приложения.
В целом масштабирование приложений (и особенно порталов) — это обмен ресурсов, которых у нас много, на те, которых нам не хватает: например, оперативной памяти на ЦП, сетевого трафика или ввода-вывода.
Кэширование — хороший метод оптимизации отдельного компонента или службы, но его возможности для оптимизации ограничены.
В какой-то момент нам придется признать, что предел того, что может обработать один экземпляр, достигнут, и нам необходимо масштабировать компоненты нашей архитектуры (то есть запускать их несколько копий).
Об этом - третья часть .
Теги: #java #масштабируемость #масштабируемость #soa #архитектура #архитектура #порталы #кэш #программирование #java #Системный анализ и проектирование
-
Можно Ли Заправить Мой Картридж?
19 Oct, 24 -
Недостаточно Сна, Но Ведь Так?
19 Oct, 24 -
Как Мы Решили Внедрить Pomodoro В Компании
19 Oct, 24 -
Сафари И Жирный Шрифт
19 Oct, 24 -
2 Миллиона Точек На Карте? Легко!
19 Oct, 24
