黄埔班第40节：消息队列应用实战-1

1、分布式消息队列应用场景分析

ActiveMQ、RabbitMQ、RocketMQ、zeroMQ、kafka

• RabbitMQ
• kafka

消息队列的应用场景分析

面试问题：MQ为我们解决了什么问题?

异步缓冲

有一些业务是可以通过异步来操作的，只要做到最终一致性而不是强一致性，就可以通过MQ来做。

场景举例：

用户在平台上注册了账号，会发邮件和短信通知

• 串行处理（同步）

  

• 并行处理

  

串行和并行都是需要等待一个确认返回的，才知道整个过程是否完成，还是强一致性的解决方案，如果发短信或者发邮件的服务出现问题，整个服务就无法保证正常了

消息队列解决这个问题

正常情况下只要把消息发送到MQ，业务就完成了，也是服务解耦的体现。

服务解耦

• 服务强依赖：将服务解耦后通过Dubbo或SpringCloud进行服务的直连和访问都是强依赖，等待对方服务的结果返回。

• 服务弱依赖：服务间的消息通过一种中间件来进行缓存，然后再使用

  • 不代表弱依赖就可以失败
  • 一定要保证上游消息的可靠投递

场景描述

订单系统—-库存系统（进行库存的设置）

• 强依赖模式：

  1、假如库存系统无法访问，订单扣减库存就会失败，导致数据不一致

  2、如果你通过启动线程来保证时效，不能保证这个线程成功执行，假如扣减库存失败

• 通过消息队列解决（弱依赖）

  订单将信息写入—>MQ（只需要保证写入是100%的可靠）

  库存系统读取—>MQ

通过消息队列解决问题，所有的数据都是一个弱一致性的过程，只要能确保某个节点或时间点单位数据最终一致即可

前端100->分布式锁控制购买（1,2,3,5,6）MQ->库存

削峰填谷

• 当我们的下游服务处理不过来的时候，就可以将这些消息缓存在一个地方（MQ），逐步处理，完全看下游的消费能力
• 解决并发量过大的时候的数据的处理
• 将短暂一段时间的业务挤压在后面非业务高峰期逐步执行完，就是削峰填谷的过程

场景说明：秒杀

秒杀应该要用分布式锁，进行阻塞减库存

消息通讯

• 点对点的消息通讯

  A只能发给B，相当于私聊（Redis里的list）

• 发布订阅的方式

  A可以发布给所有订阅了这个消息的用户，相当于聊天室（Redis pub/sub，使用Redis的发布/订阅，也可以实现）

2、分布式消息队列应用需要思考的问题

• 消息发布端的可靠性投递
  • 如果业务和钱相关，这个消息就一定不能丢失
  • 需要做到消息生产端的100%投递，就一定要有消息的补偿机制
• 消费端的幂等
  • 生产端做到可靠性投递，就可能会重复投递消息
  • 消费端消费了两次或多次同一个数据，就可能会导致数据不一致
  • 随意无论消费端重复消费多少次，都应该只能有一个结果
• MQ本身需要考虑的内容
  • HA：高可用
  • 低延迟：虽然MQ是用于弱依赖，也不能因为MQ导致延迟过大
  • 可靠性：数据是否完整
  • 堆积能力：这个MQ是否能够扛下你的业务量级，堆积消息的能力（相当于双11的快递爆仓）
  • 扩展性：是否能够支持横向扩展，扩展节点（无感知），扩容你的堆积能力

3、主流消息队列

业界流行的消息队列

ActiveMQ

• 比较经典，时间比较久的一款MQ
• apache旗下的

RabbitMQ

• Rabbit科技公司开发的MQ
• 使用erlang开发的，erlang有着和原生socket一样的延迟，性能非常高

RocketMQ

• alibaba开源的一款MQ
• 也交给apache，也是Java开发的

Kafka

• 主要关注的是高吞吐量（低延迟）和海量数据存储（堆积能力），适合大数据场景
• kafka是apache开发
• 用scala和Java编写

如何进行技术选型

需要关注的地方

1、各个MQ的性能特点，优缺点，相应的业务场景

• 比如ActiveMQ适用于传统公司，不太适合高并发的、海量的业务数据场景
• 比如RabbitMQ的横向扩展能力就不是非常强

2、集群的架构模式：分布式、可扩展、高可用、可维护性等

3、综合成本、人员学习成本

• 如果对消息的可靠性和依赖不是特别高，就可以使用kafka
• kafka可以在很廉价的机器上有着很高的吞吐和性能表现

4、未来的规划和数据兼容的方向

4、ActiveMQ集群架构原理分析

JMS规范（Java Message Service），JMS只是接口，没有给予实现，天上飞的理论，都有落地的实现。

组成元素

• Producer：消息生产者
• Consumer：消息消费者
• PTP：点对点模型（point to point）
• Pub/Sub：发布/订阅模型
• Queue：消息队列
• Topic：主题目标
• ConnectionFactory：JMS创建链接的工厂
• Connection：JMS客户端到JMS Provider链接
• Destination：消息的目的地（dest），指：队列Queue或者主题Topic
• Session：会话

JMS编码架构：

消息投递模式

• PTP：点对点模型（一方发送只有一方接收）
• Pub/Sub：发布/订阅模型（一方发送多方接收）

ActiveMQ各项指标

• 服务性能：大数据高并发场景下力不从心
• 数据存储：默认是用kahadb存储（索引文件形式），也可以使用google leveldb（内存数据存储）或者使用MySQL，Oracle进行消息存储
• 集群架构：ActiveMQ可以和zookeeper构建主备集群模式，或者多套主备搭建集群

ActiveMQ的集群结构

Master-Slave 主备模式

zookeeper的作用就是当master宕机，进行及时切换到slave

主备模式是无法满足分布式的

Network 分布式

• 这种方案要有两套或多套Master-Slave集群进行搭建
• 多套集群直接相关交叉配置
• 这种方法可能会导致资源浪费