消息队列|消息队列术语和常用MQ对比

1 消息队列术语

1、消息 : 两台计算机之间传送的数据单位，例如字符串、文本、对象等。
2、消息队列 : 消息的容器，用于在消息传递的过程中保存消息的容器，充当
消息源和目标之间的中间桥梁。队列的主要目的在于提高路由保证消息的传递。
3、发送者、生产者：创造、发送消息的一方；
4、消费者、订阅者：获取生产者发送的消息进行后续处理的一方；
5、消息中间件 : (Message Oriented Middleware,简称MOM),是消息队列的一种封装实现，提供了应用
程序和API。MOM是分布式系统中的重要组件,主要解决应用耦合，异步消息，流量削锋等问题。实现高性能，
高可用，可伸缩和最终一致性架构。常用的消息队列中间件：ActiveMQ，RabbitMQ，ZeroMQ，Kafka，RocketMQ等。

2 应用场景

（1）场景之异步处理
	如：将注册信息写入数据库成功后，发送注册邮件，发送注册短信。写库成成功后，
发送邮件的消息放入一个队列；发送短信的消息放入一个队列；对应的消费者自己拉取进行消费处理。
（2）场景之应用解耦
	如：用户下单后，订单系统需要通知库存系统。
	1.订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功。
	2.库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作。
	3.假如在下单时库存系统不能正常使用。也不影响正常下单，因为下单后，订单系统写入消息队列
就不再关心其他的后续操作。实现订单系统与库存系统的应用解耦。
（3）场景之流量削锋
	如：秒杀活动，一般会因为流量过大，导致流量暴增，应用挂掉。为解决这个问题，一般需要在
应用前端加入消息队列。
	1、可以控制活动的人数。
	2、可以缓解短时间内高流量压垮应用。用户的请求，服务器接收后，首先写入消息队列。
假如消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面；秒杀业务根据消息队列中
的请求信息，再做后续处理。
（4）场景之日志处理
	如：日志处理是指将消息队列用在日志处理中，比如Kafka的应用，解决大量日志传输的问题。
	1、日志采集客户端，负责日志数据采集，定时写受写入Kafka队列；
	2、Kafka消息队列，负责日志数据的接收，存储和转发；
	3、日志处理应用：订阅并消费kafka队列中的日志数据；

3 JMS消息模型

（1）JMS

	JMS是Java Message Service的缩写，即Java消息服务。它是JavaEE中一个关于消息的规范。
	1、定义一组消息公用概念和实用工具
	2、最大化消息应用程序的可移植性（无需关注RPC调用过程）
	3、最大化降低应用程序与应用程序之间的耦合度

（2）JMS消息模型

    1、点对点 : Queue ,不可重复消费
    消息生产者生产消息发送到queue中，然后消息消费者从queue中取出并且消费消息。
    消息被消费以后，queue中不再有存储，所以消息消费者不可能消费到已经被消费的消息。
Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。

   2、发布与订阅 : topic ,可重复消费
   消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。
和点对点方式不同，发布到topic的消息会被所有订阅者消费。

   3、发布与订阅 : topic ,支持订阅组的发布订阅模式
     发布订阅模式下，当发布者消息量很大时，显然单个订阅者的处理能力是不足的。实际上现实场景中是多个订
 阅者节点组成一个订阅组负载均衡消费topic消息即分组订阅，这样订阅者很容易实现消费能力线性扩展。可以看成
 是一个topic下有多个Queue，每个Queue是点对点的方式，Queue之间是发布订阅方式。

4 常用消息队列对比

5 消息队列集群两个问题

（1）生产者产生了2条消息：M1、M2，要保证这两条消息的顺序，应该怎样做？

	这个模型存在的问题是，如果M1和M2分别发送到两台Server上，就不能保证M1先达到，也就不能保证M1被先消
费，那么就需要在MQ Server集群维护消息的顺序。那么如何解决？一种简单的方式就是将M1、M2发送到同一个Server上。
	将消息从一台服务器发往另一台服务器，就会存在网络延迟问题。如果发送M1耗时大于发送M2的耗时，那么M2
就先被消费，仍然不能保证消息的顺序。如何解决这个问题？将M1和M2发往同一个消费者即可，且发送M1后，需要消
费端响应成功后才能发送M2。
	如果发送M1后，消费端1没有响应，那是继续发送M2呢，还是重新发送M1？一般为了保证消息一定被消
费，肯定会选择重发M1到另外一个消费端2。这样的模型就严格保证消息的顺序，仍然会发现问题，消费端1没有响应
时有两种情况，一种是M1确实没有到达，另外一种情况是消费端1已经响应，但是Server端没有收到。如果是第二种
情况，重发M1，就会造成M1被重复消费。可在消费端根据业务逻辑场景做幂等性处理。

（2）消息重复问题

保证每条消息都有唯一编号,在消费端根据业务逻辑场景做幂等性处理。