分布式消息队列（MQ）应用场景

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

  传统模式的缺点：假如库存系统无法访问，则订单减库存将失败，从而导致订单失败，订单系统与库存系统耦合
  
  如何解决以上问题呢？引入应用消息队列后的方案。

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

• 削峰填谷
  流量削锋也是消息队列中的常用场景，一般在秒杀或团抢活动中使用广泛。
  应用场景：秒杀活动，一般会因为流量过大，导致流量暴增，应用挂掉。为解决这个问题，一般需要在应用前端加入消息队列。
  a、可以控制活动的人数
  b、可以缓解短时间内高流量压垮应用
  用户的请求，服务器接收后，首先写入消息队列。假如消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面。
  秒杀业务根据消息队列中的请求信息，再做后续处理
  

• 异步化缓冲
  场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种 1.串行的方式；2.并行方式
  a、串行方式：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户端。
  

  b、并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间
  

  假设三个业务节点每个使用50毫秒钟，不考虑网络等其他开销，则串行方式的时间是150毫秒，并行的时间可能是100毫秒。
  因为CPU在单位时间内处理的请求数是一定的，假设CPU1秒内吞吐量是100次。则串行方式1秒内CPU可处理的请求量是7次（1000/150）。并行方式处理的请求量是10次（1000/100）
  小结：如以上案例描述，传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。如何解决这个问题呢？

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

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

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

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

  • 点对点通讯：

    客户端A和客户端B使用同一队列，进行消息通讯。
    

  • 聊天室通讯：

    客户端A，客户端B，客户端N订阅同一主题，进行消息发布和接收。实现类似聊天室效果。
    

分布式消息队列（MQ）应用思考点

• 生产端可靠性投递
• 消费端幂等
• 高可用
• 可靠性
• 低延迟
• 扩展性
• 堆积能力
• 等等…

分布式消息队列（MQ）技术选型

ActiveMQ

单机吞吐量：万级

topic数量对吞吐量的影响：

• 时效性：ms级
• 可用性：高，基于主从架构实现高可用性
• 消息可靠性：有较低的概率丢失数据
• 功能支持：MQ领域的功能极其完备
• 总结：
  　　非常成熟，功能强大，在早些年业内大量的公司以及项目中都有应用
  　　偶尔会有较低概率丢失消息
  　　主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用

RocketMQ

单机吞吐量：十万级

topic数量对吞吐量的影响：

• topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降。可支持大量topic是一大优势。
• 时效性：ms级
• 可用性：非常高，分布式架构
• 消息可靠性：经过参数优化配置，消息可以做到0丢失
• 功能支持：MQ功能较为完善，还是分布式的，扩展性好
• 总结：
  　　接口简单易用，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，社区维护还可以，可靠性和可用性都是ok的，还可以支撑大规模的topic数量，支持复杂MQ业务场景
  　　而且一个很大的优势在于，源码是java，我们可以自己阅读源码，定制自己公司的MQ，可以掌控
  　　社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些，然后接口这块不是按照标准JMS规范走的有些系统要迁移需要修改大量代码

RabbitMQ

单机吞吐量：万级

topic数量对吞吐量的影响：

• 时效性：微秒级，延时低是一大特点。
• 可用性：高，基于主从架构实现高可用性
• 消息可靠性：
• 功能支持：基于erlang开发，所以并发能力很强，性能极其好，延时很低
• 总结：　　
  　　erlang语言开发，性能极其好，延时很低；
  　　吞吐量到万级，MQ功能比较完备
  　　开源提供的管理界面非常棒，用起来很好用
  　　社区相对比较活跃，几乎每个月都发布几个版本分
  　　在国内一些互联网公司近几年用rabbitmq也比较多一些 但是问题也是显而易见的，RabbitMQ确实吞吐量会低一些，这是因为他做的实现机制比较重。
  　　erlang开发，很难去看懂源码，基本职能依赖于开源社区的快速维护和修复bug。

Kafka

单机吞吐量：十万级，最大的优点，就是吞吐量高。

topic数量都吞吐量的影响：

• topic从几十个到几百个的时候，吞吐量会大幅度下降。所以在同等机器下，kafka尽量保证topic数量不要过多。如果要支撑大规模topic，需要增加更多的机器资源
• 时效性：ms级
• 可用性：非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
• 消息可靠性：经过参数优化配置，消息可以做到0丢失
• 功能支持：功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用
• 总结：
  　　kafka的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展
  　　同时kafka最好是支撑较少的topic数量即可，保证其超高吞吐量
  　　kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略

消息队列选型策略

• ActiveMQ 项目起初大家都是用这个，后来使用越来越少，没有经过高并发的考验。
• RabbitMQ 底层实现是erlang，因为这个原因很少有人去研究它的源码，因此掌握它原理技术的人特别少，修复bug几乎要开源社区修复，不过开源，社区活跃度高，比较稳定
• RocketMQ 大型公司会去使用，Java编码 有专业人员研究源码，对他进行改进 优化，中小型公司不建议使用所以中小型公司最好的消息队列是使用RabbitMQ。
• 大数据日志采集Kafka是标准，绝对没问题。社区活跃度特别高