##背景：做部门技术分享时，学习整理了消息队列。
一、应用场景
消息队列中间件是分布式系统中重要的组件。主要解决 异步消息、应用耦合、流量削锋、日志收集 等问题，实现高性能，高可用，可伸缩和最终一致性架构。
异步处理 场景：用户注册后，需要发注册邮件和短信。
传统的做法有两种：a) 串行的方式；b) 并行方式。
a) 串行方式：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。
以上三个任务全部完成后，返回给客户端。
串行方式
b) 并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。
以上三个任务完成后，返回给客户端。
串行方式
两种方式对比：假设三个业务节点每个使用50毫秒钟，不考虑网络等其他开销。由于CPU在单位时间内处理的请求数是一定的，假设CPU 1秒内吞吐量是100次。
1、串行方式的执行时间是150毫秒，并行的时间是100毫秒。
2、串行方式1秒内CPU可处理的请求量是7次（1000/150）
3、并行方式处理的请求量是10次（1000/100）
引入消息队列，将不是必须的业务逻辑，异步处理。改造后的架构如下：
应用消息队列
1、用户的响应时间55毫秒。
2、系统的吞吐量提高到每秒20 QPS，比串行提高了3倍，比并行提高了2倍。
应用解耦 场景：用户下单后，订单系统需要通知库存系统。
传统的做法是，订单系统调用库存系统的接口。如下图：
传统方式
传统模式的缺点：
1、假如库存系统无法访问，则订单减库存将失败，从而导致订单失败。
2、订单系统与库存系统存在依赖。
引入消息队列，改进后架构如下：
引入消息队列
订单系统：用户下单后，完成持久化处理，将消息写入消息队列，返回用户订单成功。
库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，进行库存操作。
1、假如在下单时库存系统不能正常使用，也不影响正常下单。因为下单后，订单系统写入消息队列就不再关心其他的后续操作了。
2、实现订单系统与库存系统的应用解耦。
流量削峰 场景：秒杀活动，一般会因为流量过大，导致流量暴增，应用挂掉。
为解决这个问题，一般需要在应用前端加入消息队列。用户的请求，服务器接收后，首先写入消息队列。假如消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面，秒杀业务根据消息队列中的请求信息，再做后续处理。如图：
流量削峰
1、可以控制活动的人数。
2、可以缓解短时间内高流量压垮应用。
日志处理 场景：将消息队列用在日志处理中，比如Kafka，解决大量日志传输的问题。
日志收集
1、日志采集客户端，负责日志数据采集，定时写受写入Kafka队列。
2、Kafka消息队列，负责日志数据的接收，存储和转发。
3、日志处理应用：订阅并消费kafka队列中的日志数据。
二、两种模式
消息队列的两种模式：点对点、发布订阅。
p2p（点对点）包含三个角色：消息队列（Queue）、发送者(Sender)、接收者(Receiver)
p2p
1、每个消息都被发送到一个特定的队列，接收者从队列中获取消息。
2、队列保留着消息，直到他们被消费或超时。
P2P模式的特点：
1、每个消息只有一个消费者（Consumer）(即一旦被消费，消息就不再在消息队列中)。
2、发送者和接收者之间在时间上没有依赖性。
Pub/Sub（发布订阅）包含三个角色：主题（Topic）、发布者（Publisher）、订阅者（Subscriber）
Pub/Sub
1、多个发布者将消息发送到Topic，系统将这些消息传递给多个订阅者。
Pub/Sub的特点：
1、每个消息可以有多个消费者。
2、发布者和订阅者之间有时间上的依赖性。
3、为了消费消息，订阅者必须保持运行的状态。
三、组成部分
几个重要概念
Producer：消息生产者，就是投递消息的程序。
Broker：消息队列服务器实体。
Consumer：消息消费者，就是接受消息的程序。
Queue：消息队列载体，每个消息都会被投入到一个或多个队列。
消息队列逻辑结构如下，其中中间是queue。（实际载体为broker）
逻辑结构
消息队列的本质：两次RPC加一次转储
消息队列
1、RPC通信协议：负载均衡、服务发现、通信协议、序列化协议。
2、高可用：依赖于RPC和存储的高可用来做的。
3、服务端承载消息堆积的能力（依赖4）
a) 为了满足错峰/流控/最终可达等一系列需求，把消息存储下来，然后选择时机投递；
b) 存储可以做成很多方式。比如存储在内存里，存储在分布式KV里，存储在磁盘里，存储在数据库里等等。归结起来，主要有持久化和非持久化两种。持久化的形式能更大程度地保证消息的可靠性（如断电等不可抗外力），并且理论上能承载更大限度的消息堆积（外存的空间远大于内存）
4、存储子系统选型：从速度来看，文件系统>分布式KV（持久化）>分布式文件系统>数据库，可靠性截然相反。
5、消费关系选型
a) 解析发送接收关系，进行正确的消息投递了；
b) 发送关系的维护，发送关系变更时的通知，如config server、zookeeper等。
四、典型问题
顺序有序：指的是可以按照消息的发送顺序来消费
例如：一笔订单产生了 3 条消息，分别是订单创建、订单付款、订单完成。消费时，要按照顺序依次消费才有意义。与此同时多笔订单之间又是可以并行消费的。示例：假如生产者产生了2条消息：M1、M2，要保证这两条消息的顺序，应该怎样做？
保证消息有序，可能会采用的方法
假定M1发送到S1，M2发送到S2，如果要保证M1先于M2被消费，那么需要M1到达消费端被消费后，通知S2，然后S2再将M2发送到消费端。如果M1和M2分别发送到两台Server上，就不能保证M1先达到MQ集群，也不能保证M1被先消费。换个角度看，如果M2先于M1达到MQ集群，甚至M2被消费后，M1才达到消费端，这时消息也就乱序了。说明以上模型是不能保证消息的顺序的。
如何才能在MQ集群保证消息的顺序？
一种简单的方式就是将M1、M2发送到同一个Server上：
为保证消息顺序，改进后的方法
这样可以保证M1先于M2到达MQServer（生产者等待M1发送成功后再发送M2），根据先达到先被消费的原则，M1会先于M2被消费，这样就保证了消息的顺序。这个模型也仅仅是理论上可以保证消息的顺序，在实际场景中可能会遇到下面的问题：M1晚于M2到达消费端。
网络延迟问题
如果发送M1耗时大于发送M2的耗时，那么M2就仍将被先消费。即使M1和M2同时到达消费端，由于2个消费端负载不同，仍然可能出现M2先消费。
那如何解决这个问题？
将M1和M2发往同一个消费者，且发送M1后，需要消费端响应成功后才能发送M2。M1被发送到消费端后，消费端1没有响应，那是继续发送M2呢，还是重新发送M1？一般为了保证消息一定被消费，肯定会选择重发M1到另外一个消费端2。
保证消息顺序的正确姿势
总结起来，要实现严格的顺序消息，简单且可行的办法就是：保证 生产者 - Server - 消费者是一对一对一的关系
这样的设计虽然简单易行，但也会存在一些很严重的问题，比如：
1、并行度就会成为消息系统的瓶颈（吞吐量不够）
2、更多的异常处理，比如：只要消费端出现问题，就会导致整个处理流程阻塞。
消息重复
消费端1没有响应Server时有两种情况：
1、M1确实没有到达(数据在网络传送中丢失)；
2、消费端已经消费M1且已经发送响应消息，只是MQ Server端没有收到。
如果是第二种情况，重发M1，就会造成M1被重复消费。也就引入了消息重复问题。
造成消息重复的根本原因是：网络不可达。
解决办法：
1、消费端处理消息的业务逻辑保持幂等性。
2、保证每条消息都有唯一编号且保证消息处理成功与去重表的日志同时出现。
版本号应用
示例：一个产品的状态有上线、下线。消息M1是上线，M2是下线。不巧M1判重失败，被投递了两次，且第二次发生在M2之后，如果不做重复性判断，显然最终状态是错误的。
引入版本号：每个消息自带一个版本号。
每次只接受比当前版本号大的消息。初始版本为0，当消息1到达时，将版本号更新为1。消息2到来时，因为版本号>1.可以接收。 同时更新版本号为2.当另一条下线消息到来时，如果版本号是3.则是真实的下线消息。如果是1，则是重复投递的消息。
新的问题：但很多时候，消息到来的顺序错乱了。比如应该的顺序是12，到来的顺序是21。
解决方案：只处理版本+1，如果想让乱序的消息最后能够正确的被组织，那么就应该只接收比当前版本号大一的消息。
参考及引用资料
3、消息队列设计精要
网友评论