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

1. Давайте подумаем об этом

1.1 Является ли смещение потребительской очереди непрерывным? Почему?

1.2 Является ли смещение журнала фиксации непрерывным? Почему?

1.3 Файлы, написанные на Java, по умолчанию имеют прямой или обратный порядок байтов. Почему?

2. Реальное распространение журнала фиксации

Пока все об этом думают, давайте вспомним, как раздается лог коммитов?

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

Распределение хранилища файлов реальных данных брокера

Как видите, существует несколько реальных файлов хранения, каждый из которых имеет строку, похожую на цифры в качестве имени файла, и имеет размер 1 ГБ.

Объединив исходный код, мы можем узнать, что фактическая абстрактная модель выглядит следующим образом:

Абстракция распределения файлов хранилища журнала фиксации

Из картинки выше мы знаем:

• Журнал фиксации — это имя типа файла. На самом деле существует множество файлов журнала фиксации, каждый из которых можно назвать файлом журнала фиксации. Как показано на рисунке, всего существует файлов журнала T Commit, и они упорядочены по времени создания от прошлого к настоящему.

• Каждый файл журнала фиксации сохраняет сообщения в том порядке, в котором они были записаны, всегда записывается файл с наибольшим временем создания, и одновременно может писать только один поток. Как показано на рисунке, первый файл 1, 2, 3, 4... указывает количество сообщений в этом файле. Вы можете видеть, что 1234-е сообщение является последним сообщением первого файла журнала фиксации, а 1235-е. message Это первое сообщение второго журнала фиксации.

Примечание 1: Каждый коммит LogОбъем дискового пространства, фактически занимаемый всеми сообщениями в файле.<=1G。Давайте подумаем о причинах этой проблемы для себя.。

Примечание 2. Каждый раз пишите Commit. Когда журнал, RocketMQ заблокируется, см. фрагмент кода https://github.com/apache/rocketmq/blob/7676cd9366a3297925deabcf27bb590e34648645/store/src/main/java/org/apache/rocketmq/store/CommitLog.java#L676-L722

добавить блокировку

Видим, что в файле Commit Log много сообщений, которые хранятся по установленному протоколу. Как узнать?

3. Протокол хранения журнала фиксации

По поводу протокола хранения Commit Log мы спросили ChatGPT, и вот что мне ответили. Хоть это и не правильно, но формат ответа и описание очень близки к ответу.

Ответ в чатGPT

Давайте посмотрим на исходный код,Объясните подробно：https://github.com/apache/rocketmq/blob/rocketmq-all-4.9.3/store/src/main/java/org/apache/rocketmq/store/CommitLog.java#L1547-L1587

Commit Протокол хранения журнала

После того, как я разобрался, это выглядит так, как показано ниже;

Я понимаюCommit Протокол хранения журнала

Примечание 1: Номер протокола сообщений, который я составил, не соответствует коду. Код указывает только порядок. Протокол хранения в реальном физическом файле будет более подробным.

Примечание 2. В статье «Промежуточное программное обеспечение распределенных сообщений RocketMQ: основные принципы и лучшие практики», которую я написал, на этом изображении отсутствует содержимое Body, которое добавляется сюда, а другие данные дополняются более подробно.

Здесь есть несколько вопросов, требующих разъяснения:

1. Бинарный протокол имеет порядок байтов, который часто называют прямым порядком байтов и прямым порядком байтов. Я не буду здесь подробно останавливаться на больших и малых вопросах. Заинтересованные студенты могут зайти в Google или задать вопросы в ChatGPT. Ответ определенно будет лучше, чем я сказал.
2. В Java байт занимает 1 байт, int — 4 байта, short — 2 байта, а long — 8 байт.
3. Кодирование Host заключается не просто в преобразовании IP:Port в виде строки непосредственно в массив байтов, а в последовательном кодировании каждого числа как байта. Это будет объяснено в следующем разделе кода Golang.
4. При кодировании расширенной информации невидимые символы используются в качестве разделителей, поэтому ключ-значение расширенного поля не может содержать эти два невидимых символа. Какие именно двое? Можете ли вы их поискать?

После того, как мы увидим это соглашение, как мы можем доказать, что ваши физические документы составлены в соответствии с этим соглашением?

4. Используйте Golang, чтобы разблокировать журнал коммитов RocketMQ.

RocketMQ написан на Java. Согласно протоколу хранения, описанному выше, я написал инструмент на Golang для разблокировки Commit. Журнал и потребитель Queue,кодовый адрес：https://github.com/rmq-plus-plus/rocketmq-decoder。

В настоящее время этот инструмент поддерживает 2 функции:

1. Укажите расположение журнала фиксации, проанализируйте сообщение непосредственно в журнале фиксации и распечатайте его.
2. Укажите местоположение потребления, сначала проанализируйте очередь потребителей и получите смещение журнала фиксации, затем непосредственно проанализируйте журнал фиксации на основе смещения журнала фиксации и распечатайте его.

В Golang нет кода, основанного на RocketMQ, он опирается исключительно на декодирование протокола.

golang-import

Вот пример анализа смещения журнала фиксации в golang: В Java это смещение имеет длинный тип и занимает 8 байт.

В golang, прочитав 8-байтовые данные и декодировав их в int64 в обратном порядке, вы можете получить обычное смещение журнала фиксации.

Golang-demo

Для справки я запустил демонстрационный результат:

Чтение журнала фиксации потребительской очереди

5. Ответьте на исходный вопрос

Ниже мое личное мнение для справки:

1.1 Является ли смещение потребительской очереди непрерывным? Почему?

является непрерывным.

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

Каждое индексное сообщение занимает одно и то же пространство, составляющее 20 байт. Структура следующая:

Структура сообщения индекса потребительской очереди

Физическое местоположение здесь — Commit Log Offset.

1.2 Является ли смещение журнала фиксации непрерывным? Почему?

Не постоянно.

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

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

И есть недоразумение в «абстракции распределения файлов журнала фиксации» на рисунке выше. Размер каждого маленького квадрата на самом деле различен.

1.3 Файлы, написанные на Java, по умолчанию имеют прямой или обратный порядок байтов. Почему?

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

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

Я понимаю, что вышеизложенное есть. Если у вас есть какие-либо вопросы, добавьте меня в чат в WeChat.

QR-код WeChat

Примечание для обсуждения: из-за RocketMQ некоторые версии могут иметь различия.,Данная статья обсуждается в разделе 4.9.3версия,Вы можете обратиться к этому методу,Развязать5.0или даже другоеверсиякнига,Формат протокола хранения для других файлов данных.