消息队列（一）之细聊消息队列

前言

不知道在大家的开发过程中，有没有碰到需要用到消息队列。之前的工作中使用的是kafka作为消息队列！
目前在写自己的论文，也需要用到消息队列，所以就把它系统的总结一下！

消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题
实现高性能，高可用，可伸缩和最终一致性架构
使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ

个人认为消息队列的主要特点是异步处理，主要目的是减少请求响应时间和解耦。所以主要的
使用场景就是将比较耗时而且不需要即时（同步）返回结果的操作作为消息放入消息队列。同时由
于使用了消息队列，只要保证消息格式不变，消息的发送方和接收方并不需要彼此联系，也不需要
受对方的影响，即解耦和。
举一个经常遇到的场景：
假设用户在你的软件中注册，服务端收到用户的注册请求后，它会做这些操作：

• 1） 校验用户名等信息，如果没问题会在数据库中添加一个用户记录
• 2）如果是用邮箱注册会给你发送一封注册成功的邮件，手机注册则会发送一条短信
• 3）分析用户的个人信息，以便将来向他推荐一些志同道合的人，或向那些人推荐他
• 4）发送给用户一个包含操作指南的系统通知，等等。。。。

但是对于用户来说，注册功能实际只需要第一步，只要服务端将他的账户信息存到数据库中
他便可以登录上去做他想做的事情了。至于其他的事情，非要在这一次请求中全部完成么？
值得用户浪费时间等你处理这些对他来说无关紧要的事情么？
所以实际当第一步做完后，服务端就可以把其他的操作放入对应的消息队列中然后马上返回
用户结果，由消息队列异步的进行这些操作。

或者还有一种情况，同时有大量用户注册你的软件，再高并发情况下注册请求开始出现一些
问题，例如邮件接口承受不住，或是分析信息时的大量计算使cpu满载，这将会出现虽然用户
数据记录很快的添加到数据库中了，但是却卡在发邮件或分析信息时的情况，导致请求的响应
时间大幅增长，甚至出现超时，这就有点不划算了。面对这种情况一般也是将这些操作放入消
息队列（生产者消费者模型），消息队列慢慢的进行处理，同时可以很快的完成注册请求，不
会影响用户使用其他功能。

所以在软件的正常功能开发中，并不需要去刻意的寻找消息队列的使用场景，而是当出现性能
瓶颈时，去查看业务逻辑是否存在可以异步处理的耗时操作，如果存在的话便可以引入消息队
列来解决。否则盲目的使用消息队列可能会增加维护和开发的成本却无法得到可观的性能提升
，那就得不偿失了。

再举一个例子：
由于在高并发环境下，由于来不及同步处理，请求往往会发生堵塞，比如说，大量的insert，
update之类的请求同时到达MySQL，直接导致无数的行锁表锁，甚至最后请求会堆积过多，从
而触发too many connections错误。通过使用消息队列，我们可以异步处理请求，从而缓解
系统的压力。

一、消息队列的作用和优点

1.1 使用消息队列理由

当系统中出现“生产“和“消费“的速度或稳定性等因素不一致的时候，就需要消息队列，作为
抽象层，弥合双方的差异。“ 消息 ”是在两台计算机间传送的数据单位。消息可以非常简单
例如只包含文本字符串；也可以更复杂，可能包含嵌入对象。消息被发送到队列中，“ 消息
队列 ”是在消息的传输过程中保存消息的容器 。
举例：

• 业务系统触发短信发送申请，但短信发送模块速度跟不上，需要将来不及处理的消息暂存一下，
  缓冲压力。就可以把短信发送申请丢到消息队列，直接返回用户成功，短信发送模块再可以慢慢
  去消息队列中取消息进行处理。
• 调远程系统下订单成本较高，且因为网络等因素，不稳定，攒一批一起发送。
• 任务处理类的系统，先把用户发起的任务请求接收过来存到消息队列中，然后后端开启多个
  应用程序从队列中取任务进行处理。

1.2 使用消息队列好处

• 提高系统响应速度
  使用了消息队列，生产者一方，把消息往队列里一扔，就可以立马返回，响应用户了。
  无需等待处理结果。
  处理结果可以让用户稍后自己来取，如医院取化验单。也可以让生产者订阅（如：留下手机号码
  或让生产者实现listener接口、加入监听队列），有结果了通知。获得约定将结果放在某处，无
  需通知。
• 提高系统稳定性
  考虑电商系统下订单，发送数据给生产系统的情况。电商系统和生产系统之间的网络有可能掉线，
  生产系统可能会因维护等原因暂停服务。如果不使用消息队列，电商系统数据发布出去，顾客无
  法下单，影响业务开展。两个系统间不应该如此紧密耦合。应该通过消息队列解耦。同时让系统
  更健壮、稳定。

二、消息队列应用场景

其实消息队列在很多方面的可以使用，总结下来：

• 异步处理：例如短信通知、终端状态推送、App推送、用户注册等
• 数据同步：业务数据推送同步
• 重试补偿：记账失败重试
• 系统解耦：通讯上下行、终端异常监控、分布式事件中心
• 流量消峰：秒杀场景下的下单处理
• 发布订阅：HSF的服务状态变化通知、分布式事件中心
• 高并发缓冲：日志服务、监控上报

