относительно повышения эффективности кэш-тяжелой системы - PullRequest
1 голос
/ 05 июня 2019

Я собираюсь улучшить эффективность тяжелой системы кеша, которая имеет следующие свойства / архитектуру:

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

Сервер создает данные и записывает их в реляционную базу данных, которая реплицируется в несколько центров обработки данных.

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

(Политика удаления кэша основана на LRU).

Хочу отметить, что с реализацией выше есть две проблемы:

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

Можете ли вы посоветовать решение, которое устранит обе эти проблемы?

должно ли решение измениться, если данные хранятся в nosql db, например, в cassandra, а не в классической базе данных?

1 Ответ

1 голос
/ 05 июня 2019

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

  1. Сохранять длинные TTL или кешировать вечно, но при обновлении данных кеша сделать недействительными Это может быть довольно сложным и подверженным ошибкам
  2. Просто опустите TTL, чтобы получать более быстрые обновления. Подход с низким TTL - ИМХО подход КИСС. Мы идем всего 27 секунд. Кэш с таким низким TTL не имеет большого количества обращений при нормальной работе, но очень помогает, когда флэш-толпа попадает в ваше приложение

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

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

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

Если вы хотите сделать недействительным (решение 1), с Cassandara вы можете получить информацию из базы данных, данные которой обновлены, см. CASSANDRA-8844 . Вы можете получить аналогичную информацию из «классических» баз данных SQL, но это особенность поставщика.

...