предисловие

При ведении бизнеса, связанного с C-стороной, текущая основная реляционная база данных трудно обеспечить низкую задержку и высокую степень параллелизма в сценарии запросов с высокой степенью параллелизма и может даже быть приостановлена. Таким образом, внедрение промежуточного ПО для кеша является распространенным решением, но как обеспечить согласованность между кешем и базой данных стало сложной проблемой.На этот раз мы возьмем в качестве примеров распространенные Mysql и Redis.

текст

Чтобы поддерживать согласованность кеша и базы данных, самый простой способ — напрямую выполнять двойную запись или удаление в бизнесе для поддержания согласованности; если вы хотите отвязаться от бизнеса, вам нужно подписаться на binlog или регулярно обновлять.

Согласованное решение для объединения бизнеса

Связывание кеша обновлений в бизнесе

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

Недостатки:

1. Когда происходят одновременные изменения данных, например, A и B изменяют одну и ту же строку данных, сначала изменяется A, затем изменяется B, B обновляет кэш, а A обновляет кэш. Данные в базе данных — это данные Б, а в кеше — данные А.
2. Не рекомендуется связываться с бизнесом, увеличивать сложность бизнеса и зависеть от промежуточного программного обеспечения.

Соединение удаления кеша в бизнесе

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

Недостатки:

1. Для удаления кеша очевидным недостатком является то, что при удалении кеша на втором шаге, если запрос данных поддерживает здесь высокий трафик, будет большое количество запросов, попадающих в БД через кеш, и все еще остается большой риск. ;
2. Он по-прежнему не отделен от бизнеса.

Единое решение для разделения бизнеса

Для Mysql, если вы хотите отвязаться от бизнеса, первое, что приходит вам в голову, должно быть binlog, потому что в конце концов, binlog записывает полный объем реальных данных базы данных, маскируется под ведомый узел и подписывается на binlog для завершите бизнес-решение муфты, как показано ниже:Как показано на рисунке выше, кеш в настоящее время рассматривается как полное зеркало данных в БД, но нельзя избежать проблемы несогласованности кеша, вызванной многопоточным потреблением бинлога в параллельных сценариях.

Механизм обновления кеша Binlog, который представляет задачи синхронизации и механизм проверки данных.

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

Как показано на рисунке ниже, мы добавили два изменения на основе предыдущей схемы мониторинга бинлога.

1. Время генерации бинлога записывается при мониторинге потребления бинлога, и время бинлога каждый раз сравнивается для решения проблемы конечного несоответствия данных кеша и бд в случае многопоточного потребления;
2. Так как при каждом обновлении будет генерироваться бинлог, то для полного обновления таблицы конфигурации (не бизнес-полей, таких как set update_time=now()) может быть выполнено полное обновление данных и синхронизация с кешем, а запланированная задача запускается регулярно, чтобы можно было обновлять бизнес.Повышает отказоустойчивость.

Эпилог

Идеального решения не существует, есть только наиболее подходящее решение для вашего бизнеса.Если текущая инфраструктура слаба и сроки строительства короткие, то схема удаления кеша вкупе с бизнесом может в принципе соответствовать большинству сценариев, если сроки строительства устраивают, вы может изучить некоторые более последовательные сексуальные программы, даже представляя分布式事务Гарантировать, что кэшированные данные обновляются, не невозможно.

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