Введение и уточнение
Полагаю, у вас есть одно недопонимание, что кэш НЕ хранится явно на том же сервере, что и сервер werb. Иногда даже база данных не работает на своем собственном сервере с веб-сервера. Если вы думаете об API, таких как HTTP REST API, вы можете использовать кэширование, чтобы не тратить слишком много ресурсов на соединения и запросы к базе данных. Как правило, вы хотите использовать как можно меньше соединений и запросов к базе данных. Теперь представьте следующую настройку:
У вас есть werbserver, который обслуживает ваше приложение, и REST API, который используется веб-сервером для работы с некоторыми ресурсами. Эти ресурсы поступают из базы данных (скажем, реляционной базы данных), которая также хранится на том же сервере. Теперь есть одна конечная точка, которая обслуживает, например, список posts (например, посты в блоге). Каждый пользователь может получить все сообщения (для простоты в этом примере). Теперь у нас есть случай, когда можно сказать, что этот запрос API можно кэшировать, чтобы не позволить всем пользователям всегда запускать базу данных, просто запрашивать одни и те же ресурсы (через REST API) снова и снова. Вот идет кеширование . Redis - это один из многих инструментов, которые можно использовать для кэширования. Поскольку redis - это простое хранилище значений ключей в памяти, вы можете просто поместить все свои сообщения (вспомните REST API) после первого запроса DB в кэш. Все будущие запросы на список постов будут сначала проверять, кэшированы ли посты или нет. Если это так, API вернет кеш-контент для этого указанного c запроса.
Это один простой пример, чтобы показать, для чего может использоваться кэширование.
Ответы на ваш вопрос
Мой первый вопрос: зачем вам запись в кеш?
Чтобы уменьшить количество подключений к базе данных и запросов.
, как запись в эти хранилища значений ключей поможет с обновлением реляционной базы данных ?
Это не поможет вам с обновлением, но вместо этого поможет вам тратить меньше ресурсов. Это также помогает вам с точки зрения «временного резервного копирования» некоторых данных - но это лишь очень небольшой побочный эффект. Для этого есть более привлекательные решения (так как redis также не является постоянным по умолчанию. Но он поддерживает постоянство. )
Применяют ли эти стратегии записи в кэш только если ваш основной база данных также является хранилищем значений ключей?
Нет, не важно, какую базу данных вы используете. Будь то No SQL или SQL DB. Это сильно зависит от того, что вы хотите кэшировать и как база данных и ее таблицы настроены. Есть ли у вас частые изменения в ваших ресурсах? Обновляются ли ресурсы вручную или только по действиям, инициированным пользователем? Это вопросы, которые приведут вас к правильной реализации кэширования.
Разве нельзя смешивать и подбирать стратегии кэширования?
Я не эксперт по стратегиям кэширования , но позвольте мне попробовать: я думаю, что это возможно, но это также сильно зависит от того, что вы делаете в своей БД и какое у вас приложение. Я предполагаю, что если вы узнаете, какое приложение вы создаете, то вы будете знать, какую стратегию вы должны использовать - я думаю, что также не рекомендуется смешивать эти стратегии, потому что эти стратегии в сочетании с вашим типом приложения - другими словами: оно не будет работать очень хорошо.
Что произойдет, если у вас есть кластер веб-серверов? У каждого из них есть своя собственная локальная база данных в памяти, которая действует как кеш?
Полагаю, что оба варианта возможны. Обычно у вас есть одна база данных, может быть кластеризованная или синхронизированная с копиями, к которой ваши веб-серверы (например, API REST) делают свои запросы. Затем, будь у каждого из ваших серверов API свой собственный кеш, чтобы вообще не запрашивать базу данных (в облачных приложениях ваша база данных также может быть на другом отдельном сервере - так что еще один «скачок» с точки зрения сетевого взаимодействия). ИЛИ (что я также могу себе представить) у вас есть другое промежуточное ПО между вашими API (кластеризованными) и вашей БД (возможно, также кластеризованными) - но я думаю, что никто не сделает этого из-за сетевого трафика c. Это может привести к более высокому времени отклика, что вы обычно хотите предотвратить.
Не могли бы вы реализовать кеш, используя обычную (не в памяти) базу данных?
Да, вы могли бы, но это было бы намного медленнее. Машина может получить доступ к данным в памяти быстрее, чем создать другое (локальное) соединение с базой данных и запросить ваши кэшированные записи. Кроме того, поскольку ваша база данных должна записывать записи в файлы на вашем компьютере, чтобы сохранить данные.
Заключение
В общем, все дело в том, чтобы быть быстрым с точки зрения времени отклика и чтобы предотвратить много трафика сети c. Я надеюсь, что смогу немного помочь вам.