Лидер считывает соответствующий Log согласно Offset.

3. Лидер возвращает соответствующие данные.

Из-за ограничений Kafka Client, при использовании Kafka Client потребитель может потреблять данные только от Лидера. Если в будущем будет предоставлен VDL Client, это ограничение не будет действовать.

5. Детальное проектирование

5.1. Компонентное проектирование

5.1.1. Клиент

5.1.1.1 Поддержка Kafka протокола

VDL поддерживает часть протокола Kafka версии 0.10, что позволяет использовать оригинальный клиент Kafka или новый клиент VMS. Поддерживаемые протоколы:

5.1.1.2 Производитель

В Kafka используется основанный на TCP двоичный протокол, Produce является типичным примером Request/Response. В протоколе Produce запроса можно включить один или несколько Log. Таким образом, принцип работы Produce может быть следующим (реализация разных клиентов Kafka может отличаться):

1. Однократная отправка: один запрос отправляет один Log.
2. Пакетная отправка: один запрос запрашивает отправку нескольких Log, VDL не гарантирует атомарность нескольких Log в одном запросе.
3. Синхронная отправка: клиент реализует функцию синхронной отправки.
4. Асинхронная отправка: однократная или пакетная асинхронная отправка. VDL должен гарантировать последовательность Log в одном TCP-соединении.

Для ответа Produce определены следующие условия:

1. Успех: если это однократная отправка, то эта отправка успешна. Если это пакетная отправка, все успешно.
2. Неудача: если это однократная отправка, эта отправка неудачна. Если это пакетная отправка, всё неудачно. Как только VDL Server возвращает ошибку, последующие запросы этого TCP-соединения будут ошибочными, и клиенту необходимо повторно подключиться.
3. Тайм-аут: тайм-аут логики клиента, означающий, что ответ не получен в течение указанного времени. a) Тайм-аут не гарантирует успеха или неудачи соответствующей операции запроса, для пакетной отправки не гарантируется атомарность, возможно частичное успешное выполнение или частичная неудача (например, часть Log синхронизирована с Follower после сбоя Leader), или все успешно или неудачно. b) При возникновении тайм-аута клиенту не нужно повторно подключаться.

5.1.1.3 Потребитель

Kafka 0.10 позволяет хранить смещения потребления на брокере, но на данный момент VDL не поддерживает эту функцию. Потребителю необходимо самостоятельно сохранять смещения.

Поток журналов VDL можно рассматривать как тему Kafka с одним разделом, Kafka назначит раздел группе потребителей, но поток журналов VDL имеет только один раздел, поэтому одновременно может потребляться только одним экземпляром потребителя в одной группе потребителей.

5.1.2 Набор реплик VDL

Как описано в разделе «Архитектура», набор реплик VDL состоит из группы серверов VDL (процессов), которые используются для хранения одинаковых данных журнала. Сервер VDL в основном состоит из модуля RPC Interface, модуля обработчика потока журналов и модуля согласованности (Raft). Как показано на рисунке ниже:

5.2. Ключевые моменты проектирования Raft

5.2.1 Дизайн хранилища

5.2.1.1 Дизайн хранения

Журнал Raft

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

Журнал Raft состоит из нескольких сегментов фиксированного размера, что упрощает удаление данных журнала. Каждый сегмент состоит из нескольких журналов, каждый журнал состоит из информации Raft и данных Log.

1. Информация Raft: включает тип журнала и информацию Raft, такую как срок действия и индекс.

2. Данные Log: в зависимости от типа журнала хранятся данные журнала Raft или данные журнала, отправленные клиентом.

Сервер VDL кэширует часть самого последнего журнала Raft в памяти, чтобы потребитель мог быстро выполнять Tailing Read и избегать операций ввода-вывода на диске.

Индекс Raft

Файл, используемый для хранения индекса журнала Raft. В алгоритме Raft необходимо использовать индекс для определения местоположения журнала Raft. Индекс Raft также состоит из нескольких сегментов индекса фиксированного размера, каждый сегмент состоит из нескольких Idx. Idx имеет два важных поля: File Position, указывающее на файл сегмента журнала Raft, и Inner File Position, указывающий на смещение в файле сегмента.

Каждый сегмент имеет фиксированный размер, предположим, M байт, Idx также имеет фиксированную длину, предположим, N байт, если вы хотите определить индекс X журнала Raft Log, используйте X * N / M, чтобы получить конкретный сегмент, предположим, Y, затем используйте (X * N – M * Y) / N, чтобы получить позицию индекса в сегменте.

Индекс Raft не записывается на диск в режиме реального времени, сервер VDL поддерживает часть самого последнего индекса данных в памяти и записывает его на диск, когда размер данных превышает N раз PageSize.

Индекс журнала

Индекс данных журнала, отправляемых клиентом. В отличие от индекса Raft, индекс журнала индексирует только данные журнала клиента и не индексирует журналы, созданные алгоритмом Raft.