Недавно я изучал очереди сообщений, файловые системы, базы данных и т. д. и постепенно обнаружил, что все они имеют основной компонент: журналы, иногда также называемые журналами упреждающей записи, журналами фиксации или журналами транзакций, обычно относящиеся к применению всех модификации Перед записью в журнал в него обычно записывается журнал повторов и журнал отмен. Мы часто слышим много терминов: база данных NoSQL, хранилище KV, Hadoop, raft, paxos и контроль версий и т. д. Эти промежуточное ПО или протоколы более или менее зависят от журналов по своей природе, и можно обнаружить, что журналы всегда находятся в распределенных системах. играют очень важную роль.

Что такое журнал?

Журнал представляет собой полностью упорядоченную последовательность записей, добавленных в хронологическом порядке.Это на самом деле специальный формат файла.Файл представляет собой массив байтов, а журнал здесь представляет собой данные записи, но по сравнению с файлом каждая запись здесь расположены в относительном порядке времени.Можно сказать, что журнал представляет собой простейшую модель хранения.Чтение, как правило, слева направо.Например, очередь сообщений обычно записывается в файл журнала линейно.Начинается порядок потребителей со смещения.читай.
Из-за присущих самому журналу характеристик записи вставляются последовательно слева направо, что означает, что записи слева «старше», чем записи справа, а значит, нам не нужно полагаться на систему часы система очень важна.

приложение журнала

Применение входа в базу данных

Невозможно узнать, когда появился журнал, и он может быть концептуально слишком простым. В области базы данных журналы больше используются для синхронизации данных и индексов при сбое системы, например, журнал повторов в MySQL, журнал повторов — это дисковая структура данных, используемая для обеспечения данных при сбое системы. Правильность и полнота журнала также называется журналом упреждающей записи.Например, во время выполнения чего-либо сначала будет записан журнал повторов, а затем будут применены фактические изменения, чтобы при восстановлении системы после сбоя ее можно было восстановить по журналу повторов.Поставил для восстановления данных(в процессе инициализации в это время не будет подключения клиента). Лог также можно использовать для синхронизации между мастером и слейвом БД, т.к. по сути все записи операций БД записаны в лог.Нам нужно только синхронизировать лог на слейве и воспроизвести его в слейве для достижения синхронизации ведущий-ведомый.Многие другие необходимые компоненты также могут быть реализованы здесь, мы можем подписаться на повтор log, чтобы получить все изменения в базе данных, чтобы реализовать персонализированную бизнес-логику, такую как аудит, синхронизация кэша и т. д.

Применение журнала в распределенной системе

Распределенные системные службы в основном связаны с изменениями состояния, которые здесь можно понимать как конечные автоматы Два независимых процесса (не зависящих от внешней среды, таких как системные часы, внешние интерфейсы и т. д.) будут производить согласованные выходные данные при согласованных входных данных И, наконец, поддерживать согласованное состояние, а журнал не зависит от системных часов из-за присущего ему порядка, что можно использовать для решения проблемы порядка изменения.
Мы используем эту функцию для решения многих проблем, возникающих в распределенных системах. Например, резервный узел в RocketMQ, главный брокер получает запрос клиента, записывает журнал, а затем синхронизирует его с подчиненным в режиме реального времени. Ведомый воспроизводит его локально. Когда мастер отключается, подчиненный может продолжать обработку запрос, например отклонение запроса на запись и продолжение обработки запросов на чтение. Журнал может не только записывать данные, но и напрямую записывать операции, такие как операторы SQL.

Журнал является ключевой структурой данных для решения проблемы согласованности. Журнал подобен последовательности операций. Каждая запись представляет собой инструкцию. Например, широко используемые протоколы Paxos и Raft представляют собой протоколы согласованности, построенные на основе журналов.

Применение входа в очередь сообщений

Журналы можно легко использовать для обработки притока и оттока данных.Каждый источник данных может генерировать свой собственный журнал, где источник данных может поступать из различных аспектов, таких как поток событий (клики по страницам, напоминания об обновлении кеша, изменения в бинлоге базы данных). ), мы можем централизованно хранить логи в кластере, подписчики могут читать каждую запись журнала по смещению и применять свои изменения по данным и операциям в каждой записи.
Лог здесь можно понимать как очередь сообщений, которая может играть роль асинхронной развязки и ограничения тока. Почему вы говорите о развязке? Потому что для потребителей и производителей обязанности двух ролей предельно ясны: они несут ответственность за создание и потребление сообщений, не заботясь о том, кто нижестоящий и восходящий поток, будь то журнал изменений из базы данных или событие. Мне вообще не нужно заботиться об одной стороне, мне просто нужно обратить внимание на журнал, который меня интересует, и на каждую запись в журнале.

Мы знаем, что количество запросов в секунду для базы данных определено, и приложения верхнего уровня, как правило, можно масштабировать по горизонтали.В настоящее время, если двойное 11 является сценарием внезапного запроса, база данных будет перегружена, тогда мы можем ввести очередь сообщений и писать операции каждой командной БД.В логе другое приложение отвечает за потребление этих записей лога и применение их к БД, и даже если БД зависнет, оно может продолжить обработку с позиции последнего сообщения при восстановлении (RocketMQ и Kafka поддерживают семантику Exactly Once) , даже если скорость производителя отличается от скорости потребителя, это не повлияет на журнал здесь. Журнал действует здесь как буфер. Он может хранить все записи в журнал и регулярно синхронизируйтесь с подчиненным узлом, так что отставание сообщений Возможность может быть значительно улучшена, потому что журнал записи обрабатывается главным узлом.Существует два типа запросов на чтение.Один из них - хвостовое чтение, что означает, что скорость потребления может идти в ногу со скоростью записи.Этот вид чтения может напрямую идти в кеш, а другой - потребитель, который отстает от запроса на запись.Это может быть прочитано с ведомого узла, так что через изоляцию ввода-вывода и некоторые файловые стратегии, поставляемые с операционной системой, такие как кэш страниц, упреждающее чтение кеша и т. д., могут значительно улучшить производительность.

Горизонтальная масштабируемость — очень важная особенность распределенных систем, и проблемы, которые можно решить путем добавления машин, не являются проблемами. Итак, как реализовать очередь сообщений, которая может достичь горизонтального расширения?У нас есть очередь сообщений на одной машине.По мере увеличения количества тем IO, CPU, пропускная способность и т. д. постепенно становятся узкими местами, а производительность будет постепенно снижаться, так как продолжить здесь Как насчет оптимизации производительности?

Разделение темы/журнала, по сути, сообщения, написанные темой, являются записями журнала, поэтому по мере увеличения количества записей одна возможность постепенно становится узким местом.В настоящее время мы можем разделить одну тему на несколько подтем. , и Назначить каждую тему отдельному компьютеру. Таким образом, темы с большим количеством сообщений могут быть решены путем добавления компьютеров, а некоторые сообщения с небольшим количеством сообщений могут быть назначены на один и тот же компьютер или не разделены
Групповая фиксация, такая как клиент-производитель Kafka, при написании сообщения сначала записывает в локальную очередь памяти, а затем агрегирует сообщения в соответствии с каждым разделом и узлом и отправляет их пакетами. Также можно использовать кэш страниц Таким образом, сначала записывается кэш страниц, а затем периодически обновляется диск.Метод обновления диска может определяться в зависимости от бизнеса.Например, финансовый бизнес может принять метод синхронного обновления диск.
Избегайте бесполезных копий данных
Изоляция ввода-вывода

Эпилог

Журналы играют важную роль в распределенных системах и являются ключом к пониманию каждого компонента распределенных систем.По мере углубления понимания мы обнаружили, что многие распределенные промежуточные программы построены на основе логов, такие как Zookeeper, HDFS, Kafka, RocketMQ, Google Spanner и т. д., и даже базы данных, такие как Redis, MySQL и т. д., их master-slave основаны на синхронизации журналов, опираясь на общую систему журналов, мы можем реализовать множество систем: синхронизация данных между узлами, параллельные обновления Проблема последовательности данных (проблема непротиворечивости), настойчивость (система может продолжать предоставлять услуги через другие узлы при сбое системы), служба распределенной блокировки и т. д. Я считаю, что после медленного прохождения практики и прочтения большого количества статей будет более глубокий уровень понимание.