Решение iQIYI для локального кэширования в реальном времени

задняя часть база данных
Решение iQIYI для локального кэширования в реальном времени

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

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

1. Предпосылки

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

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

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

2. Идеи и планы

Первое сравнениеПреимущества и недостатки локального кэша и централизованного кэша:

1. Локальный кеш

Его преимущества:

(1) Кэш точки доступа, каждое расширение экземпляра эквивалентно расширению базы данных точки доступа;

(2) Высокая скорость попадания;

(3) Политика истечения срока действия;

(4) бизнес-логика работает быстро, а потери машины низки;

(5) Сильная способность против риска.

Его недостатки:

(1) Как правило, это пассивный кеш с низкой производительностью в реальном времени;

(2) Ограниченная емкость хранилища, оснащенный 2 ГБ ~ 4 ГБ, что достаточно для удовлетворения горячих данных большинства текущих сценариев.

2. Централизованный кэш

Его преимущества:

(1) Удобно обновлять Кэш в режиме реального времени;

(2) Высокая согласованность кеша.

Недостатки следующие:

(1) кластер слишком велик, а зависимость слишком тяжелая;

(2) Когда параллелизм высок, ввод-вывод слишком тяжел;

(3) Уязвимость к джиттеру сети между машиной приложения и машиной кэша;

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

Сравнивая преимущества и недостатки вышеперечисленного, большинство людей будут использовать локальный кэш-память точки доступа, а ** 4 ГБ локального хранилища обычно соответствуют обычным бизнес-данным точки доступа.Однако производительность локального кэша в реальном времени низкая.Как решить проблему с производительностью в реальном времени? Вот решение:

3. Решения

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

4. Описание программы

**(1) Фон управления: **Управление всеми экземплярами приложений и политиками кэширования, использующими локальный кэш;

(2) Изменение данных: Источник изменения данных;

** (3) Автобус: ** распределительный центр сообщений;

** (4) Бизнес-фильтр: ** бизнес-сторона может сама обрабатывать часть сообщения;

**(5) Мониторинг статистики: ** Используя унифицированную систему сбора журналов iQIYI, ее можно использовать для статистического анализа данных точек доступа и обеспечения поддержки данных для других решений точек доступа. пример.

3. Расширение

Когда частота попаданий в локальный кэш одного кластера ниже допустимого порога (например, 70%), ограничения памяти не могут расширить локальное хранилище кэша,Его можно разделить на легкие логические кластеры сегментирования данных, чтобы повысить частоту попаданий.

В-четвертых, резюме эффекта

(1) Эффективно снижаетКластерная лавинариски;

(2) решеноВысокая скорость одновременного чтенияПроблема;

(3) уменьшитьПроникновение в сеть данных точек доступа, уменьшить нагрузку на централизованный кэш.