如何选型

• 关于性能
  • 吞吐量
  • 延迟
• 关于选型
  • 场景
  • 指标
• 关于开发
  • 抽象
  • 封装

• 关于维护

  • 稳定性
  • 高可用

    系统间通信方式

    

• 各个方式的不足

  • 文件：明显不方便、不及时
  • socket：使用麻烦，多数情况下不如RPC
  • 数据库：不实时，但经常有人拿数据库模拟消息队列
  • RPC：调用关系复杂，同步处理，压力大的时候无法缓冲

• 期望方式

  • 异步消息通信
  • 简化依赖关系
  • 在压力大时可缓冲，类似线程池里的Queue
  • 保障消息可靠，甚至顺序

    从队列到消息服务

    消息服务

    

    四大优势

• 异步通信：异步通信减少线程等待，特别是处理批量等大事务、耗时操作

• 通信可靠：提供多种消息模式、服务质量、顺序保障等
• 系统解耦：系统间不直接调用，降低依赖，特别是一方不在线也能保证通信最终完成

• 削峰填谷：压力大的时候，缓冲部分消息，类似于背压处理

  DLQ

• DeadLetterQueue死信队列

• 重试N次依然失败的消息、执行超时的消息等都会被丢到DLQ

• 是MQ为了保证消息可靠的一种机制，为了不影响线上服务和资源，后续可人工介入处理

  Camel

• MQ版本升级，自动迁移消息

  RoaringBitmap

• 消息去重

  消息处理模式与消息协议

  消息处理模式

  PTP

• PointToPoint

• 点对点模式

• 对应于Queue模式

  PubSub

• PublishSubscribe

• 发布订阅模式
• 对应于Topic模式

消息处理保障

QoS

• AtMostOnce，至多一次，消息可能丢失但不会重复发送
• AtLeastOnce，至少一次，消息不会丢失，但可能会重复（推荐使用此模式，业务上去重RoaringBitmap）

• ExactlyOnce，精确一次，每条信息肯定会被传输且仅传输一次

  事务

• 通过确认机制实现消息的事务性

• 可以被事务管理器管理，甚至还可以支持XA

  有序性

• 同一个Topic/Queue的消息，保障按顺序投递

• 如果做了消息分区，或者批量预取之类的操作，可能就没有顺序了

  消息协议

  

  JMS

• JavaMessageService

• 关注于应用层的API协议，类似JDBC
• Message结构
  • Body
  • Header
  • Property（自定义的头信息）
• Messaging行为
  • PTP&PubSub
  • 持久化
  • 事务机制
  • 确认机制
  • 临时机制
    • TemporaryQueue
    • TemporaryTopic

• 

  消息队列的通用结构

  

  开源中间件

• 第一代主要不支持堆集，内存满了系统就崩溃了

• 第二代基于磁盘和堆集以及WAL，只要磁盘够，支持无限的消息
• 第三代计算和存储分离，相互不受影响

ActiveMQ

介绍

• 高可靠，事务性
• 后来与HornetQ合并，新的消息队列叫Artemis，目前是ActiveMQ的子项目

• 功能最全的消息队列

  主要功能

• 多种语言和协议编写客户端

• 完全支持JMS1.1和J2EE1.4规范
  • 持久化
  • XA消息
  • 事务
• spring生态完善
• 支持通过JDBC和journal提供高速的消息持久化

• 高性能集群模式

  使用场景

• 所有需要使用消息队列的地方

• 订单处理、消息通知、服务降级等
• 特别的是因为他是纯java实现，支持嵌入到应用系统