проблемы с когерентностью кэша
Когда требования своевременности данных очень высоки, необходимо убедиться, что данные в кеше согласуются с данными в базе данных, а данные в узле кеша и реплике должны быть согласованы, и не должно быть никаких различий. . Это больше зависит от стратегии истечения срока действия и обновления кэша. Как правило, при изменении данных данные в кэше активно обновляются или соответствующий кэш удаляется.
проблема параллелизма кеша
По истечении срока действия кеша будет предпринята попытка получить данные из серверной базы данных, что вполне вероятно. Однако в сценарии с высокой степенью параллелизма несколько запросов могут одновременно получать данные из базы данных, что оказывает сильное влияние на серверную базу данных и даже вызывает явление «лавины». Кроме того, при обновлении ключа кэша он также может быть получен большим количеством запросов, что также приведет к проблемам согласованности. Так как же избежать подобных проблем? Мы будем думать о механизме, похожем на «блокировку». В случае обновления или истечения срока действия кеша сначала попытайтесь получить блокировку и снять блокировку, когда обновление или получение из базы данных будет завершено. Для других запросов нужно только пожертвовать определенное время ожидания Продолжить выборку данных непосредственно из кеша.
проблема проникновения в кеш
Проникновение в кеш в некоторых местах также называют «пробой». Многие друзья понимают проникновение в кеш так, что из-за сбоя кеша или истечения срока действия кеша большое количество запросов проникает на внутренний сервер базы данных, что оказывает огромное влияние на базу данных.
На самом деле это недоразумение. Реальное проникновение в кеш должно выглядеть так:
В высоких сценариях совпадения, если ключ является высоким параллельным доступом, не ударилось, постарается добраться от базы данных в ответственную базу данных для рассмотрения неисправностей, что приводит к большому количеству запросов, достигших базы данных, и когда соответствующая Ключ, когда сама данные пуста, что привело к параллелизму базы данных, чтобы нести много ненужных поисковых операций, что приводит к огромному давлению и удару.
Существует несколько распространенных способов избежать кэширования устаревших проблем:
- Кэшировать пустые объекты
Объекты с пустыми результатами запроса также кэшируются. Если это коллекция, пустая коллекция (ненулевая) может быть кэширована. Если кэшируется один объект, его можно отличить по идентификатору поля. Это предотвращает проникновение запросов в серверную базу данных. При этом также необходимо обеспечить своевременность кэшируемых данных. Этот метод менее затратен в реализации и больше подходит для данных, которые имеют мало совпадений, но могут часто обновляться.
- отдельная обработка фильтра
Все ключи, соответствующие данные которых могут быть пустыми, хранятся единообразно и перехватываются перед запросом, чтобы предотвратить проникновение запроса во внутреннюю базу данных. Этот метод относительно сложен в реализации и больше подходит для данных с небольшим числом обращений, но нечастыми обновлениями.
проблема с забивкой кеша
Переполнение кеша, которое в некоторых местах может называться «переполнением кеша», может рассматриваться как более мелкий сбой, чем «лавина», но оно также может вызвать шок и влияние на производительность системы в течение определенного периода времени. Обычно вызывается сбоем узла кэша. В отрасли рекомендуется решать эту проблему с помощью согласованного алгоритма хеширования. Я не буду вдаваться в подробности, вы можете обратиться к другим главам.
Кэшированная лавина
Лавина кеша означает, что из-за кеша большое количество запросов достигает серверной базы данных, что приводит к краху базы данных, краху всей системы и катастрофе. Причин этому явлению много.Вышеупомянутые «параллелизм кеша», «проникновение кеша», «переполнение кеша» и другие проблемы могут на самом деле вызывать лавины кеша. Эти проблемы также могут быть использованы злоумышленниками. В другой ситуации, например, в определенный момент времени предварительно загруженные системой кеши периодически инвалидируются, что также может привести к лавинному сбросу. Чтобы избежать этой периодической аннулирования, истечение срока действия кеша можно распределить по времени, установив разное время истечения срока действия, тем самым избегая централизованного аннулирования кеша.
С точки зрения архитектуры приложения мы можем уменьшить влияние с помощью ограничения тока, перехода на более раннюю версию и прерывателя цепи, а также можем избежать таких аварий с помощью многоуровневого кэширования.
Кроме того, с точки зрения всего процесса системы НИОКР стресс-тестирование должно быть усилено, чтобы максимально имитировать реальные сценарии и как можно скорее выявлять проблемы для их предотвращения.
Тайник бездонный феномен
Эта проблема была поднята сотрудниками Facebook. Примерно в 2010 году у Facebook было 3000 узлов memcached, которые кэшировали тысячи гигабайт контента.
Они нашли проблему --- частоту подключения к памяти, эффективность уменьшилась, поэтому добавьте Memcached Node,
После его добавления было обнаружено, что проблема, вызванная частотой подключения, все еще существует и не улучшилась, что называется «феноменом бездонной ямы».
В настоящее время основные технологические стеки, такие как базы данных, кэши, Nosql и промежуточное программное обеспечение поиска, поддерживают технологию «сегментирования» для удовлетворения требований «высокой производительности, высокой степени параллелизма, высокой доступности и масштабируемости». Некоторые сопоставляются с разными экземплярами по модулю Hash (или согласованному хешу) на стороне клиента, а некоторые сопоставляются по значениям диапазона на стороне клиента. Конечно, некоторые из них выполняются на стороне сервера. Однако для выполнения каждой операции может потребоваться сетевое взаимодействие с разными узлами.Чем больше узлов-экземпляров, тем больше накладные расходы и больше влияние на производительность.
Его можно избежать и оптимизировать в основном по следующим аспектам:
- распределение данных
Некоторые бизнес-данные могут подходить для распределения хэшей, в то время как другие подходят для распределения диапазонов, что позволяет в определенной степени избежать накладных расходов на сетевой ввод-вывод.
- оптимизация ввода-вывода
Вы можете воспользоваться пулом подключений, NIO и другими технологиями, чтобы максимально снизить затраты на подключение и расширить возможности одновременных подключений.
- метод доступа к данным
Получение большого набора данных за один раз будет иметь меньшую нагрузку на сетевой ввод-вывод, чем многократное получение небольшого набора данных.
Конечно, явление бездонного кэша встречается не часто. Наверное, не во всех компаниях.