消息队列的应用及实现分析总结

前言

消息队列的本质实际就是队列，先进先出，只不过队列中存放的是msg。通过这种方式实现通信。通常在不同的进程，不同的server以及不同的线程之间会使用这种方式来实现。

消息队列的应用场景

异步处理

消息推送的时候一般需要经过繁琐的步骤，需要对传递的消息进行处理才能最终下发到用户，但是如果这些步骤都顺序执行的话，造成的缺点就是不能保证消息的时效性，一旦并发量增大，那么就会造成阻塞。
因此许多场景下需要进行异步处理，将消息存到队列中，分发给其他的client同时执行。这样的话，就可以减少等待，实现并发处理，提高了系统的执行效率。
一般APP推送，短信通知，终端状态推送，用户注册等会用到。
以下就是秒杀系统一个例子：
如果按照以下的方式同步执行的话，时效性会很低

因此，一般会采用下面的方式，用消息队列将资源同时分发给下面的步骤并发执行。实现异步处理

流量控制（削峰）

流量控制的话，比较典型的应用场景就是在秒杀系统中，隔离网关和后台的服务，实现流量控制。比如说秒杀系统，当订单抢的人数超过水位线的时候，也就是消息队列里面的消息已经达到上限的时候，后面的消息就不会传到后端进行处理。这样可以降低后端的负载压力。
但是这个水位线就需要自己控制好，如果频繁的出发削峰的话就需要增大水位线。

服务解耦

服务解耦实际上是设计上的一种选择，当服务端不断地有新的需求，需要调用不用平台的接口的话，每次都需要修改服务端的代码。并且由于是一种强耦合的设计，每次服务端推消息的话，所有的客户端都能收到，这就导致客户端被动的接收了很多无用的消息。

但是解耦的话就是利用消息队列的订阅机制，每个客户端需要消息的时候主动去消息队列中取消息。

发布订阅

发布订阅这种机制用到消息队列，有很多的应用场景。当对端需要数据的时候就需要订阅这个消息队列。然后服务端广播这个消息对端就能收到消息。

高并发缓冲

这块的话主要就是日志服务以及监控上报，有兴趣的话可以看下kafka的日志上报。

消息队列的一些基本概念

broker

通俗的讲就是MQ的服务器。

生产者和消费者

这个应该比较熟悉，生产者就是负责将消息发送到消息队列，消费者负责取消息队列中的消息使用。

点对点的消息队列模型

这种模型的话就是消费者和生产者的运行状态可以不同步。生产者只管将消息放到约定好的队列，消费者取消息。每个消息都能确保被消费者执行到。

发布订阅的消息队列模型

这种模型发布端和订阅端也是不进行交互的，双方通过消息队列进行消息的处理。发布端将消息放入消息队列。消息队列将消息发送给订阅消息的多个订阅者。

消息的顺序性保证

消息队列的基础是队列，因此，遵循队列先入先出的模式，保证消息的顺序执行。

消息队列的ACK确认机制

为了确保消息的可靠性，消息队列加入了ACK的机制。当消息队列处理完一个消息的时候，需要收到对端的ACK之后才会将此消息删除，如果没有收到对端的ACK说明对端可能出现问题，此时需要再重新传一遍消息给对端，重新处理消息。
但是这种ACK的机制很难做到高吞吐量，但是优点就是消息确保可达，延迟低。这时候一般会使用批量的处理消息来稍微提高吞吐量。
Tips：常见的保证消息可靠性的机制有哪些？
答：Ack机制；超时重传；定义序列号，消息连续的话表示消息没有丢；消息的备份；以及持久化。

消息的持久化

消息的持久化是指将消息存到内存中，以便一些核心的业务处理在消息队列宕机之后消息的恢复。

消息的同步和异步收发

消息的收发支持同步和同步和异步的方式。同步的方式虽然可以确保消息准确的传输，但是消息队列发送和接收是同步的方式意味着当一端没有发送的话，接收端就只能一直等待发送端的消息，时效性很低。
异步的方式相对而言就效率高了很多。不需要应答，可以实现批量的ACK或者发送的场景。
为什么采用消息异步的方式？
答：如果是send-Ack一一对应的话肯定是吞吐量比较低，异步收发可以实现批量处理，提高吞吐量，但时效型就降低了。

消息的事务支持

这里的事务实际上和MySQL的事务实际比较相似。一个处理可能包含多条消息，这多条消息的处理就形成一个事务。

几种比较常见的消息队列产品

我们今天讲的是ZeroMQ的使用，ZMQ和其他MQ的主要的区别就是它不是一个独立的服务，是调用API来实现的。对用MQ的具体选用还是需要看自己的业务需求。

ZeroMQ模型使用示例

REQ/REP请求响应模型

需要注意的是请求响应模型都是一次请求一次响应。客户端发送多次数据的话，服务端只能收到一次。
代码中，客户端和服务器谁先起都可以。

PUB/SUB消息订阅模型

订阅模型是一种一对多的模式，可以对应多个订阅的客户端。多个客户端订阅消息之后可以同时收到消息。

Push/Pull 推拉模型

这种模型可以用于并行处理，中间worker可以多个并行执行，执行结束之后将结果汇总到sink。

Router/Dealer 模型

这种模型是一种多对多的模型，中间也是有一种负载均衡的操作来实现多对多的操作。