The basic concept

  • Refer to the official documentation

The overall architecture

  • -Serena: Well, I’m not being a Producer.
  • -Penny: You’re a Consumer.
  • Broker: Stores, delivers, and queries messages
  • NameServer: Indicates the route registration center. The functions include Broker management and route information management

Data flow between modules

Production-consumption model

Message Sending Process

  • When the Broker starts, information is registered with NameServer
  • When a client invokes Producer to send a message, it first obtains routing information for the topic from NameServer. The header code is GET_ROUTEINFO_BY_TOPIC
  • Routing information returned from NameServer, including the list of queues and brokers contained in the topic
  • The Producer side selects a queue based on the query policy to store messages
  • Each message generates a unique ID that is added to the attributes of the message. The key of the property is UNIQ_KEY
  • Special processing is performed on the message. For example, if the message exceeds 4M, the message will be compressed
  • Producer sends an RPC request to the Broker, saving the message to the Broker side. The code of the message header is SEND_MESSAGE or SEND_MESSAGE_V2 (the configuration file has special flags set)

Message storage process

  • After receiving a message, the Broker saves the original message information in the MappedFile of the CommitLog file and asynchronously flusher it to disk
  • The ReputMessageServie thread asynchronously saves messages from the CommitLog MappedFile to the ConsumerQueue and IndexFile
  • ConsumerQueue and IndexFile are simply the index information of the original file

Message body structure

  • The message body of a CommitLog file varies in length. By default, each CommitLog file is 1 GB
  • The message body in ConsumerQueue is a fixed length of 20 bytes

Memory Mapping Process

  • Memory mapped files MappedFile through AllocateMappedFileService created
  • The creation of MappedFile is a typical producer-consumer model
  • MappedFileQueue queues the request when getLastMappedFile is called to get the MappedFile
  • AllocateMappedFileService threads continue listening to the queue, queue request, create MappedFile object
  • Finally, the MappedFile object is preheated, and the force method and mlock method are called at the bottom

Brush plate process

  • Messages sent from producer to broker are stored in MappedFile and then synchronized to disk through the flush mechanism
  • Disk brushing is classified into synchronous disk brushing and asynchronous disk brushing
  • Asynchronous flush background thread executes at a certain interval
  • Synchronous brushing is also a producer-consumer model. After the broker saves the message to the MappedFile, it creates a GroupCommitRequest to place on the list and blocks the wait. The background thread retrieves the request from the list and flushes the disk, notifying the waiting thread upon a successful flush.