【总结】消息服务中间件（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部署