分布式消息队列MQ 认知

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

1）服务解耦：现有耦合在一起的模块进行重新的设计，设计成可以独立部署的多个模块
2）削峰填谷，把流量的高峰削下来，先把消息存到一个队列里，后面慢慢消费，常应用双十11秒杀等
3）异步缓存：异步缓存将缓存操作的开销由客户端转移到worker。客户端读数据的同时，缓存数据块的任务被交给worker在后台异步来处理

MQ应用的思考点

• 生产端可靠性投递：特别是金融业务，要做到生产端100%可靠性投递，消息发出去和数据库要保障原子性
  常见的解决方案有两种
  1.消息落库，对消息状态进行打标
  2.消息的延迟投递，做二次确认，回调检查
• 消费端幂等：可能会出现重复消费问题，消费端要做幂等性验证，不能让消息消费多次
• 高可用：服务挂机
• 可靠性：例如，kafak副本，保证消息丢失的问题
• 低延迟：
• 堆积能力：
• 扩展性
  

如何进行技术选型？

• 各个MQ的性能、优缺点、相应的业务场景；
• 集群架构模式：分布式、可扩展、高可用、可维护性
• 综合成本问题，集群规模，人员成本
• 未来的方向、规划、思考

主流分布式MQ

• ActiveMQ：一款经典而又古老的MQ，其功能强大，是Apache*开源的一款中间件，在中小型企业以及企业级的管理应用广泛；
• RabbitMQ：大的需求可以满足，横向扩展能力不是特别好；可扩展性不是很好，高可用行和可维护性很好；
• Kafka：扩展性强，高可用性具备、可维护性稍微差点，主要关注数据的高吞吐量，还有海量数据的转储工作
• RocketMQ：最初由阿里巴巴开源，后捐给Apache维护，扩展性强、高可用性具备，可维护性稍微差点，支持很多功能，丰富的消息拉取，消费机制以及重复消费机制等，目前开始支持分布式事务

ActiveMQ消息中间件集群架构与原理解析

认识JMS

JMS（java Message Service）规范，也就是java消息服务，定义了中间件的接口规范。
JMS只是接口，并没有给予实现，实现JMS接口的消息中间件称为 “JMS Provider”。目前知名的开源 MOM （Message Oriented Middleware，也就是消息中间件）系统包括Apache的ActiveMQ、RocketMQ、Kafka，以及RabbitMQ，可以说他们都 “基本遵循” 或 “参考” JMS规范，都有自己的特点和优势。

ActiveMQ消息投递模式

• 点对点：生产者向队列投递一条消息，只有一个消费者呢能监听到这条消息（PTP），下图所示

• 发布订阅：生产者向队列投递一条消息，所有监听到该队列的消费者都能监听到这条消息（P/S）,如下图所示
  

ActiveMQ 指标

衡量一个MOM ，主要从三个维度，服务性能、存储堆积能力、可扩展性。

• 服务性能：性能一般，在早起传统行业比较流行，但现如今高并发、大数据的业务场景，力不从心！
• 数据存储：默认采用kahadb存储（索引文件形式存储），也可以使用高性能的 Google level（内存数据存储），或 MySQL进程消息存储（关系型数据库存储）。
• 集群架构：ActiveMQ与zookeeper进行构建，主备集群模型，多套的主备模型直接采用network的方式构建分布式集群。

ActiveMQ集群架构模式

• Master-Slave：主从方式

• Master-Slave集群模型的关键点

1. 上图，绿色的为主节点，灰色为备份节点，这两个节点都是运行的状态的。
2. zookeeper的作用是为了当绿色的主节点宕机时，进行及时切换到备份的灰色节点上去，使其进行主从角色互换，用于实现高可用性。
3. 这种集群模型的缺点，就是不能做到分布式的topic、queue，当消息量巨大时，我们的MQ集群压力过大，没办法满足分布式的需求。

• Network：网络通信方式，这种方式解决了消息存储和故障转移、broker切换的问题，可以理解为消息会进行均衡
  

• Network集群模式的关键点

  需要2套或多套Master-Slave集群模型才可以搞定，部署比较麻烦，直接交叉配置，相互能够感知彼此的存在，配置例如：

虽然解决了分布式消息队列难题，但造成很多问题，例如资源浪费，并且也可能达不到所预期的效果

架构思考

综上所述，本人不推荐使用ActiveMQ,具体选型看需求需要结合每种MQ的优缺点

下期分享RabbitMQ¹

---

1. 关注下期分享 RabbitMQ ↩︎