Shulou(Shulou.com)06/01 Report--

This article mainly explains "how to achieve Journal in Apache Bookkeeper". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "how to achieve Journal in Apache Bookkeeper".

Main function

Act as WAL

Write request processing:

First of all, after the Bookkeeper server receives the request to write Entry, it will hand it over to Bookie for processing.

The Bookie.addEntryInternal method writes the Entry information carried by the request to LedgerStorage (the location of the actual data store + index).

After a successful write, the request is also written to Journal.

Other important information: for example, information about Ledger being fence, LAC, etc.

When starting, replay the WAL and re-apply the contents recorded in the journal to the LedgerStorage.

Avoid the loss of content previously written to LedgerStorage because it is not brushed.

Checkpoint logic

Like other WAL, you need to record a location that indicates that all the data in the LedgerStorage has been unloaded.

All WAL logs before this location can be deleted.

Maintain JournalChannel logic, write WAL logs, log rotation, etc.

General logic 1. Write:

The whole write is asynchronous, and the result of the write is subsequently processed by callback.

The written parameters are encapsulated into a QueueEntry and placed in the write request queue.

Class QueueEntry {/ / content ByteBuf entry; long ledgerId; long entryId; / / the time when the callback WriteCallback cb; of the write result enters the queue, which is used to determine whether the waiting time is too long long enqueueTime; / / whether the content needs to be boolean ackBeforeSync;}

This queue will be processed periodically by a thread. Call it BookieJournalWriteThread first (there is no such class).

After taking it out, the carried ByteBuffer will be written to the JournalChannel. This thread deals specifically with this logic.

I won't do the rest of the work.

Let's start with the JournalChannel class, which can be thought of as the mapping of the underlying journal disk files.

The internal implementation is a FileChannel with read and write cache, which goes to write cache first when writing

The corresponding logic actively triggers the write cache to write to the packaged FileChannel.

After the bytes of QueueEntry are written, the contents may be in the write cache.

Flush logic

We need to trigger the flush logic to write the contents of the write cache to the FileChannel.

Flush and sync to disk are not the same here.

Flush is to call FileChannel.write to reduce the number of calls.

Sync is calling FileChannel.force to fsync to disk

There are three conditions for triggering flush:

Time bound: after this request is enlisted, it must be processed after a period of time (written to channel or off disk)

Number of write requests | | cumulative number of bytes of write requests

The write request team is empty (this usually occurs during the test, but when there are few write requests, most of them will be covered by the condition of 1)

If the flush condition is met, the content of the write cache will be actively brushed into the FileChannel.

If you do not need to wait for the content to be dropped (ackBeforeSync=false), then submit the callback directly to the thread pool for callback.

The write request is then placed in a batch waiting for flush.

After the flush logic is done, it will determine whether it needs to be closed.

ForceWrite logic

According to the configuration, there are several conditions that need to be closed.

Every time flush needs to be closed.

Journal file rotation, you need to put the previous files on the disk.

Set down the disk according to the configured interval.

If the disk needs to be removed, the previous batch will be encapsulated into a ForceWriteRequest and placed in the disk queue at this time.

This queue will be emptied by ForceWriteThread.

Here you can configure the logic of a groupCommit. Avoid multiple fsync.

If this is configured, the requests in the queue will be merged, triggering a single FileChannel.force.

Similarly, after the disk is dropped, the previous callback is put into the thread pool to handle the callback.

2. Replay logic

This logic is relatively simple, which is to start reading the contents of this file from the location of the last successful checkpoint.

Write what you read into LedgerStorage again and ok it.

3. Checkpoint logic

This is actually linked to the LedgerStorage. If the content above the WAL has been successfully written to disk by LedgerStorage, then the WAL can be deleted.

There will be a LastLogMark file marked (journal file, offset) to indicate that the contents of the file before the offset can be wiped out.

The class Journal implements the interface CheckpointSource.

The actual action is performed by SyncThread (which implements the Checkpointer interface).

The checkpoint trigger conditions for each LedgerStorage are different.

EntryLogPerLedgerEnabled | | isDbLedgerStorage triggers checkpoint periodically according to time interval

InterleavedLedgerStorage will trigger when the log is rotated

SortedLedgerStorage will trigger when memtable needs flush

The actual logic is relatively simple.

Public void checkpoint (Checkpoint checkpoint) {/ /... LedgerStorage.checkpoint (checkpoint); checkpointSource.checkpointComplete (checkpoint, true); / /...}

The checkpointComplete method will refresh the LastLogMarker file on the disk and drop the disk at the same time.

(the main logic is here in LedgerStorage.checkpoint)

The disk here is LedgerStorage's disk.

Write request processing is asynchronous and is processed by the Journal thread after it is submitted.

The Journal thread is responsible for writing content to the Journal channel and executing flush logic according to certain conditions.

If it is determined that the flushing disk needs to be done, the batch will be packed as ForceWriteRequest.

ForceWriteThread cleans up the queue for group commit processing. Responsible for journal listing.

The callback for write requests will not be executed in either of these two and will be submitted to the callback thread pool for processing.

Thank you for your reading, the above is the content of "how to achieve Journal in Apache Bookkeeper". After the study of this article, I believe you have a deeper understanding of how to achieve Journal in Apache Bookkeeper, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.