# 1. Message middleware
Message queue technology is a technology for exchanging information between distributed applications. Message queues can reside in memory or on disk, and the queue stores messages until they are read by the application. With message queues, applications can execute independently - they do not need to know each other's location or wait for the receiving program to receive the message before continuing. In general, message middleware has the following functions: reducing coupling, reducing traffic peaks, asynchronous communication, and reliable transmission1. Reduce coupling: loose coupling through publish and subscribe Let’s take the registration business as an example. If the registration is successful, SMS and email will be sent to the user for confirmation. The traditional architecture model is as follows: Email business and SMS business The code is written in the user registration process. Whether it is implemented through an interface or a remote call, the coupling degree is very high. Now, a new requirement is added. After the user registration is completed, emails will not be sent. It is to "increase points" for users. Let's analyze these situations: First, the business processing after successful registration is implemented in a business system through code accumulation and interface calling. We need To change the registration code, you need to start and stop the application when going online. This method has the highest degree of coupling. Secondly, through remote calling, when we want to add new business processing, we still need to change the main process code, which cannot avoid starting and stopping the application. If we introduce message middleware, as follows: #Through publish and subscribe, after the user successfully registers, a message is sent to the message middleware, each The business end subscribes to the messages of the same channel and executes the corresponding business after receiving the message of successful registration. With the addition of "Add Points", it is enough for the point system to handle the relevant processing and subscribe to this message. There is no need to change the user's business code or start or stop the application, and the smooth expansion of the business can be achieved. 2. Asynchronous communication Taking the above example, in the traditional architecture, when the user registration is completed and the SMS email is sent, the client is returned to notify the user that the registration is successful. After using the message middleware, after the user submits the registration information and the processing is completed, the user can be prompted to register successfully. Subsequent SMS services and email services will receive the user registration success message from the subscribed channel before sending SMS messages and emails. There is no longer any need between businesses. Mutual restraint. 3. Traffic peak reduction and surge preventionMessage middleware can accumulate messages during the peak period, and after the peak value passes, the downstream system slowly consumes messages to solve the problem of traffic peak. When the concurrency reaches its peak, the pressure on the back-end system is usually very high. Whether it is an application server or a database server, at this time, similar requests can be placed in the message queue of the message middleware and accumulated for slow processing. You can also set the size of the message queue to control the amount of concurrency. The business scenario of product flash sales is relatively typical. 4. Reliable transmissionMessage-based communication is reliable and messages will not be lost. Most messaging middleware provides the functionality to persist messages to disk. In the first scenario at the beginning, the message middleware can persist the messages produced by the producer to the disk. The back-end application goes down, but the messages are not lost and the application is restarted to continue processing. You may have this question, if the message middleware is down, how can it be persisted if the message cannot be received? It doesn't matter, the message middleware provides a variety of message replication strategies, persistence strategies, cluster deployment strategies, etc., which can ensure the reliable transmission of messages.2. Message middleware model
##3. Commonly used message middleware##RabbitMQ
1. RabbitMQ features:
RabbitMQ is a An open source implementation based on the AMQP standard developed in the Erlang language. RabbitMQ originally originated from financial systems and is used to store and forward messages in distributed systems. It performs well in terms of ease of use, scalability, and high availability. Its specific features include:ReliabilityFlexible routingSupport message cluster
High availability
Support multiple protocols (in addition to supporting AMQP protocol, it also supports other message queue protocols through plug-ins, such as STOMP and MQTT)
Support multi-language clients
Provide management interface
Provide tracking mechanism
Provide plug-in mechanism (RabbitMQ provides many plug-ins, and you can also write your own plug-ins)
Summary:
The biggest advantage of RabbitMQ is that it provides a relatively flexible message routing strategy, high availability, reliability, rich plug-ins, multiple platform support and complete documentation. However, due to the AMQP protocol itself, its implementation is relatively heavy, which puts its throughput at a disadvantage compared with other MQs (such as Kafka).
ActiveMQ
1.ActiveMQ Features:
ActiveMQ is an open source messaging middleware produced by Apache, designed to provide efficient , scalable, stable, and secure enterprise-level messaging communications. ActiveMQ implements JMS 1.1 and provides many additional features, such as JMX management, master-slave management, message group communication, message priority, delayed message reception, virtual receivers, message persistence, message queue monitoring, etc. The main features are as follows:
Supports clients and protocols in multiple languages such as Java, C, C, C#, Ruby, Perl, Python, PHP, etc., such as OpenWire, STOMP, AMQP, and MQTT protocols.
Provides advanced features such as message group communication, message priority, delayed message reception, virtual receivers, and message persistence.
Fully supports JMS 1.1 and J2EE 1.4 specifications (including persistence, distributed transaction messages, transactions)
Supports Spring framework, ActiveMQ can be easily embedded in Spring applications through Spring configuration files .
Passed common J2EE server tests, such as TomEE, Geronimo, JBoss, GlassFish, and WebLogic.
Diversified connection methods, ActiveMQ provides a variety of connection methods, such as in-VM, TCP, SSL, NIO, UDP, multicast, JGroups, JXTA.
Supports fast persistence of messages through the use of JDBC and Journal.
Designed for high-performance cluster, client-server, point-to-point communication and other scenarios.
Provides a technology- and language-neutral REST API interface.
Supports calling ActiveMQ via AJAX.
ActiveMQ can be easily integrated with WebService technologies such as CXF and Axis to provide reliable messaging.
Can be used as an in-memory JMS provider, very suitable for JMS unit testing.
Kafka
1.Kafka features:
Kafka was first developed by LinkedIn as a distributed publish/subscribe messaging system. , which later became Apache's top-level project. Its main features are as follows:
Provides high throughput for both publishing and subscription. (Kafka’s design goal is to provide message persistence capabilities with a time complexity of O(1). It can guarantee constant-time access performance even for data above the TB level, and can do it even on very cheap commercial machines. Supports the transmission of 100K messages per second to a single machine)
Message persistence. (Persist messages to disk, so can be used for batch consumption, such as ETL as well as real-time applications. Data loss can be prevented by persisting data to hard disk and replicating it.)
Distributed. (Supports message partitioning and distributed consumption between servers, while ensuring the sequential transmission of messages within each Partition. Its internal Producer, Broker and Consumer are all distributed architectures, which makes it easier to expand outwards.)
Consuming messages adopts Pull mode. (The status of the message being processed is maintained on the Consumer side, not on the server side. The Broker is stateless and the Consumer saves the offset itself.)
Supports Online and Offline scenarios, as well as offline data processing and real-time data deal with.
RocketMQ
1. RocketMQ features:
RocketMQ is a distributed messaging middleware open sourced by Alibaba in 2012 and later donated to Apache software Foundation, and became an Apache top-level project on September 25, 2017. As a domestic middleware that has experienced many "super projects" such as Alibaba's "Double 11" and has stable and outstanding performance, it has been used by more and more domestic users in recent years for its high performance, low latency and high reliability. Used by businesses. Its main features are as follows:
It has flexible scalability. (RocketMQ naturally supports clusters, and each of its four core components (NameServer, Broker, Producer, and Consumer) can be horizontally expanded without a single point of failure.)
Has the ability to accumulate massive messages. (RocketMQ uses the zero-copy principle to achieve the ability to accumulate extremely large amounts of messages. It is said that a single machine can support the accumulation of hundreds of millions of messages, and it still maintains low writing latency after accumulating so many messages)
Supports sequential messages. (RocketMQ can ensure that message consumers consume messages in the order in which they are sent. Sequential messages are divided into globally ordered messages and locally ordered messages. It is generally recommended to use locally ordered messages, that is, the producer sends a certain type of message in order Send to the same queue to achieve.)
Supports multiple message filtering methods. (Message filtering is divided into server-side filtering and consumer-side filtering. When filtering on the server side, filtering can be performed according to the requirements of message consumers. The advantage is that unnecessary message transmission is reduced, and the disadvantage is that it increases the burden on the message server. Implementation Relatively complex. Consumer-side filtering is completely customized by specific applications. This method is more flexible. The disadvantage is that many useless messages will be transmitted to message consumers.)
Support transaction messages. (In addition to supporting ordinary messages and sequential messages, RocketMQ also supports transaction messages. This feature provides another solution for distributed transactions.)
Supports backtracking consumption. (Retroactive consumption means that messages that have been successfully consumed by consumers need to be consumed again due to business needs. RocketMQ supports retroactive consumption according to time. The time dimension is accurate to milliseconds, and can be traced forward or backward.)
MoreFAQ, please visit the PHP Chinese website.
The above is the detailed content of What are rpc middleware?. For more information, please follow other related articles on the PHP Chinese website!