Знакомство с артефактом синхронизации данных в реальном времени — Canal~

источник:Облачное сообщество Hang Seng LIGHT

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

Введение в канал

CanalЭто платформа с открытым исходным кодом, основанная на Ali.Mysqlбаза данныхbinlogИнкрементная подписка и компонент потребленияbinloglog, а затем выполнять некоторое потребление данных, например зеркальное отображение данных, неоднородность данных, индексирование данных, обновление кэша и т. д. По сравнению с очередями сообщений с помощью этого механизма можно добиться упорядочения и согласованности данных.

дизайн фона

В первые дни компания Alibaba B2B имела бизнес-требования для синхронизации компьютерных залов из-за развертывания двухкомпьютерных залов в Ханчжоу и США. Однако ранний бизнес по синхронизации баз данных в основном основывался на методе триггера для получения добавочных изменений, однако с 2010 года компании, базирующиеся на Alibaba, начали постепенно пытаться анализировать журналы на основе базы данных, чтобы получать добавочные изменения для синхронизации. с тех пор массовая подписка и потребление открыли новую эру.

Используемая в настоящее время внутренняя синхронизация уже поддерживает синтаксический анализ журналов некоторых версий mysql5.x и oracle.

Службы, поддерживаемые инкрементальной подпиской и потреблением журналов:

1. Зеркальное отображение базы данных
2. Резервное копирование базы данных в режиме реального времени
3. Многоуровневый индекс (у продавцов и покупателей есть собственный индекс подбазы данных)
4. search build
5. Обновление бизнес-кэша
6. Важные деловые новости, такие как изменение цен

Принцип работы

Реализация активной и резервной репликации MySQL

С верхнего уровня репликация делится на три шага:

1. masterЛог изменений в бинарный лог (binary log) (эти записи называются событиями бинарного журнала,binary log events, в состоянии пройтиshow binlog eventsсмотреть);
2. slaveбудетmasterизbinary log eventsскопировать в свой журнал ретрансляции (relay log);
3. slaveПовторное выполнение события в журнале реле изменит данные, чтобы отразить его собственное.

Как работает канал

Принцип относительно прост:

1. canalмоделированиеmysql slaveпротокол взаимодействия, маскирующийся подmysql slave,В направленииmysql masterОтправитьdumpпротокол
2. mysql masterПолучатьdumpзапросить, начать толкатьbinary logдаватьslave(это,canal)
3. canalРазобратьbinary logобъект (исходный поток байтов)

базовая архитектура

инструкция:

• serverпредставляетcanalзапущенный экземпляр, соответствующийjvm
• instanceсоответствует очереди данных (1serverСоответствует 1..ninstance)

instanceМодуль:

• eventParser(Доступ к источнику данных, моделирование взаимодействия между подчиненным протоколом и ведущим, анализ протокола)
• eventSink(Компоновщик Parser и Store для фильтрации, обработки и распространения данных)
• eventStore(хранилище данных)
• metaManager(Диспетчер дополнительной информации о подписке и потреблении)

Дизайн парсера событий

весьparserПроцесс условно можно разделить на несколько этапов:

1. ConnectionПолучить местоположение, в котором был выполнен последний синтаксический анализ (если он запускается в первый раз, получить начальное указанное местоположение или текущую базу данныхbinlogсайт)
2. Connectionсоздать ссылку, отправитьBINLOG_DUMPинструкция // 0. записать номер команды // 1. записываем 4-байтовую позицию bin-log для начала // 2. записать 2 байта флагов bin-log // 3. записываем 4 байта id сервера слейва // 4. записать имя файла bin-log
3. Mysqlначать толчокBinaly Log
4. получилаBinaly LogпрохождениеBinlog parserВыполните анализ протокола и добавьте определенную информацию // Имя дополнительного поля, тип поля, информация о первичном ключе, обработка беззнакового типа
5. Перейти кEventSinkМодуль выполняет хранение данных, что является блокирующей операцией до тех пор, пока сохранение не будет успешным.
6. После успешного хранения регулярно записывайтеBinaly LogМесто расположения

Дизайн EventSink

инструкция:

• Фильтрация данных: поддержка режима фильтрации подстановочных знаков, имени таблицы, содержимого поля и т. д.
• Маршрутизация/распределение данных: решить 1:n (1parserсоответствовать несколькимstoreРежим)
• Объединение данных: решить n:1 (несколькоparserсоответствует 1store)
• Обработка данных: при вводеstoreПеред выполнением дополнительной обработки, такой какjoin

