Понимание веб-кеширования (Redis)

Я работаю над веб-приложением, которое получает данные от поставщика API. Теперь мне нужен способ кэширования данных, чтобы избежать повторного вызова поставщика для тех же данных.

Затем я наткнулся на Redis, который, кажется, служит моей цели, но я не на 100% понимаю концепцию кеширования с использованием Redis. Я проверил их документацию, но не совсем понимаю, что они говорят.

Предположим, я только что развернул свой веб-сайт, и у меня есть мой первый посетитель по имени A. Поскольку A - первый посетитель, мой веб-сайт запросит новый набор данных через поставщика API, и через пару секунд страница будет загружен данными, которые хотел А.

Мой веб-сайт кэширует эти данные в Redis, чтобы обслуживать будущих посетителей, которые попадут на ту же страницу.

Теперь у меня второй гость Б.

B обращается к тому же URL-адресу страницы, что и A, и поскольку на моем веб-сайте эти данные хранятся в кеше, B обслуживается из кеша и будет загружаться гораздо быстрее, чем то, что было у A.

Соответствует ли мое понимание концепции веб-кеширования?

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


caching redis node-redis
person Seong Lee    schedule 15.10.2015    source источник

Ответы (1)


arrow_upward
8
arrow_downward

Да, ваше понимание веб-кеширования правильное, но оно может стать намного сложнее, в зависимости от вашего варианта использования. Redis - это, по сути, хранилище ключей и значений. Итак, если вам нужно кеширование на уровне приложения, ваша теоретическая пара ключ / значение будет выглядеть так:

key: /path/to/my/page
value: <html><...whatever...></html>

Если вам нужно кеширование на уровне пользователя, ваш теоретический ключ немного изменится:

key: visitorA|/path/to/my/page
value: <html><...whatever...></html>

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

Существуют клиентские библиотеки Redis, написанные для различных фреймворков веб-разработки и систем управления контентом, которые будут определять, как они обрабатывают кеширование (т. Е. Для конкретных пользователей или приложений). Если вы пишете собственное веб-приложение, вы можете выбрать кеширование на уровне приложения или на уровне пользователя и делать с кешированием все, что захотите.

person Rob Bailey    schedule 15.10.2015
comment
Спасибо, что нашли время объяснить это. Это очень помогает. Является ли кеширование на уровне приложений более распространенным выбором для Интернета? Каковы были бы плюсы и минусы этого выбора? - person Seong Lee; 16.10.2015
comment
Я предполагаю, что кэширование на уровне приложения более распространено, потому что оно обычно дает лучшие улучшения производительности, чем кэширование на уровне пользователя. Кэширование на уровне пользователя действительно эффективно только в том случае, если один и тот же пользователь снова и снова просматривает одни и те же ресурсоемкие страницы. Кэширование на уровне приложений просто проще, и вы получаете значительные преимущества кэширования (потому что от этого выигрывают все пользователи); но как только контент у разных пользователей различается, вам придется перейти к кэшированию на уровне пользователя. Вы также можете кэшировать по разделам страницы, где некоторые div кешируются для всех пользователей, а некоторые - для конкретных пользователей. Надеюсь, это поможет! - person Rob Bailey; 16.10.2015
comment
Существуют также другие типы кеширования, которые ускоряют работу. Например, в PHP есть кэширование APC, которое представляет собой кеширование самого кода на уровне байт-кода, которое может вдвое легко сократить задержку, при этом позволяя работать с учетом специфики пользователя. Действительно проста в использовании, и есть масса других. - person Rob Bailey; 16.10.2015
comment
Спасибо. Это очень помогло. - person Seong Lee; 18.10.2015