6 распространенных проблем с кешем с высокой степенью параллелизма, сколько вы знаете?

Вообще говоря, общий процесс текущего веб-сайта Интернет-приложения или приложения может быть представлен тем, что мы показываем на этом рисунке.Запрос пользователя начинается с этого интерфейса, самого внутреннего браузера и приложения, к пересылке по сети, а затем к приложению. Службы и, наконец, хранилище, которое, возможно, является файловой системой базы данных, а затем обратно в интерфейс для отображения содержимого.

С популяризацией Интернета информация о содержании становится все более и более сложной, количество пользователей и количество посещений увеличивается, нашим приложениям необходимо поддерживать больше параллелизма, и в то же время вычисления, выполняемые нашими серверами приложений и серверы баз данных также увеличиваются.Чем больше, однако, ресурсы нашего сервера приложений часто ограничены, а технологические изменения идут медленно, поэтому количество запросов, которые можно получить в секунду, также ограничено, или чтение и запись файлы также ограничены.

Как мы можем эффективно использовать ограниченные ресурсы, чтобы обеспечить максимально возможную пропускную способность? Эффективным способом является введение кеша, чтобы нарушить стандартный процесс на рисунке.Запросы в каждой ссылке могут напрямую получать целевые данные из кеша и возвращать их, тем самым уменьшая объем их вычислений, эффективно улучшая скорость ответа и позволяя использовать ограниченные ресурсы. В каждой ссылке от 1 до 4 может отображаться больше пользователей, как показано на этом рисунке.

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

Это больше зависит от стратегии истечения срока действия и обновления кэша. Как правило, при изменении данных данные в кэше активно обновляются или соответствующий кэш удаляется.

По истечении срока действия кеша будет предпринята попытка получить данные из серверной базы данных, что вполне вероятно. Однако в сценарии с высокой степенью параллелизма несколько запросов могут одновременно получать данные из базы данных, что оказывает сильное влияние на серверную базу данных и даже вызывает явление «лавины».

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

Мы будем думать о механизме, похожем на «блокировку». В случае обновления или истечения срока действия кеша сначала попытайтесь получить блокировку и снять блокировку, когда обновление или получение из базы данных будет завершено. Для других запросов нужно только пожертвовать определенное время ожидания Продолжить выборку данных непосредственно из кеша.

Проникновение в кеш в некоторых местах также называют «пробой». Многие друзья понимают проникновение в кеш так, что из-за сбоя кеша или истечения срока действия кеша большое количество запросов проникает на внутренний сервер базы данных, что оказывает огромное влияние на базу данных.

На самом деле это недоразумение. Реальное проникновение в кеш должно выглядеть так:

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

Существует несколько распространенных способов избежать кэширования устаревших проблем:

1. Кешируйте пустые объекты

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

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

2. Отдельная обработка фильтров

Все ключи, соответствующие данные которых могут быть пустыми, хранятся единообразно и перехватываются перед запросом, чтобы предотвратить проникновение запроса во внутреннюю базу данных. Этот метод относительно сложен в реализации и больше подходит для данных с небольшим числом обращений, но нечастыми обновлениями.

Переполнение кеша, которое в некоторых местах может называться «переполнением кеша», может рассматриваться как более мелкий сбой, чем «лавина», но оно также может вызвать шок и влияние на производительность системы в течение определенного периода времени. Обычно вызывается сбоем узла кэша. В отрасли рекомендуется решать эту проблему с помощью согласованного алгоритма хеширования.

Лавина кеша означает, что из-за кеша большое количество запросов достигает серверной базы данных, что приводит к краху базы данных, краху всей системы и катастрофе.

Причин этому явлению много.Вышеупомянутые «параллелизм кеша», «проникновение кеша», «переполнение кеша» и другие проблемы могут на самом деле вызывать лавины кеша. Эти проблемы также могут быть использованы злоумышленниками.

В другой ситуации, например, в определенный момент времени предварительно загруженные системой кеши периодически инвалидируются, что также может привести к лавинному сбросу. Чтобы избежать этой периодической аннулирования, истечение срока действия кеша можно распределить по времени, установив разное время истечения срока действия, тем самым избегая централизованного аннулирования кеша.

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

Кроме того, с точки зрения всего процесса системы НИОКР стресс-тестирование должно быть усилено, чтобы максимально имитировать реальные сценарии и как можно скорее выявлять проблемы для их предотвращения.

Эта проблема была поднята сотрудниками Facebook. Примерно в 2010 году у Facebook было 3000 узлов memcached, которые кэшировали тысячи гигабайт контента.

Нашли проблему---частота подключения memcached, эффективность снизилась, поэтому добавили узлы memcached.Добавив их, они обнаружили, что проблема, вызванная частотой подключения, все еще существует и не улучшается, что было названо «феноменом бездонной ямы». .

В настоящее время основные технологические стеки, такие как базы данных, кэши, Nosql и промежуточное программное обеспечение поиска, поддерживают технологию «сегментирования» для удовлетворения требований «высокой производительности, высокой степени параллелизма, высокой доступности и масштабируемости».

Некоторые сопоставляются с разными экземплярами по модулю Hash (или согласованному хешу) на стороне клиента, а некоторые сопоставляются по значениям диапазона на стороне клиента. Конечно, некоторые из них выполняются на стороне сервера.

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

Его можно избежать и оптимизировать в основном по следующим аспектам:

1. Метод распространения данных

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

2. Оптимизация ввода-вывода

Вы можете в полной мере использовать пул соединений, NIO и другие технологии, чтобы максимально снизить нагрузку на соединение и расширить возможности параллельного соединения.

3. Метод доступа к данным

Получение большого набора данных за один раз будет иметь меньшую нагрузку на сетевой ввод-вывод, чем многократное получение небольшого набора данных.

Конечно, явление бездонного кэша встречается не часто. Наверное, не во всех компаниях.