Схема синхронизации между MySQL и кешем Redis

Нет публики:Маленькое кофейное шоу Java,Веб-сайт:javaxks.com

Автор: Цзян Нань, Дун Шао, ссылка:Донг Шао.blog.CSDN.net/article/decent…

В этой статье представлены две схемы синхронизации кешей MySQL и Redis.

• Вариант 1: Redis автоматически синхронно обновляется через MySQL, реализованный триггером MySQL + функцией UDF.

• Вариант 2. Проанализируйте реализацию binlog MySQL и синхронизируйте данные в базе данных с Redis.

1. Схема 1 (УДФ)

Анализ сценария:

Когда мы выполняем операции с данными в базе данных MySQL, соответствующие данные одновременно синхронизируются с Redis.После синхронизации с Redis операция запроса выполняется из Redis.

Процесс примерно такой:

• Установите триггер Trigger для данных, которые будут обрабатываться в MySQL, и отслеживайте операцию.
• Когда клиент (NodeServer) записывает данные в MySQL, сработает триггер, а после триггера будет вызвана функция UDF MySQL.
• Функция UDF может записывать данные в REDIS для достижения эффекта синхронизации.

анализ случая:

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

• Поскольку триггеры MySQL сами по себе вызывают снижение эффективности, если таблица часто используется, эта схема не подходит.

Демонстрационный случай

• Ниже приведена таблица MySQL.

• Ниже приведен код разбора UDF.

• Определите соответствующий триггер

2. Вариант 2 (разбор бинлога)

• Прежде чем представить схему 2, давайте сначала представим принцип репликации MySQL, как показано на следующем рисунке:

  • Главный сервер обрабатывает данные и записывает данные в журнал Bin.

  • Подчиненный сервер вызывает поток ввода-вывода для чтения журнала Bin главного сервера, записывает его в свой собственный журнал ретрансляции, а затем вызывает поток SQL для анализа данных из журнала ретрансляции, тем самым синхронизируясь со своей собственной базой данных.

• Вариант 2:

  • Весь процесс репликации MySQL выше можно обобщить одним предложением, а именно: прочитать данные в журнале Bin главного сервера с сервера и синхронизировать их с собственной базой данных.

  • То же самое относится и к нашему решению 2, которое заключается в концептуальном изменении главного сервера на MySQL и подчиненного сервера на Redis (как показано на рисунке ниже).Когда данные записываются в MySQL, мы анализируем журнал Bin MySQL, а затем пишем Проанализированные данные записываются в Redis для достижения синхронизации.

• Например, ниже приведен анализ экземпляра облачной базы данных:

  • Облачная база данных и локальная база данных имеют отношение ведущий-подчиненный. В качестве основной базы данных облачная база данных в основном обеспечивает запись, а локальная база данных служит подчиненной базой данных для чтения данных из основной базы данных.

  • После того, как локальная база данных считывает данные, анализирует журнал Bin, затем синхронно записывает и записывает данные в Redis, а затем клиент считывает данные из Redis.

• Сложность этого технического решения заключается в том, как анализировать бинарный журнал MySQL. Однако это требует очень глубокого понимания файлов binlog и MySQL.В то же время, поскольку binlog имеет различные формы Statement/Row/Mixedlevel, рабочая нагрузка анализа binlog для достижения синхронизации очень велика.

Технология с открытым исходным кодом канала

• canal — это проект с открытым исходным кодом Alibaba, разработанный на чистой Java. На основе анализа добавочного журнала базы данных он обеспечивает подписку и потребление добавочных данных.В настоящее время он в основном поддерживает MySQL (также поддерживает mariaDB)

• Ссылочные адреса с открытым исходным кодом:GitHub.com/лю Келин/rub…

• Как это работает (имитация репликации MySQL):

  • canal имитирует протокол взаимодействия подчиненного сервера mysql, притворяется подчиненным сервером mysql и отправляет протокол дампа мастеру mysql.

  • Мастер mysql получает запрос на дамп и начинает передавать двоичный журнал подчиненному (то есть каналу)

  • канал анализирует двоичный объект журнала (оригинал - поток байтов)

• Архитектура:

  • server представляет запущенный экземпляр канала, соответствующий jvm

  • экземпляр соответствует очереди данных (1 сервер соответствует 1..n экземплярам)

  • модуль экземпляра:

    eventParser (数据源接入，模拟slave协议和master进行交互，协议解析)
    
    eventSink (Parser和Store链接器，进行数据过滤，加工，分发的工作)
    
    eventStore (数据存储)
    
    metaManager (增量订阅&消费信息管理器)
    

• Общий процесс анализа выглядит следующим образом:

  • parse анализирует журнал Bin MySQL, а затем помещает данные в приемник

  • Sink фильтрует, обрабатывает и распределяет данные

  • Хранилище считывает проанализированные данные из приемника и сохраняет их.

  • Затем используйте код дизайна для синхронизации данных в Store с Redis.

  • Среди них parse/sink инкапсулируется фреймворком, и то, что мы делаем, — это шаг чтения данных хранилища.

• Узнать больше о Cancl можно на Baidu.
• Ниже приведена рабочая топология

• Синхронизация таблиц MySQL использует режим цепочки ответственности, и каждая таблица соответствует фильтру. Например, дизайн класса, используемый в zvsync, выглядит следующим образом:

• Ниже приведены классы, используемые в конкретном zvsync.Каждый раз, когда таблица добавляется или удаляется, ее можно добавить или удалить напрямую.

3. Дополнительные

• Все вышеперечисленное в этой статье — это синхронизация из MySQL в кеш. Но в реальной разработке некоторые люди могут использовать следующую схему:

  • После того, как у клиента есть данные, он сначала сохраняет их в Redis, а затем синхронизирует с MySQL.

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