作者 陈彩华
文章转载交流请联系 caison@aliyun.com

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

1 Обзор кэша

2 Классификация кеша

Кэши в основном делятся на следующие четыре категории

2.1 Кэш CDN

основное введение

Основной принцип CDN (Content Delivery Network) заключается в широком использовании различных кеш-серверов и распределении этих кеш-серверов по регионам или сетям, где доступ пользователей относительно сконцентрирован. Запросы

Сценарии применения

В основном кэшируйте статические ресурсы, такие как изображения, видео

Схема применения

преимущество

2.2 Кэш обратного прокси

основное введение

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

Сценарии применения

Как правило, кэшируются только небольшие статические файловые ресурсы, такие как css, js, изображения.

Схема применения

Реализация с открытым исходным кодом

2.3 Кэш локального приложения

основное введение

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

Сценарии применения

Кэшировать общие данные, такие как словари

кеш-носитель

выполнить

программирование напрямую

Ehcache

основное введение

Ehcache — это основанный на стандартах кэш с открытым исходным кодом, который повышает производительность, разгружает базы данных и упрощает масштабирование. Это наиболее широко используемый кеш на основе Java, поскольку он мощный, проверенный, полнофункциональный и интегрируется с другими популярными библиотеками и платформами. Ehcache может масштабироваться от внутрипроцессного кэширования до гибридных внутрипроцессных/внепроцессных развертываний с использованием терабайтных кэшей.

Сценарии применения

Схема архитектуры Ehcache

Основные возможности Ehcache

Политика истечения срока действия кэша Ehcache

Механизм удаления просроченных данных Ehcache

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

Guava Cache

2.4 Распределенный кеш

основное введение

Guava Cache — это инструмент кэширования в Guava, библиотеке набора инструментов повторного использования Java с открытым исходным кодом от Google.

Особенности и функции

Сценарии применения

диаграмма структуры данных

стратегия обновления кеша

Политика восстановления кэша

2.4 Распределенный кеш

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

Основные сценарии применения

Основной метод доступа

Ниже представлены две распространенные реализации распределенного кэширования с открытым исходным кодом, Memcached и Redis.

Memcached

основное введение

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

Функции

Базовая архитектура

Политика истечения срока действия кэша

Политика истечения срока действия LRU (наименее недавно использованная), при сохранении элемента данных в Memcached можно указать время его истечения в кеше, по умолчанию — постоянное. Когда на сервере Memcached заканчивается выделенная память, сначала заменяются устаревшие данные, а затем самые последние неиспользованные данные.

Внутренняя реализация удаления данных

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

Реализация распределенного кластера

Сервер не имеет "распределенной" функции. Каждый сервер является полностью независимым и изолированным сервисом. Раздача Memcached осуществляется клиентской программой

Redis

основное введение

Redis — это удаленная база данных в памяти (нереляционная база данных)., с высокой производительностью, характеристиками репликации и уникальной моделью данных для решения проблем. Он может хранить сопоставление между парами ключ-значение и 5 различными типами значений, может сохранять данные пары ключ-значение, хранящиеся в памяти, на жестком диске и может использовать функцию репликации для увеличения производительности чтения. Redis также может использовать сегментирование на стороне клиента для масштабирования производительности записи. Встроенная репликация (replication), сценарии LUA (сценарии Lua), события, управляемые LRU (выселение LRU), транзакции (transactions) и различные уровни персистентности диска (persistence), а также через Redis Sentinel (Sentinel) и автоматический раздел (Cluster ) Обеспечить высокую доступность (высокая доступность).

модель данных

Политика удаления данных

Внутренняя реализация удаления данных

Упорство

Частичный анализ базовой реализации

• Иллюстрация части процесса запуска

  

• Частичная диаграмма работы сохраняемости на стороне сервера

  

• Реализация низкоуровневой хэш-таблицы (прогрессивный перехеширование)

инициализировать словарь

Добавлена ​​диаграмма элементов словаря.

Перефразировать процесс выполнения

Принципы проектирования кэша

Сравнение Redis и Memcached

	Redis	Memcached
Поддерживаемые структуры данных	Хэш, список, набор, отсортированный набор	чистое кэВ-значение
Постоянная поддержка	имеют	никто
Поддержка высокой доступности	Redis естественно поддерживает функции кластеризации, которые могут обеспечить активную репликацию и разделение чтения и записи. Официальный также предоставляет инструмент управления дозорным кластером, который может осуществлять мониторинг службы master-slave и автоматическое переключение при отказе, все из которых прозрачны для клиента, без изменения программы или ручного вмешательства.	нужно вторичное развитие
Емкость хранения	Максимум 512М	Макс 1 м
выделение памяти	Временно запрашивать место, что может привести к фрагментации	Управляйте памятью, предварительно выделяя пулы памяти, что может сократить время выделения памяти.
использование виртуальной памяти	У него есть собственный механизм VM, который теоретически может хранить больше данных, чем физическая память.Когда данные превышают, он запускает своп и сбрасывает холодные данные на диск.	Все данные хранятся в физической памяти
сетевая модель	Неблокирующая модель мультиплексирования ввода-вывода обеспечивает некоторые функции сортировки и агрегации, отличные от хранилища без KV.При выполнении этих функций сложные вычисления ЦП блокируют все планирование ввода-вывода.	Неблокирующая модель мультиплексирования ввода-вывода
Поддержка горизонтального масштабирования	Нет	Нет
Многопоточность	Redis поддерживает один поток	Memcached поддерживает многопоточность, а Memcache лучше, чем Redis, с точки зрения использования ЦП.
Политика истечения срока действия	Существует специальный поток для очистки кэшированных данных.	Ленивый механизм исключения: каждый раз, когда вы помещаете данные в кеш, это экономит время, при чтении вам нужно сравнить TTL с установленным временем, чтобы определить, не истек ли он.
Автономные запросы в секунду	Около 10 Вт	Около 60 Вт
читабельность исходного кода	Чистый и лаконичный код	Может быть, слишком много масштабируемости, мультисистемной совместимости и нечистого кода.
Применимая сцена	Сложная структура данных, постоянство, требования к высокой доступности, хранение большого объема содержимого.	Чистый KV, очень большой объем данных, очень большой параллельный бизнес

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

Более интересно, добро пожаловать на официальный аккаунт автора [архитектура распределенной системы]

Ссылаться на

Изучаем архитектуру с нуля - Alibaba Ли Юньхуа

36 лекций по технологии Java Core — Oracle Yang Xiaofeng

Анализ дизайна архитектуры Redis — запретная зона Бога

Официальная документация Memcached

Разница между RDB и AOF в режиме персистентности Redis - 58 Shen Jian

Кэш, ты действительно его правильно используешь? —— 58 Шэнь Цзянь

Выберите Redis или memcached, что говорит исходный код? —— 58 Шэнь Цзянь

Кэшируйте эти вещи - техническая команда Meituan

Принципы проектирования Redis Cache — Сюэ Фейхун

Стратегия кэширования Redis и механизм аннулирования первичного ключа — Бинг Юэ