задний план

Я не знаю, беспокоят ли вас все еще следующие проблемы:

• Когда вы используете Redis или другое ПО промежуточного слоя для кэширования, вы часто обнаруживаете, что данные в кеше и базе данных несовместимы, и вы можете сделать некоторые ограничения только через временные задачи или истечение срока действия кеша.
• Когда вы используете ES в качестве инструмента поиска и используете метод двойной записи, вы все равно беспокоитесь о том, что ES и база данных не являются транзакцией.
• Когда вам нужно мигрировать данные, вы все еще используете метод двойного записи. Если это та же база данных, это нормально. Если это другая база данных, транзакция не может быть гарантирована, то согласованность данных также является проблемой, и Многие ремонтные задания будут написаны. И проверить работу.

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

Давайте задумаемся, в чем суть этой проблемы? Необходимо убедиться, что наши данные согласуются с нашим mysql, будь то в redis или es, что по сути является репликацией данных. Размышляя о репликации данных, друзья, знакомые с Mysql, скажут: Разве мастер и резервная копия Mysql не являются репликацией данных? Если мы имитируем первичную и вторичную репликацию Mysql, то наша синхронизация данных будет очень простой.

Мастер-ведомый Mysql

Поскольку мы можем имитировать репликацию master-slave Mysql для удовлетворения наших потребностей, нам нужно сначала понять принцип MySQL master-slave, как показано на следующем рисунке:

• Шаг 1: MySQL в качестве мастера должен последовательно записывать запись операции в файл binlog и сохранять ее на локальном диске до того, как каждая транзакция обновит данные.

• Шаг 2: Откройте поток ввода-вывода на нашем вспомогательном сервере, он будет непрерывно читать из binlog, если он будет прочитан. Если прогресс догнал мастера, засыпайте и ждите, пока мастер сгенерирует новые события. Все считанные данные записываются в журнал реле.

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

В процессе master-slave репликации самым важным является binlog, а slave-библиотека будет копировать копию данных master-библиотеки по информации binlog.

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

binlog

Бинлог (Binary Log), как следует из названия, представляет собой двоичный журнал в Mysql, в котором записываются все операции, выполняемые Mysql по изменению базы данных. Binlog также является журналом, созданным на уровне сервера, и не имеет ничего общего с нашим механизмом хранения.Независимо от того, какой механизм хранения вы используете, вы можете использовать наш binlog.

бинарный формат

В binlog есть три формата, а именно:Statement,Row, Mixedтри, черезshow variables like 'binlog_format'Чтобы просмотреть формат binlog текущей базы данных, как показано на рисунке ниже, это binlog в формате Row:

Statement

Оператор также является типом оператора, он будет записывать каждый Sql, который изменяет данные в binlog.

• Преимущества: Соотношение пробелов наименьшее, и поля, которые не были изменены, не будут записаны. По сравнению с другими режимами он уменьшает количество световых сигналов журнала и повышает производительность ввода-вывода.
• Недостатки: Гетерогенные системы неудобны в использовании, например, при копировании кэша redis сложно смоделировать работу слейва mysql, и данные нужно проверять заново. И у ведомого также будут проблемы, такие как использование некоторых функций UUID, ведомое устройство не гарантирует, что две стороны непротиворечивы при воспроизведении.

Мы можем проверить, каково содержимое журнала Statement? Здесь мы можем ввести команду:show master status;Просмотрите бинарный журнал, который использует наш текущий мастер, как показано ниже:

Затем используйте командуshow binlog events in 'mysql-bin.000003', чтобы увидеть, что в этом журнале:Мы можем обнаружить, что все наши операции будут выполняться в полной транзакции.Если транзакция не будет зафиксирована, она не появится в нашем бинлоге.Вы можете спуститься и поэкспериментировать.Наш обновленный сырой sql в базе данных будет полностью записан.

Row

Режим строки отличается от оператора, он записывает все данные после изменения каждой строки:

• Достоинства: Гетерогенные системы тоже легко синхронизируют данные, и проблем с функциями UUID не будет, и можно реплицировать несмотря ни на что.
• Недостатки: имеется много данных, таких как оператор обновления, который также записывает каждое поле до обновления и каждое поле после обновления. Объем журнала относительно велик, что оказывает определенное влияние на ввод-вывод.

Аналогично, давайте взглянем на то, что в нем:

существуетshow binlog events in 'mysql-bin.000004'В команде мы обнаружили, что в транзакции мы не можем видеть наши конкретные данные. В это время нам нужны наши инструменты, чтобы помочь MySqlbinlog. Он также вызывает непосредственно в каталоге bin MySQL, введите команду/usr/local/mysql/bin/mysqlbinlog --base64-output=decode-rows -v mysql-bin.000004, мы можем видеть:

Здесь показан оператор обновления, который отображает не только исходное значение, но и измененное значение.

Здесь следует отметить, чтоbinlog_row_imageОн используется, чтобы определить, будет ли строка записывать исходное значение.По умолчанию FULL, что означает, что она будет записана, как в нашем случае выше.Есть также параметр минимального, что означает, что записывается только обновленное значение.

Mixed

В смешанном режиме MySQL по-прежнему записывает в формате оператора по умолчанию, но как только он определяет, что может быть несогласованность данных (функция UUID), он будет записывать в формате строки.

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

Canal

Когда мы знаем, что такое бинлог, нам нужно, как использовать этот бинлог. Распространенными инструментами синхронизации бинлога являются: databus, canal, maxwell, Alibaba Cloud dts и т. д. Здесь мы не будем сравнивать их соответствующие преимущества и недостатки, а сосредоточимся на канале.

