The opening is introduced

This is the second in a series of middleware interview questions that summarize RocketMQ interview questions. In the follow-up, I will sum up the knowledge line at the beginning of the first chapter all the way to the day! If I can do 100 days 100 more, I hope you can follow 100 days 100 brush, 100 days to develop a good habit.

How to select multiple MQS?

RabbitMQ Erlang is not well supported for message stacking, which can cause RabbitMQ performance to degrade dramatically when a large number of messages are backlogged. It can process tens of thousands to hundreds of thousands of messages per second.

RocketMQ Java is an Internet cluster-based, feature-rich application that optimizes the response latency of online services. In most cases, it can process hundreds of thousands of messages per second.

Kafka Scala development, log oriented, feature rich, the highest performance. When your business scenario doesn’t have as many messages per second, Kafka’s latency can be high. As a result, Kafka is not well suited for online business scenarios.

ActiveMQ Java development, simple, stable, performance as the first three. Is not recommended.

What are the RocketMQ components?

Nameserver stateless, dynamic list; This is one of the key differences from ZooKeeper. Zookeeper is stateful.

Producer A Producer of messages that sends messages to the Broker.

The Broker is MQ itself, responsible for sending and receiving messages, persisting messages, and so on.

Consumer Message Consumer, which is responsible for pulling messages from the Broker for consumption and ack after consumption.

How many RocketMQ consumption modes are there?

Cluster consumption

  • A message will only be consumed by one Consumer in the same Group
  • When multiple groups consume a Topic at the same time, each Group will have one Consumer consume data

Radio consumption

  • The message will be consumed for each Consumer instance under a Consumer Group. Even if the consumers belong to the same Consumer Group, the message will be consumed once by each Consumer in the Consumer Group.

What about message duplication consumption?

A consumer would normally send an ACK to inform the broker that the message has been consumed and removed from the queue. If an ACK cannot be sent to the broker for network reasons, the broker will assume that the message has not been consumed. The message redelivery mechanism is then enabled to redeliver the message to the consumer.

Consumption patterns: In the CLUSTERING model, messages are guaranteed to be consumed once by consumers of the same group within the broker, but pushed multiple times by consumers of different groups

The solution

  • Database tables: Insert into constrained fields in the table using the message primary key before processing the message
  • Map: In single-node mode, you can use Map to limit messages. When consuming messages, you can check whether the current message ID already exists
  • Redis: Use distributed locks.

How does RocketMQ ensure sequential consumption of messages?

First of all, multiple queues only guarantee the order in a single queue, which is a typical FIFO, natural order. Simultaneous consumption of multiple queues is not an absolute guarantee of message order. You can use the same topic, same QUEUE, one thread to send messages, and one thread to consume messages from a QUEUE.

How does RocketMQ ensure that messages are not lost?

The Producer uses send() to send messages synchronously, and the sending results are synchronously aware. If the sending fails, you can retry. Three times by default.

Changed the flush policy of the Broker to synchronous flush. By default, disks are flushed asynchronously. Cluster deployment

After complete consumption on the Consumer end is normal, manual ACK confirmation is performed

How does RocketMQ implement distributed transactions?

The producer sends a half message to the MQ server. 2. After the half message is successfully sent, the MQ server returns an acknowledgement message to the producer. 3. The producer starts to execute the local transaction. 4. Send commit or rollback messages to MQ Server based on the result of local transaction execution (unknown, COMMIT, rollback). 5. If a commit/rollback message is missed (possibly due to a network exception, sudden producer outage, etc.), the MQ server will send a backcheck message to each producer in the same group to get the transaction status. 6. Check the state of local things. 7. The producer sends commit/rollback messages based on the local transaction status. 8. The MQ server will discard the rollback messages, but the committed (double-validated half messages) messages will be delivered to the consumer for consumption.

Half Message: Pre-processed messages that are stored in RMQ_SYS_TRANS_HALF_TOPIC’s Message consumption queue when received by the broker

Check transaction status: The Broker starts a scheduled task to consume messages in the RMQ_SYS_TRANS_HALF_TOPIC queue. Each execution of the task confirms the transaction status (committed, rolled back, unknown) to the message sender. If it is unknown, the Broker periodically calls back to recheck.

Timeout: The message is rolled back by default if the number of times the message is checked exceeds. Instead of actually entering the Topic queue, he uses a temporary queue to hold the so-called half message, and then transfers the half message to the Topic queue after the transaction is committed.

How is message accumulation handled for RocketMQ?

2. If there is a queue but there are too many consumers, add the data amount of consumers. You can prepare a temporary topic, create queues, and temporarily create a consumer to transfer these messages to the topic for consumption.