Оригинальная аннотация взята из:
Проникновение в кэш, параллелизм и сбои, решения от передовых архитекторов https://community.qingcloud.com/topic/463
В нашей практике некоторые оригинальные решения устарели. На основе оригинала мы добавляем несколько часто используемых решений.
Проникновение в кэш, Параллелизм и сбои, Прерывания синхронизации, Рекомендации и сценарии оптимизации
Когда мы используем кэширование, будь то Redis или Memcached, мы обычно сталкиваемся с тремя проблемами:
Проникновение в кэш
Кэш одновременно
Аннулирование кэша
Прерывание синхронизации и репликации
Проникновение в кэш
Примечание: В чем проблемы с приведенными выше тремя цифрами?
Когда мы используем кэширование в проектах, мы обычно проверяем, существует ли кэш или нет. Если есть кэшированное содержимое напрямую, если кэшированного содержимого нет, мы запрашиваем базу данных напрямую, а затем кэшируем результаты запроса для возврата.
На этом этапе, если мы запросим определенные данные в ____________ Если кэш не существует все время, это приведет к тому, что БД будет запрашиваться для каждого запроса. Таким образом, кэш теряет свое значение, и при высоком трафике база данных может зависнуть.
Каков наилучший способ решения этой проблемы?
Если кто-то часто использует несуществующие ключи для атаки на наши приложения, это уязвимость. Один из разумных способов сделать это-представить несуществующий ключ к значению. Например, “ключ”,”&”.
Когда мы возвращаем это значение&, наше приложение может предположить, что ключа нет, и тогда наше приложение может решить, продолжать ли ждать доступа или отказаться от этой операции. Если вы продолжаете ждать доступа после определенного периода времени в точке опроса, вы снова запрашиваете ключ. Если значение больше не &&, вы можете считать, что ключ в данный момент является ценным, что позволяет избежать передачи в базу данных, тем самым блокируя большое количество аналогичных запросов в кэше.
Вы должны отметить, что причина, по которой кэш пропущен здесь, более достойна нашего внимания.
Когда пространство кэша заполнено, сбой синхронизации, перегрузка сети, сбой записи в кэш и другие причины, на сервере кэша не будет ключа. Или из-за прерывания синхронизации в архитектуре “ведущий-ведомый” трагедия записи на ведущий, но не на ведомый, приведет к тому, что запросы будут проникать на уровень БД.
В этом случае запросы не должны напрямую проникать на уровень БД, чтобы избежать влияния сбоя БД на другие предприятия. На наше решение можно сослаться.
Когда количество запросов очень велико и кэш пропускает, мы должны отказаться от определенной доли запросов и вернуться к пустым непосредственно на основе установления защиты БД.
Некоторые запросы могут быть случайным образом отправлены в базу данных, что гарантирует восстановление кэша, и база данных не будет находиться под чрезмерным давлением, если трафик хорошо контролируется.
Серверная асинхронная синхронизация проверяет наличие кэшей и активно устанавливает их
Некоторые страницы могут быть кэшированы, срок действия которых никогда не истекает. Серверная асинхронная синхронизация проверяет кэш, активно обновляет и перестраивает его. Сбой внутренней части также может привести к деградации бизнеса.
Настроив дополнительный кэш, кэшированные данные, успешно полученные ранее, могут быть помещены в локальный кэш, файл или общую память, и некоторые данные с истекшим сроком действия могут быть приняты.
Кэш одновременно
Иногда, если одновременный доступ к веб-сайту высок, в случае сбоя кэша может быть несколько процессов, одновременно запрашивающих базу данных, настраивая кэш. Если параллелизм действительно велик, это также может вызвать давление на БД и проблему частых обновлений кэша. Моя идея сейчас состоит в том, чтобы заблокировать запрос кэша, если КЛЮЧ не существует, заблокировать его, а затем проверить базу данных в кэше, а затем разблокировать; если другие процессы обнаружат блокировку, подождите, а затем верните данные после разблокировки или введите запрос БД.
Эта ситуация несколько похожа на только что упомянутую проблему с текущим значением, но использование блокировок может привести к тому, что некоторые запросы будут ждать.
Аннулирование кэша
Основной причиной этой проблемы является высокий уровень параллелизма. Обычно, когда мы устанавливаем время истечения срока действия кэша, некоторые из них будут установлены на 1 минуту или 5 минут. При высоком уровне параллелизма в определенное время будет создано много кэшей, и время истечения срока действия будет одинаковым. В это время это может привести к потере этих кэшей одновременно с истечением срока действия. По сути, все запросы перенаправляются в базу данных, которая может находиться под слишком большим давлением.
Как решить эти проблемы?
Одна из простых схем состоит в том, чтобы распределить время сбоя кэша. Например, мы можем добавить случайное значение, основанное на исходном времени сбоя, например, случайность 1-5 минут, чтобы частота повторения каждого времени истечения срока действия кэша была уменьшена, и было трудно инициировать события коллективного сбоя.
Второй вопрос, который мы обсуждали, касался одного и того же кэша, а третий – множества кэшей.
Затем мы опубликуем некоторые из наших собственных методов высокой доступности кэширования, таких как Методы высокой доступности кластера кэширования на основе облачной платформы. Приветствую ваше внимание.
сводка 1. Проникновение в кэш: Запрос данных, которые не должны существовать. Например, таблица статей запрашивает несуществующий идентификатор и каждый раз обращается к базе данных. Если кто-то злонамеренно повредит БД, это, скорее всего, напрямую повлияет на БД. 2. Сбой кэша: Если кэш сконцентрирован в течение определенного периода времени, давление БД заметно. Идеального решения этой проблемы не существует, но поведение пользователей может быть проанализировано, и моменты времени сбоя могут быть распределены равномерно, насколько это возможно.
Лавина кэша возникает, когда происходит большое количество проникновений в кэш, например, при большом одновременном доступе к отказавшему кэшу.
Замечательные вопросы и ответы Вопрос: Как решить проблему согласованности БД и кэша?
Когда база данных была изменена, вы вовремя изменили кэш? Такого рода проблемы, которые практиковались ранее, успешно изменяют базу данных, и сбой изменения кэша в основном вызван зависанием сервера кэша. Однако из-за отсутствия своевременных обновлений, вызванных сетевыми проблемами, это может быть решено с помощью механизма повторных попыток. Когда сервер кэша зависает, запросы, естественно, не будут поступать первыми, что приведет к прямому доступу к базе данных. Тогда мы не сможем изменить кэш после изменения базы данных. В это время мы можем поместить эти данные в базу данных и запустить асинхронную задачу, чтобы проверить, успешно ли подключен сервер кэша. После успешного подключения мы можем извлечь измененные данные из базы данных по порядку и, в свою очередь, изменить последнее значение кэша.
Вопрос: Попросите кэш проникнуть в этот фрагмент! Например, пользователь запрашивает статьи через идентификатор, в соответствии с тем, что было сказано ранее, чтобы задать значение для КЛЮЧА кэша. Если он интерполируется через идентификатор, обнаруживается, что это заданное значение, такое как”&”, то что значит продолжать ждать доступа после этого? Когда идентификатор действительно будет привязан к значению, необходимому пользователю?
То, что я только что сказал, – это в основном сцены, которые мы обычно используем в задней конфигурации и при съемке на переднем плане. Если на стойке регистрации не могут получить ключ, подождите или сдавайтесь. Когда ключ и значение настроены в интерфейсе фоновой конфигурации, предыдущий ключ и значение, естественно, будут заменены. В этом случае, конечно, должен быть процесс, который устанавливает идентификатор в кэше в определенное время, а затем получает последний идентификатор и значение при поступлении нового запроса.
Вопрос: С Redis я видел хороший пример в тот день, двойной ключ, к которому был прикреплен ключ, сгенерированный в то время, чтобы отметить дату истечения срока действия изменения данных, а затем перезагрузить данные, когда они будут рядом. Если я думаю, что этот ключ может указать время окончания в главном ключе, прикрепленный ключ может действовать как замок.
Мы уже делали это раньше. Эта схема генерирует две копии данных и должна одновременно контролировать взаимосвязь между прикрепленным ключом и ключом, что имеет определенную степень сложности в эксплуатации.
Вопрос: В чем заключается концепция многоуровневого кэширования?
Многоуровневое кэширование, как я упоминал в статье, которую я отправил вам ранее сегодня, использует Ehcache и Redis в качестве вторичного кэширования, как я упоминал в своей предыдущей статье http://www.jianshu.com/p/2cd6ad416a5a. Но также возникнут проблемы с согласованностью. Если нам нужна сильная согласованность, между синхронизацией кэша и базы данных будет задержка по времени. Поэтому в процессе конкретного развития мы должны проводить конкретный анализ в соответствии со сценариями. Кэш второго уровня больше предназначен для решения проблемы проникновения в кэш и надежности программ. Когда возникает проблема с централизованным кэшем, наше приложение может продолжать работать. Все в порядке.