канал (адрес на гитхабе:GitHub.com/Alibaba/Misery…Инкрементный анализ журнала базы данных MySQL, обеспечивающий подписку на инкрементные данные и потребление

На заре существования Alibaba из-за развертывания двухкомпьютерных залов в Ханчжоу и США бизнес-требование требовало синхронизации между компьютерными залами Метод реализации заключался в основном в получении дополнительных изменений на основе бизнес-триггеров. С 2010 года компания постепенно пытается анализировать журнал базы данных, чтобы получить добавочные изменения для синхронизации, что привело к большому количеству добавочных подписок на базы данных и служб потребления. Позже он постепенно превратился в проект DTS в Alibaba Cloud.

общий принцип канала заключается в том, чтобы имитировать ведомый mysql, то ли вытащить binlog из мастера, то binlog может служить в разных местах, таких как наша общая очередь сообщений: kafka, RocketMQ и так далее. Конечно, Ali cloud, также платные DTS, указанные выше, могут быть напрямую синхронизированы с Redis, ES или каким-либо другим носителем данных.

Простое использование Canal позволяет просматривать QuickStart:GitHub.com/Alibaba/Misery…, Я не буду делать здесь слишком много введения. Следующее в основном предназначено для того, чтобы больше узнать об общей архитектуре канала, а также о принципе реализации и так далее.

Общая архитектура канала

CanalServer: JVM можно понимать как CanalServer.Если это Canal в режиме кластера, будет несколько CanalServer.

CanalInstance: это можно понимать как задание как экземпляр.Например, существует бинарный журнал библиотеки А, который синхронизируется с очередью сообщений А, а двоичный журнал библиотеки Б синхронизируется с очередью сообщений Б. Затем эти это два разных экземпляра.Что касается того, какой экземпляр в каком Для запуска на CanalServer нужно посмотреть, кто первым вытесняет временный узел в ZK.Если распределение достаточно равномерное, это может снять большую нагрузку в кластерном режиме.

CanalParser: используется для извлечения и анализа mysql-binlog.

Мероприятияники: обработка анализируемых данных (отфильтрованных, слияние и т. Д.).

CanalEventStore: это похоже на ретрансляционный журнал в ведомом устройстве, который используется для ретрансляционного хранения журналов, но в настоящее время поддерживает только хранение в памяти в канале и в настоящее время не поддерживает хранение на диске.

CanalParser, EventSink и CanalEventStore — очень важные компоненты в Canal, отношения между которыми следующие:

CanalParser генерирует данные для обработки EventSink.Обработанные данные будут храниться в CanalEventStore, а затем MQ будет непрерывно получать последние данные из CanalEventStore, а затем доставлять их в MQ.

CanalParser

Давайте поговорим о том, как Canal притворяется ведомым для получения данных в CanalParser.AbstractEventParser.javaЭтот класс имеет следующие шаги:

• Шаг 1: Создайте ссылку на базу данных и сгенерируйте slaveID, чтобы указать вашу собственную подчиненную личность.
• Шаг 2: получение базы метаинформации, такой как binlogFormat, binRowImage и так далее.
• Шаг 3: пройтиshow variables like 'server_id'команда, чтобы получить идентификатор сервера, который нам нужен для прослушивания службы binlog.

• Шаг 4: Получите местоположение, которое необходимо использовать на этот раз. Если оно сохранено в прошлый раз, получите его из последнего раза. Если нет, вам нужно пройтиshow master statusПоследняя позиция, полученная в команде, используется.

• STEP5: выполните операцию дампа, имитируйте раб, чтобы отправить запрос на регистрацию, и выпустите запрос на BINLOG, а затем используйте бесконечный цикл, чтобы непрерывно вытащить данные из BinLog:

• Шаг6: преобразовать полученные двоичные данные в локальную регистрацию в соответствии с протоколом BINLOG MYSQL для облегчения последующей обработки.

EventSink

EventSink обработает logEntry, полученный выше:

• фильтр:
  • фильтровать пустые транзакции
  • фильтр сердцебиения
  • пользовательский фильтр
• Records, Prometheus используется здесь для статистической отчетности данных.
• При слиянии возникает множество бизнес-потребностей в подбазе данных и подтаблице, и все их источники данных находятся в разных парсерах, но в конце концов все они должны быть объединены в одно и то же хранилище событий. На что нам нужно обратить внимание в этом сценарии, так это на то, что мы будем контролировать слияние по времени, то есть пытаться сделать данные каждой подбазы данных агрегированными и отправленными поэтапно, чтобы избежать опережения данных подбазы данных. других или много позади.

EventStore

Давайте сначала посмотрим на интерфейсы, предоставляемые в EventStore:Видно, что EventStore на самом деле представляет собой простое хранилище.MemoryEventStoreWithBuffer предоставляется в канале для передачи данных в память.Принцип реализован RingBuffer (lock-free, high-performance queue).Информацию о RingBuffer см. статьяРазрушители, о которых вы должны знать, RingBuffer подробно объясняется в 3.1.

Затем CanalMq непрерывно получает данные через EventStore для отправки данных.

резюме

На самом деле в Canal есть и другие оптимизации, такие как оптимизация после изменения структуры таблицы, некоторая оптимизация gtid и т. д. Если вам интересно, вы можете прочитать это самостоятельно, и мы не будем здесь это расширять.

Суммировать

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

Если вы считаете, что эта статья полезна для вас, то ваше внимание и пересылка - самая большая поддержка для меня, O(∩_∩)O: