предисловие
В распределенной системе, когда кеш и база данных сосуществуют, если есть операция записи, должна ли база данных или кеш работать в первую очередь? Сначала подумайте, какие проблемы могут существовать, а потом смотрите вниз. Ниже я опишу несколько вариантов.
Решение для обслуживания кэша 1
Предположим, что есть операции записи (поток A) и чтения (поток B),Сначала работайте с кешем, затем работайте с базой данных. , как показано на следующей блок-схеме:
1) Поток A инициирует операцию записи, первый шаг — удаление кеша.
2) Второй шаг потока A записывает новые данные в БД
3) Поток B инициирует операцию чтения, промах кеша,
4) Поток B получает последние данные из БД
5) Запросить B установить кеш одновременно
Посмотрите на это так, нет проблем. Давайте посмотрим на вторую блок-схему следующим образом:
1) Поток A инициирует операцию записи, первый шаг — удаление кеша.
2) В это время поток B инициирует операцию чтения, промах кеша
3) Поток B продолжает читать БД и считывает старые данные
4) Затем старые данные помещаются в кеш
5) Поток A записывает последние данные
Хорошо, Цзянцзы, есть проблема, старые данные в кеше,Каждое чтение — это старые данные, кеш и данные несовместимы с данными базы данных..
Решение для обслуживания кэша 2
двойная операция записи,Сначала работайте с кешем, затем работайте с базой данных.
1) Поток A инициирует операцию записи, первым шагом является установка кеша
2) Второй шаг потока A записывает новые данные в БД
3) Поток B инициирует операцию записи, установку кеша,
4) Второй шаг потока B записывает новые данные в БД
Таким образом, нет никаких проблем., но иногда это может иметь неприятные последствия, давайте посмотрим на вторую блок-схему, а именно:
1) Поток A инициирует операцию записи, первым шагом является установка кеша
2) Поток B инициирует операцию записи, первый шаг — setcache
3) Поток B записывает базу данных в БД
4) Thread A записывает базу данных в БД
После выполнения кэш сохраняет данные после операции B, а база данных сохраняет данные после операции A.Данные кеша и базы данных несовместимы.
Решение для обслуживания кэша 3
Операции записи (поток A) и чтения (поток B),Сначала работайте с базой данных, затем работайте с кешем.
1) Поток A инициирует операцию записи, первым шагом является запись БД
2) Второй шаг потока A del cache
3) Поток B инициирует операцию чтения, промах кеша
4) Поток B получает последние данные из БД
5) Поток B устанавливает кеш одновременно
эта схемаНет явных проблем с параллелизмом, но это возможноШаг 2 Не удалось удалить кеш, хотя вероятность относительно мала,Лучше, чем вариант 1 и вариант 2, вариант 3 тоже используется в обычной работе.
Подводя итог сравнению, мы обычно используем решение номер три, но есть ли способ исправить все недостатки решения номер три?
Решение для обслуживания кэша 4
Это план улучшения третьего плана, который заключается в том, чтобы сначала работать с базой данных, а затем с кэшем.Давайте посмотрим на блок-схему:
через базу данныхbinlogПриходитьАсинхронное устранение ключей, возьмем mysql в качестве примера МожетИспользуйте канал Али для отправки коллекции журналов binlog в очередь MQ.внутрь, точерез механизм ACK Подтвердить обработкуЭто сообщение об обновлении удаляет кэш, чтобы обеспечить согласованность кэша данных.
Но есть еще одинВопрос, а если это master-slave БД??
Решение для обслуживания кэша 5
Проблема с базой данных «главный-подчиненный»: поскольку синхронизация БД «главный-подчиненный» одновременно имеет время задержки, если есть запрос перед синхронизацией данных с резервной базой данных после удаления кеша,Грязные данные будут считаны из резервной базы данных., как решить? Решение выглядит следующим образом:
Сводка обслуживания кэша
Подводя итог, в распределенной системе, когда кеш и база данных существуют одновременно, если есть операция записи,Сначала работайте с базой данных, затем работайте с кешем. следующее:
(1) Есть ли соответствующие данные в кэше чтения
(2) Если в кеше есть соответствующее значение данных, вернуть
(3) Если в кеше нет соответствующих данных, прочитайте соответствующие данные из базы данных и поместите их в кеш-ключ->значение, а затем верните
(4) Если есть обновленные данные, сначала обновите данные, а затем удалите кеш.
(5) Чтобы обеспечить успешное удаление кеша на четвертом шаге, используйте binlog для его асинхронного удаления.
(6) Если это база данных master-slave, binglog берется из подчиненной библиотеки.
(7) Если это один мастер и несколько подчиненных, каждая подчиненная библиотека должна собирать бинарные журналы, а затем потребитель удалит кеш после получения последних данных бинлоговых данных.
Личный публичный аккаунт
- Приглашаем всех обратить внимание, учиться и обсуждать вместе.
- адрес гитхаба:GitHub.com/Я бы хотел 123/Java…