【总结】消息服务中间件（ActvieMQ）

1，使用消息中间件场景

   - 解耦和扩展性

      - 系统之间集成只需要基于消息队列的数据接口层，这允许系统各自独立的扩展或修改各自的实现，只需要确保遵守同样的接口约束

   - 异步通信/处理

      - 一些事务性很强，耗时久的请求，如下订单，注册发邮件等，接受请求后马上告诉用户后台已经接受到了请求并在处理请等待，前台不停的检查处理情况，防止了用户一直挂在当前页面，提升了交互体验

      - 有些请求伴随着很多后台的附加处理，比如：记录日志，发通知邮件，相关计算处理更新通知等，都可以通过发消息的方式处理，不影响用户请求的主流程

   - 处理突发高并发/高峰值的负载情况

      - 为这种少见的突发高并发/高峰值的负载情况花费大量的费用提升硬件性能是不值得了

      - 用消息队列作为一个缓冲承接用户请求，后台服务器按照自己处理的能力从消息队列拿任务进行处理，不至于让系统超出负荷而崩溃

   - 消息中间件需要确保

      - 可恢复性

      - 送达保证

         - 如何确保幂等性

         - 发送仅发送一次

      - 排序保证

      - 安全保证

2，ActiveMQ

   - 消息类型

      - TextMessage（文本消息）

      - MapMessage（映射消息）

      - BytesMessage（字节消息）

      - StreamMessage（流消息）

      - ObjectMessage（对象消息）

   - JMS可靠性机制

      - 确认JMS消息

      - 持久性

      - 优先级

      - 消息过期

      - 临时目的地

      - 持久订阅

      - 本地事务

   - JMS规范

      - 点对点域：QueueConnectionFactory，QueueConnection，Queue，QueueSession，QueueSender，QueueReceiver

      - 发布/订阅域：TopicConnectionFactory，TopicConnection，Topic ，Topic Session，TopicPublisher，TopicSubscriber

   - Broker监控

      - JMX

      - Web Console：Web监控后台

      - Advisory Message（通知消息）：允许你通过标准的JMS 消息来监控系统

      - Command Agent

         - XMPP 是一种基于XML的即时通信协议

         - 启用了Command Agent 的broker 上会有一个来自Command Agent的连接，ActiveMQ 提供了ActiveMQ messages和XMPP之间的双向桥接

            - 如果客户加入了一个聊天室，那么这个聊天室的名字会被映射到一个JMS topic

            - 尝试在聊天室内发送消息会导致一个JMS消息被发送到这个topic

            - 呆在一个聊天室中意味着这将保持一个对相应JMS topic 的订阅。因此发送到这个topic 的JMS 消息也会被发送到聊天室

      - Visualization Plugin

   - 应用协议

      - MQTT

         - （Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议

         - 该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议

         - MQTT协议是为大量计算能力有限，且工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议，它具有以下主要的几项特性

            - 使用发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合

            - 对负载内容屏蔽的消息传输

            - 使用TCP/IP提供网络连接

            - 有三种消息发布服务质量

               - “至多一次”，消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送

               - “至少一次”，确保消息到达，但消息重复可能会发生

               - “只有一次”，确保消息到达一次。这一级别可用于如下情况，在计费系统中，消息重复或丢失会导致不正确的结果

            - 小型传输，开销很小（固定长度的头部是 2 字节），协议交换最小化，以降低网络流量

            - 使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制

      - WS

      - Openwire：ActiveMQ自身设计的协议

      - Stomp

         -  Streaming Text Orientated Message Protocol，是流文本定向消息协议，是一种为MOM (Message Oriented Middleware，面向消息的中间件)设计的简单文本协议

         -  它提供了一个可互操作的连接格式，允许STOMP客户端与任意STOMP消息代理(Broker)进行交互，类似于OpenWire(一种二进制协议)

         -  STOMP协议工作于TCP协议之上

      - AMQP

         - 即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计

         -  一套确定的消息交换功能，也就是“高级消息交换协议模型”。AMQP模型包括一套用于路由和存储消息的功能模块，以及一套在这些模块之间交换消息的规则

   - 传输（Transport）协议

      - VM

         - VM transport 允许在VM 内部通信，从而避免了网络传输的开销

         - 采用的连接不是socket 连接，而是直接地方法调用

      - TCP

         - 以包交换进行主机通信的可靠的传输协议

      - SSL

         - SSL协议在TCP协议的基础上传输加密的安全数据

         - 它使用一组密钥（公钥和私钥）确保传输通道的安全性

      - Failover

         - Failover Transport 是一种重新连接的机制，它工作于其它transport 的上层，用于建立可靠的传输 

         - 它的配置语法允许制定任意多个复合的URI。Failover transport 会自动选择其中的一个URI 来尝试建立连接。如果没有成功，那么会选择一个其它的URI来建立一个新的连接

      - Peer

      - Discovery

         - Discovery transport 是可靠的tranport。它使用Discovery transport来定位用来连接的URI列表

      - Zeroconf

      - HTTP

         - 防火墙仅允许使用一些基础的协议访问。这是HTTP协议出现的原因

         - ActiveMQ实现了HTTP传输连接器，能够提供基于xml的消息传输。可以使用HTTP协议绕过防火墙

      - UDP

         -UDP是一种无连接的协议，不能保证数据报的完整传输

         -UDP不能保证数据包的有序接收，也不能保证数据包的重复发送

      - Multicast

   - 持久化

      - Kaha Message Store

         - 一种基于文件的消息存储，并且联合Journal事务，可稳定存储消息并且恢复消息

         - KahaDB消息存储使用事务Log作为它的索引，并且对所有的Destination仅仅使用一个索引文件，该索引文件是事务日志文件组中消息ID的索引

         - KahaDB消息存储联合使用快速的事务处理：Journal以及数据日志文件，该日志文件是消息ID的索引，并且在内存中缓存消息

      - AMQ Persistence

         - 类似于KahaDB。它使用了journal事务来确保稳定的持久、恢复、高性能的索引

         - 主要用于大数据(消息)量的存储

         - 对每个索引文件，有两个单独的文件；一个用于每个Destination

         - 如果每个Broker有上千个Queue，此时使用AMQ消息存储是不合适的，并且恢复数据也很慢，因为所有的索引文件需要rebuid，需要Broker扫描所有的Data logs去再次构建索引

            - Data Logs: 作为消息journal

            - Cache: 在消息写入data log后，在内存中保持消息用于快速恢复

            - Reference Store:在journal保存消息的引用，按照消息ID索引

      - JDBC Persistence

         - 可以将消息存储到数据库中，例如：Mysql、SQL Server、Oracle、DB2

      - LevelDB

         - 这种文件系统是从ActiveMQ5.8之后引进的，它和KahaDB非常相似，也是基于文件的本地数据库储存形式，但是它提供比KahaDB更快的持久性

         - 与KahaDB不同的是，它不是使用传统的B-树来实现对日志数据的提前写，而是使用基于索引的LevelDB

   - 安全机制

      - Simple Authentication Plugin

      - JAAS Authentication Plugin

      - Custom Authentication Implementation

      - Authorization Plugin

   - 更多功能

      - Exclusive Consumer

         - ActiveMQ 从4.x 版本起开始支持Exclusive Consumer （或者说Exclusive Queues）。Broker 会从多个consumers 中挑选一个consumer 来处理queue 中所有的消息，从而保证了消息的有序处理

      - Message Groups

         - Exclusive Consumer 功能的增强。逻辑上，Message Groups 可以看成是一种并发的Exclusive Consumer

         - 跟所有的消息都由唯一的consumer 处理不同，JMS 消息属性JMSXGroupID 被用来区分message group

      - JMS Selectors

         - JMS Selectors 用于在订阅中，基于消息属性对消息进行过滤

      - Pending Message Limit Strategy

         - ActiveMQ 通过prefetch 机制来提高性能，这意味这客户端的内存里可能会缓存一定数量的消息

         - 缓存消息的数量由prefetch limit 来控制

         - 当某个consumer 的prefetch buffer 已经达到上限，那么broker 不会再向consumer分发消息，直到consumer 向broker 发送消息的确认

      - Composite Destinations

         - ActiveMQ 支持composite destinations。它允许用一个虚拟的destination 代表多个destinations

         - 例如你可以通过composite destinations 在一个操作中同时向12 个queue 发送消息。在composite destinations 中，多个destination之间采用","分割

      - Mirrored Queues

      - Wildcards

         - Wildcards 用来支持联合的名字分层体系（federated name hierarchies）

      - Async Sends

         - ActiveMQ 支持以同步（sync）方式或者异步（async）方式向broker 发送消息

         - ActiveMQ 缺省使用异步传输方式

         - 按照JMS 规范，当在事务外发送持久化消息的时候，ActiveMQ 会强制使用同步发送方式，保证了broker 已经成功地将消息持久化，而且不会丢失。但是这样作也严重地影响了性能

      - Dispatch Policies

         - ActiveMQ 的缺省参数是针对处理大量消息时的高性能和高吞吐量而设置的

      - Message Cursors

      - Optimized Acknowledgement

      - Producer Flow Control

      - Message Transformtion

3，高可用（HA）和集群

   - 高可用（HA，防单点故障）：Master-Slave（主从）部署方式

      - Shared filesystem Master-Slave主从

         - 通过共享存储目录来实现master和slave的热备

         - ActiveMQ应用都在不断地获取共享目录的控制权，哪个应用抢到了控制权，它就成为master

         - 性能较好

      - Shared database Master-Slave主从

         - 通过共享数据库来实现master和slave的热备

         - 性能比共享文件方式差

      - Replicated LevelDB Store方式

         - ActiveMQ5.9以后才新增的特性

         - 使用ZooKeeper协调选择一个node作为master，被选择的master broker node开启并接受客户端连接

         - 其他node转入slave模式，连接master并同步他们的存储状态。slave不接受客户端连接。所有的存储操作都将被复制到连接至Master的slaves

         - 性能较好

   - Broker集群（负载均衡）

         - Static Broker-Cluster部署

         - Dynamic Broker-Cluster部署