When interviewing for a large Internet company, you’re likely to be asked about message queues:
1. In what scenarios is messaging middleware used?
2. Why introduce message-oriented middleware into the system?
3. How to achieve idempotent?
Chain call is the general process when we write A program. In order to complete an overall function, it will be divided into multiple functions (or sub-modules), such as module A calls module B, module B calls module C, and module C calls module D. However, in large-scale distributed applications, RPC interaction between systems is complicated, and it is not impossible to call hundreds of interfaces behind one function. This architecture has the following disadvantages:
1. The coupling between these interfaces is quite serious. For each new downstream function, relevant interfaces on the interface should be reformed; For example, if System A wants to send data to systems B and C, the data sent to each system may be different, so system A assembles the data to be sent to each system and sends it one by one. When the code goes live, a new requirement is added: send data to D as well. At this point, system A needs to be modified so that it can sense the existence of D and process the data well for D. In this process, you will see that every time A downstream system is connected, the code of system A needs to be reformed, and the efficiency of joint development is very low. Its overall architecture is shown as follows:
2, in the face of large flow concurrency, easy to be overwhelmed **. ** The throughput capacity of each interface module is limited, and this upper limit capacity if the dam, when heavy flow (flood) is coming, is liable to be washed out.
3. Performance problems exist. RPC interfaces are basically synchronous calls, and the overall service performance follows the “bucket theory”, that is, the slowest interface in the link. For example, it takes 50ms for A to call B/C/D, but B calls B1 again at this time, which costs 2000ms, so the whole service performance will be directly dragged down.
According to the above questions, the goals to be achieved can be clearly defined when designing the system:
1. To achieve system decoupling, when new modules are connected, code changes can be minimized;
2. Set the flow buffer pool, so that the back-end system can consume according to its capacity and not be washed down;
3. Strong and weak dependence combing, asynchronize the operation of non-critical call links, and improve the throughput capacity of the whole system. For example, in the figure above, A, B, C and D are several key processes that allow users to initiate payment and then return the notification of successful payment, while B1 is A module that notifies merchants of delivery after payment. Then in essence, the user has a high tolerance for B1 completion time (such as a few seconds later), so it can be asynchronized.
MQ message queues are widely used in today’s systems and are a perfect solution to these problems. The following diagram shows A simple architecture using MQ. You can see that MQ stores the traffic at the front end, while downstream system A\B\C deals only with MQ, parsed in A predefined message format.
After introducing the MQ system architecture, interaction, and the initial call chain architecture is very different, although you can solve the problems of the mentioned above, but also should fully understand its principle features to avoid its side effects, here in the message queue how to ensure the reliable message delivery “as the breakthrough point, to see the realization of the MQ mode.
1. How does the Client reliably deliver messages to MQ
1. The Client sends a message to MQ
2. After persisting the MESSAGE, MQ sends an Ack message to the Client. The Ack message may fail to be sent to the Client due to a network fault.
3. After receiving the Ack message, the Client considers that the Ack message is successfully delivered.
2. How does MQ reliably deliver messages to clients
1.MQ pushes messages to clients (or clients pull messages)
2. The Client receives the message and completes the service logic
3. The Client sends an Ack message to MQ and notifies MQ to delete the message. In this case, the Ack may fail due to a network problem and the Client may repeat the message, which leads to the consumption idempotent problem.
4.MQ deletes consumed messages
Concern public number: Java baodian