Дизайн магазина событий

• 1. В настоящее время реализовано толькоMemoryРежим памяти, последующие планы по увеличению местныхfileместо хранения,mixedрежим смешивания
• 2. Узнал отDisruptorизRingBufferидея реализации

RingBufferдизайн:

3 курсора определены

• Put : последняя позиция записи модуля приемника для хранения данных.
• Get : последняя позиция выборки, полученная подпиской на данные.
• Ack : последняя позиция потребления, где потребление данных было успешным.

Дизайн экземпляра

instanceПредставляет фактическую работающую очередь данных, включаяEventPaser,EventSink,EventStoreи другие компоненты.

абстрагированныйCanalInstanceGenerator, в основном с учетом того, как осуществляется управление конфигурацией:

• managerКак: интегрировать с собственной внутренней веб-консолью/системой управления. (В настоящее время в основном используется внутри компании)
• springМетод: определить на основе свойств Spring XML + для создания конфигурации Spring.

Дизайн сервера

serverПредставляет работающий экземпляр канала. Чтобы облегчить использование компонентов, он специально абстрагирован.Embeded(встроенный) /NettyДве реализации (доступ к сети)

• Embeded: правильноlatencyи доступность имеют относительно высокие требования и могут содержать распределенные связанные технологии (такие какfailover)
• Netty: на основеnettyОн инкапсулирует уровень сетевого протокола, который состоит изcanal serverКонечно, чтобы обеспечить его доступность, использовалась модель вытягивания.latencyБудет небольшая скидка, но это тоже зависит от ситуации. (Алиnotifyиmetaq, типичныйpush/pullМодель также постепенно движется в сторонуpullмодель рядом,pushБудут некоторые проблемы, когда объем данных большой)

механизм ГК

canalизhaделится на две части,canal serverиcanal clientИмеются соответствующие реализации ha соответственно

• canal server: уменьшитьmysql dumpзапрос, разныеserverВверхinstanceТребуется, чтобы только один изrunning, остальные находятся в режиме ожидания.
• canal client: Для обеспечения порядкаinstanceТолько по одномуcanal clientпровестиget/ack/rollbackоперации, в противном случае прием клиента не может быть гарантированно в порядке.

Управление всем механизмом HA в основном зависит отzookeeperнесколько характеристикwatcherиEPHEMERALузел (иsessionпривязка жизненного цикла).

Canal Server:

Грубые шаги:

1. canal serverначатьcanal instanceвсегда впередzookeeperСделайте попытку начать суждение (реализация: создайте EPHEMERAL node, кто бы ни был успешно создан, ему будет разрешено начать)
2. СоздайтеzookeeperПосле успешного завершения узла соответствующийcanal serverзапустить соответствующийcanal instance, не удалось создатьcanal instanceбудет в режиме ожидания
3. однаждыzookeeperНаходитьcanal server AУведомлять других сразу после исчезновения созданного узлаcanal serverВыполните операцию шага 1 еще раз и выберите новыйcanal serverзапускатьinstance.
4. canal clientКаждый раз, когда выполняется соединение, оно сначала отправляетzookeeperСпросите, кто сейчас активированcanal instance, а затем установить с ним связь. Как только ссылка будет недоступна, он попытается снова подключиться.

Метод клиента канала иcanal serverАналогичным образом, также используяzookeeperСпособ вытеснения узла EPHEMERAL контролируется.

Сценарии применения

синхронизация данных

• В среде разработки микросервисов для повышения эффективности поиска и точности поиска он будет широко использоваться.Redis,MongodbЖдатьNoSQLбаза данных, которая также использует многоSolr,Elasticsearchи другие сервисы полнотекстового поиска. Затем, в это время, возникнет проблема, о которой нам нужно подумать и решить: это проблема синхронизации данных!
• Canal может синхронизировать данные в изменяющейся в реальном времени базе данных, чтобыRedis,MongodbилиSolr/Elasticsearchсередина.

неоднородность данных

В крупномасштабной архитектуре веб-сайта БД будет использовать подбазу данных и подтаблицу для решения проблем с емкостью и производительностью, но новые проблемы, вызванные подбазой данных и подтаблицей. Например, запросы различных измерений или запросы агрегации в настоящее время будут очень сложными. Как правило, мы решим эту проблему с помощью механизма неоднородности данных.Неоднородность данных заключается в объединении нескольких таблиц, которые необходимо объединить и запросить в БД в соответствии с определенным измерением. Позвольте вам поинтересоваться. Канал является одним из средств реализации неоднородности данных.