2.1 异步处理

场景说明：
用户注册后，需要发注册邮件和注册短信。传统的做法有两种 1.串行的方式；2.并行方式

• 串行方式
  将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。
  以上三个任务全部完成后，返回给客户端。
  
• 并行方式
  将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，
  返回给客户端。与串行的差别是，并行的方式可以提高处理的时间。
  
  假设三个业务节点每个使用50毫秒钟，不考虑网络等其他开销，则串行方式的时间是150毫秒，
  并行的时间可能是100毫秒。
  因为CPU在单位时间内处理的请求数是一定的，假设CPU1秒内吞吐量是100次。则串行方式1秒
  内CPU可处理的请求量是7次（1000/150）。并行方式处理的请求量是10次（1000/100）。

问题引发：传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。
引入消息队列，将不是必须的业务逻辑，异步处理。改造后的架构如下：

按照以上约定，用户的响应时间相当于是注册信息写入数据库的时间，也就是50毫秒。注册邮件，
发送短信写入消息队列后，直接返回，因此写入消息队列的速度很快，基本可以忽略，因此用户的
响应时间可能是50毫秒。因此架构改变后，系统的吞吐量提高到每秒20 QPS。比串行提高了3倍，
比并行提高了两倍。

2.2 系统解耦

场景说明：
用户下单后，订单系统需要通知库存系统。传统的做法是，订单系统调用库存系统的接口。
如下图

传统模式的缺点：

• 假如库存系统无法访问，则订单减库存将失败，从而导致订单失败
• 订单系统与库存系统耦合

问题解决方案：

• 订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单
  下单成功。
• 库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，
  进行库存操作。
• 在下单时库存系统不能正常使用。也不影响正常下单，因为下单后，订单系统写入消息队
  列就不再关心其他的后续操作了。实现订单系统与库存系统的应用解耦。

2.3 流量削峰

流量削锋也是消息队列中的常用场景，一般在秒杀或团抢活动中使用广泛
应用场景：
秒杀活动，一般会因为流量过大，导致流量暴增，应用挂掉。为解决这个问题，一般需要在应
用前端加入消息队列。

• 可以控制活动的人数
• 可以缓解短时间内高流量压垮应用

• 用户的请求，服务器接收后，首先写入消息队列。假如消息队列长度超过最大数量，则直接
  抛弃用户请求或跳转到错误页面。
• 秒杀业务根据消息队列中的请求信息，再做后续处理。

2.4 日志处理

日志处理是指将消息队列用在日志处理中，比如Kafka的应用，解决大量日志传输的问题。
架构简化如下：

• 日志采集客户端，负责日志数据采集，定时写受写入Kafka队列
• Kafka消息队列，负责日志数据的接收，存储和转发
• 日志处理应用：订阅并消费kafka队列中的日志数据

举例：新浪kafka日志处理

• Kafka：接收用户日志的消息队列
• Logstash：做日志解析，统一成JSON输出给Elasticsearch
• Elasticsearch：实时日志分析服务的核心技术，一个schemaless，实时的数据存储服务，
  通过index组织数据，兼具强大的搜索和统计功能
• Kibana：基于Elasticsearch的数据可视化组件，超强的数据可视化能力是众多公司选择
  ELK stack的重要原因

2.4 消息通讯

消息通讯是指，消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯。
比如实现点对点消息队列，或者聊天室等。

• 点对点通讯
  
  客户端A和客户端B使用同一队列，进行消息通讯。
• 聊天室通讯
  
  客户端A，客户端B，客户端N订阅同一主题，进行消息发布和接收。实现类似聊天室效果。
  以上实际是消息队列的两种消息模式，点对点或发布订阅模式。

三、消息中间件实际使用实例

3.1 电商系统

消息队列采用高可用，可持久化的消息中间件。比如Active MQ，Rabbit MQ，Rocket Mq。

• 应用将主干逻辑处理完成后，写入消息队列。消息发送是否成功可以开启消息的确认模式。
  （消息队列返回消息接收成功状态后，应用再返回，这样保障消息的完整性）
• 扩展流程（发短信，配送处理）订阅队列消息。采用推或拉的方式获取消息并处理。
• 消息将应用解耦的同时，带来了数据一致性问题，可以采用最终一致性方式解决。
  比如主数据写入数据库，扩展应用根据消息队列，并结合数据库方式实现基于消息队列的后
  续处理。

3.2 日志采集系统

分为Zookeeper注册中心，日志收集客户端，Kafka集群和Storm集群（OtherApp）四部分组成。

• Zookeeper注册中心，提出负载均衡和地址查找服务
• 日志收集客户端，用于采集应用系统的日志，并将数据推送到kafka队列
• Kafka集群：接收，路由，存储，转发等消息处理
• Storm集群：与OtherApp处于同一级别，采用拉的方式消费队列中的数据

参考文章：
https://blog.csdn.net/seven__________7/article/details/70225830