предисловие
Что такое канал? Цитирую официальный ответ:
Инкрементная подписка и компонент потребления binlog базы данных Alibaba mysql
Что может канал?
Службы, поддерживаемые инкрементной подпиской и потреблением журналов:
- Зеркальное отображение базы данных
- Резервное копирование базы данных в режиме реального времени
- Многоуровневый индекс (у продавцов и покупателей есть собственный индекс подбазы данных)
- search build
- Обновление бизнес-кэша
- Важные деловые новости, такие как изменение цен
Например, в настоящее время LZ использует канал для репликации данных в реальном времени, построения данных поисковой системы и других функций. Поскольку вы хотите использовать его, проведите небольшое исследование.
Время ограничено, давайте посмотрим вместе.
Архитектура программного обеспечения
По поводу принципа работы canla не буду его распространять, если интересно, можете посмотреть официальную документацию, или вот этот ppt:docs.Google.com/present Вопрос А…
Грубо говоря, canal — это слейв, замаскированный под mysql, дамп бинлога, парсинг бинлога и передача его приложению, в общем, все довольно просто.
Итак, давайте посмотрим на структуру кода канала.
Мы видим, что сервер канала состоит из нескольких модулей, самый внешний из которых — Сервер, который принимает запрос Клиента Канала и возвращает данные Клиента. Сервер — это JVM. Каждый сервер состоит из нескольких CanalInstance, и каждый CanalInstance на самом деле является местом назначения, которое мы устанавливаем, обычно это база данных.
Каждый CanalInstance состоит из 5 модулей, а именно синтаксического анализа, фильтрации приемника, хранения хранилища, управления метаданными metaManager и аварийного сигнала.
Для чего эти 5 модулей?
Проще говоря:
При запуске Canal Server будет запущено N экземпляров CanalInstance в соответствии с конфигурацией.Каждый экземпляр CanalInstance будет использовать сокет для подключения к mysql, выгрузки binlog, а затем отправки данных в синтаксический анализатор для анализа, фильтрации приемника и хранения.При подключении клиента , он будет считывать из zk Получить информацию о клиенте, а управление метаданными metaManager заключается в управлении информацией zk (конечно, есть много реализаций, например, сохранение в файле) информации, при возникновении ошибки вызовите Alarm для отправки информация о тревоге (вы можете получить доступ к системе мониторинга вашей собственной компании), в настоящее время печатает журналы.
Процесс запуска канала
В настоящее время существует более 60 000 строк кода канала, около 17 000 строк кода после удаления 2 классов генерации ProtocolBuffer, и осталось еще 43 000 строк кода.Кода еще много.
Процесс запуска также более извилистый. Здесь я просто рисую блок-схему:
Объясните эту схему:
Сценарий канала запускается из основного метода CanalLauncher, затем вызывает метод запуска CanalController, CanalController вызывает метод запуска InstanceConfigMonitor и, наконец, вызывает метод запуска ключевого компонента канала CanalServerWithEmbedded.
Внутри Canal есть CanalServerWithEmbedded и CanalServerWithNetty, Первый не имеет порта сервера и является прокси без порта. Последний представляет собой сервер, реализованный на основе Netty, в методе channelRead будут вызываться родственные методы CanalServerWithEmbedded.
CanalServerWithEmbedded является синглтоном, и внутри будет несколько CanalInstances.У него несколько реализаций.В независимой версии используется версия CanalInstanceWithSpring, которая управляет жизненным циклом компонентов на базе Spring.
Внутри каждого CanalInstance находится 5 компонентов, то есть упомянутые выше компоненты, и они будут запускаться отдельно.
Среди них наиболее важными являются парсер, сток, хранилище.
После того, как CanalEventParser запустится, он запустит поток с именем parseThread, который продолжает зацикливаться. В основном: создайте соединение с mysql, затем запустите поток сердцебиения, а затем запустите дамп binlog.
Выгруженный бинлог выпускается через беззамковую очередь дисраптора, бинлог потребляется тремя потребителями последовательно и после обработки передается модулю-приемнику.
Затем есть раковина, которая относительно проста, поэтому я не буду о ней говорить. После того, как сток обработан, он передается в модуль хранения.
Режим хранилища представляет собой кольцевой массив, аналогичный RingBuffer, в котором хранятся данные, выгруженные из mysql, и клиент также получает данные отсюда. Массив поддерживает 3 указателя: получить, положить, подтвердить.
Самое странное здесь то, почему бы не использовать паттерн цепочки ответственности для сборки компонентов?
Поток данных канала
Прочитав процесс запуска, давайте посмотрим, как выглядит поток данных внутри канала. Я тут просто картинку нарисовал.
Автономная версия Canal использует Netty для предоставления порта и использует свой собственный SessionHandler для обработки TCP-запросов, а SessionHandler передает запрос CanalServerWithEmbedded для обработки.
Давайте посмотрим, что некоторые методы CanalServerWithEmbedded, такие как subscribe, get, ack и т. д., являются методами, соответствующими клиенту, то есть CanalServerWithEmbedded — это класс, который имеет дело с клиентом.
CanalServerWithEmbedded внутренне управляет всеми экземплярами CanalInstance, находит экземпляр CanalInstance, на который подписан клиент, с помощью информации о клиенте, а затем вызывает модуль Store внутри экземпляра CanalInstance, который является методом get RingBuffer, для получения данных RingBuffer.
С точки зрения Myslq, MysqlConnection выгружает данные из Myslq и передает их синтаксическому анализатору для синтаксического анализа.После синтаксического анализа синтаксического анализатора они передаются приемнику.После обработки приемника они сохраняются в хранилище и ждут, когда клиент придет и заберет их.
После прочтения потока данных, если у вас есть какие-либо вопросы, вы можете посмотреть код, соответствующий какому модулю, просто посмотрите на него напрямую.
Суммировать
Потребовалось некоторое время, чтобы посмотреть на код Canal, и в целом он очень хорош, но есть некоторые вопросы, например, почему парсер, приемник, хранилище не используют режим фильтрации.
Почему бы Client и CanalServerWithEmbedded не использовать RPC для взаимодействия, что проще и понятнее.
В коде слишком много методов обратного вызова, что влияет на чтение.
Но в целом читать стоит.