1. RocketMQ implementation principle
2. Why write NameServer without Zk?
1. NameServer is written by yourself, which is convenient for expansion and decentralization. As long as there is a NameServer, the entire registration center environment can be used.
2. Zk election needs to meet more than half of the mechanism before it can be used.
Three, four cluster methods:
1. A single master node: the load pressure is very large, and data may be lost if it is down
2. Multiple master stages: shared storage data, but if there is no slave node, data may be lost when the machine is down
3, multiple masters With multiple slave nodes, the synchronous form realizes the master-slave data synchronization, and the producer returns the message to the master and then synchronizes it to the standby broker before returning the ack to confirm the successful delivery of the message.
4. Multiple master and multiple slave nodes, asynchronous form realizes master-slave data synchronization , The producer stores the message to the master, returns ack to confirm that the message is successfully delivered, and asynchronously synchronizes to the standby broker, which is highly efficient, but the data may be lost
4. Will the Broker use be affected when the Broker is expanded? Can it be curtailed?
No, because the producer realizes data storage through polling through the number of nodes registered in the NameServer, the number of nodes is not written dead
Can be reduced, but the premise is that the messages in the Broker must be consumed
Fifth, the difference between RocketMQ and Kafka
| RocketMQ | Kafka | |
|---|---|---|
| Registration Center | Zookeeper | NameServer |
| Broker | Logical concept, one Broker is equal to multiple Master combinations | Physical concept, a Broker is a |
| Transaction news | stand by | |
| Sequential message | stand by | A Brocker corresponds to a consumer to achieve sequential messages |
6. How to increase the throughput of RocketMQ in the stand-alone version?
Only need to add queues and consumers
Seven, Rocketmq's core ideas for solving distributed transactions
1. The producer sends our Broker (MQ server side) our dispatch message to be a semi-message, and this message cannot be consumed by consumers.
2. When executing our local transaction, submit or rollback the result of the local execution transaction to Broker
3. If Broker obtains the result of the local transaction if it is submitted, set the half message to be allowed to be consumed by the consumer, if the local transaction case fails, the message is removed from the semi-Broker in
4. If our local transaction did not result in a timely manner to inform us of the Broker, this time we will take the initiative Broker timer (default 60s) the results of the query local transaction
5. The local transaction result is actually a callback method, encapsulating the local transaction result according to its own business scenario
At this time, local transactions must use manual transactions, with annotations, the transaction is not easy to control
Eight, RabbitMQ solves the defects of distributed transaction problems
RabbitMQ solves the problem of distributed transactions. If the replenishment queue is also suspended, the order data may be lost, but the order can be successfully dispatched, and then it must be compensated manually.
Nine, the core idea of solving distributed transactions
1. Final consistency
2. Ensure the success of the first transaction
Ten, the background of distributed transactions
rpc remotely calls the communication between multiple different services to ensure data consistency. There are multiple data sources. The transactions of each data source do not affect each other.
11. Others
RocketMQ stand-alone version, by default, is divided into four queues in a Topic, the purpose is for high throughput
Broker contains topics, topics include queues
Kafka has copy backup
Kafka is a partition, a broker has multiple partitions
RocketMQ is a queue, a broker has multiple queues
The number of queues in RocketMQ must be the same as the number of consumers
How do the three mqs implement sequential messages?
How are they clustered?
lcn is no longer maintained, and now mainly uses seata
RocketMQ has experienced the test of double 11
written in java language, understand the source code is easy to expand and maintain
RocketMQ is an upgrade of kafka
9876 is the default port number of NameServer
Producers must be grouped, otherwise an error will be reported
If consumers are in the same group, only one consumer will consume the same message
Features of RocketMQ
1. Support transaction messages
2. Support sequential messages
3. Consumers support tag filtering to reduce bandwidth transmission
4. Java language writing, easy to expand and maintain
5. RocketMQ has experienced the test of double 11
NameServer: Similar to eureka for service registration and discovery, producer, consumer, and topic information are all stored on NameServer. Decentralized. Realize dynamic awareness, avoid downtime and modify address
Broker: MQ server
Producer: Producer
Consumer: Consumer
brokerid = 0 is the master node> 0 as the slave node
apparatus becomes dominant changed manually
