The role of ActiveMQ messaging middleware and application scenarios
A, ActiveMQ Profile
Apache ActiveMQ is produced, most popular, strong ability to open source message bus. ActiveMQ is a fully supported JMS1.1 and J2EE1.4 standard JMS Provide implementation. Although the JMS specification has been introduced a long time ago, but in today's J2EE JMS applications still play this special status.
Two, ActiveMQ application scenarios
Message Queuing in a large e-commerce sites, such as Jingdong, Taobao, where to sites such as this in-depth application.
The main role of the queue: the elimination of high peak concurrent access, speed up the response speed of the site.
Without the use of the message queue, the request of the user data directly into the database, in case of high concurrent, enormous pressure on the database, while also increasing the system response delay;
After use the queue earlier, immediately after the user issued a request to return a queue;
For example: Of course not prompted to submit orders directly to the customer success, tips on Taobao: "You submit an order, please wait for the system to confirm"
Then access to the database from the message queue by the consumer processes the message queue, asynchronously written to the database.
Since the message queue service processing speed much faster than the database, the user's response delay may be effectively improved.
Flowchart illustrations, as follows:
Third, the message queue described
Middle message queue is important component of the distributed system, the main application to solve coupled, asynchronous message, the peak and flow problems;
High performance, high availability, scalable architecture and eventual consistency; large-scale distributed systems is essential middleware.
Currently in production environments use more message queues: ActiveMQ, RabbitMQ, Kafka, ZeroMQ, MetaMQ, RocketMQ and so on.
Four, message queue scenarios
1, asynchronous processing
Scene Description: After user registration, you need to send registered mail and SMS registration. Conventional practice in two ways: serial mode, a parallel mode;
(1) Serial: After successful registration information into the database, the occurrence of registered mail registration SMS again. After more than three tasks completed, returned to the client.
(2) parallel: After successful registration information into the database, simultaneously registered mail, SMS registration occurred after more than three tasks completed, returned to the client, and the difference is serial, parallel processing can improve the way time;
假设三个业务节点每个使用50ms，不考虑网络等其他开销，则串行方式的耗时是150ms；并行的耗时是100ms；
因为CPU在单位时间内处理的请求数是一定的，假设CPU 1秒内吞吐量是100次；则串行方式1秒内CPU可以处理的请求量是7次（1000/150）;并行方式可处理请求量是10次（1000/100）;
综上所述，传统的方式系统的性能（并发量、吞吐量、响应时间）会有瓶颈。如何解决这个问题？
引入消息队列，将不是必须的业务逻辑，异步处理，改造后的架构如下图：
安装上述约定，用户的响应时间相当于是注册信息写入数据库的时间，也是就是50ms.
注册邮件，发短信写入消息队列后，直接放回，因此写入消息队列的速度很快，基本可以忽略。
采用消息队列后用户的响应数据可能就是50ms。所以基于此架构，系统的吞吐量提高到每秒20QPS；比串行提高了3倍，比并行提高了2倍。
2，应用解耦
场景说明：用户下单后，订单系统需要通知库存系统。传统的做法：订单系统调用库存系统接口。如下图：
传统模式的缺点：
1>.假如库存系统无法访问，则订单减库存将失败，从而导致订单失败；
2>.订单系统与库存系统耦合；
如何解决以上问题？引入应用消息队列后的方案，如下图：
1>.订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功，请等等物流配送。
2>.库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作。
3>.假如在下单时库存系统不能正常使用，也不影响正常下单。因为下单后，订单系统写入消息队列就不再关系其他的后续操作了，实现订单系统与库存系统的应用解耦。
3，流量消峰
流量消峰也是消息队列中的常用场景，一般在秒数或者团抢活动中使用广泛。
应用场景：秒数活动，一般因为流量过大，导致流量暴增，应用容易挂掉。为解决这个问题，一般需要在应用前端假如消息队列。
（1）可以控制活动人数。
（2）可以缓解短时间内高流量压垮应用；
引入消息队列：
1>.用户的请求，服务器接收后，首先写入消息队列。假如消息队列长度超过最大数量，则直接抛弃用户请求或者跳转到错误页面；
2>.秒杀业务根据消息队列的请求信息，再做后续处理；
4，消息通讯
消息通讯是指：消息队列一般都内置了高效的通讯机制，因此也可以用在纯的消息通讯。比如实现点对点的消息队列或者聊天室等。
（1）点对点通讯
客户端A和客户端B使用同一队列，进行消息通讯。
（2）聊天室通讯（发布订阅）
客户端A、客户端B、客户端N订阅同一主题，进行消息发布和接收，实现类是聊天室效果。