ActiveMQ学习笔记（五）传输协议/持久化

1. ActiveMQ 支持的协议有 TCP 、 UDP、NIO、SSL、HTTP(S) 、VM
   2.其中配置了Transport Connector 的文件在activeMQ安装目录的conf/activemq.xml 中的标签内
   如图：
   

TCP
1.默认是使用 openwire 也就是 tcp 连接，默认的Broker 配置，TCP 的Client 监听端口 61616
2.在网络上传输数据，必须序列化数据，消息是通过一个write protocol 来序列化为字节流。默认情况 ActiveMQ 会把 wire protocol 叫做 Open Wire ，它的目的是促使网络上的效 率和数据快速交互 。
3.TCP连接的URI形式如：tcp：//localhost：port？key=value&key=value
4.TCP传输的优点：
可靠性高，稳定性强
高效性：字节流方式传递，效率高
有效性，可用性：应用广泛，支持任何平台
官方文档：http://activemq.apache.org/tcp-transport-reference
NIO
协议为ActiveMQ 提供更好的性能，NIO更侧重底层的访问操作。允许开发人员对同一资源可有更多的client调用和服务端有更多的负载
适合NIO 使用的场景：
1.当有大量的Client 连接到Broker上，使用NIO 比使用 tcp 需要更少的线程数量，所以使用 NIO
2.可能对于 Broker 有一个很迟钝的网络传输，NIO 的性能高于 TCP
连接形式： nio://hostname:port?key=value

各种协议对比：http://activemq.apache.org/configuring-version-5-transports.html

传输协议之NIO

1.修改配置文件


而使用 NIO 协议，代码修改量极小，只需同时将消息生产者和消费者的 URL 修 改即可，记得生产者消费者都需要修改：

NIO加强

URI 格式以 nio 开头，表示这个端口使用 tcp 协议为基础的NIO 网络 IO 模 型，但这样设置让它只支持 tcp 、 nio 的连接协议。如何让它支持多种协议？
使用 ： auto+nio+ssl
官网介绍 ：http://activemq.apache.org/auto
使用 auto 的方式就相当于四合一协议 ： STOMP AMQP MQTT TCP
auto+nio:

消息存储和持久化

开启持久化

将MQ 收到的消息存储到文件、硬盘、数据库 等、 则叫MQ 的持久化，这样即 使服务器宕机，消息在本地还是有，仍就可以访问到。
官方文档：http://activemq.apache.org/persistence
ActiveMQ 支持的消息持久化机制： 带赋值功能的 LeavelDB 、 KahaDB 、 AMQ 、 JDBC
AMQ
文件存储形式，写入快、易恢复 默认 32M ，在 ActiveMQ 5.3 之后不再适用
KahaDB
5.4 之后基于日志文件的持久化插件，默认持久化插件，提高了性能和恢复能力
属性配置参考： http://activemq.apache.org/kahadb
它使用一个事务日志和 索引文件来存储所有的地址

db-<数字>.log 存储数据，一个存满会再次创建 db-2 db-3 …… ，当不会 有引用到数据文件的内容时，文件会被删除或归档
db.data 是一个BTree 索引，索引了消息数据记录的消息，是消息索引文 件，它作为索引指向了 db-.log 里的消息
一点题外话：就像mysql 数据库，新建一张表，就有这个表对应的 .MYD 文件，作为它的数据文件，就有一个 .MYI 作为索引文件。
db.free 存储空闲页 ID 有时会被清除
db.redo 当 KahaDB 消息存储在强制退出后启动，用于恢复 BTree 索引
lock 顾名思义就是锁
四类文件+一把锁 —> KahaDB

LeavelDB ：
希望作为以后的存储引擎，5.8 以后引进，也是基于文件的本地数 据存储形式，但是比 KahaDB 更快
它比KahaDB 更快的原因是它不使用BTree 索引，而是使用本身自带的 LeavelDB 索引

JDBC :
有一部分数据会真实的存储到数据库中
使用JDBC持久化的步骤：
1.修改配置文件，默认 kahaDB
修改前：

修改后：


true表明每次启动都回去创建数据表，一般是第一次启动的时候设置为true之后改成false 默认为true
2.在activemq 的lib 目录下添加 jdbc 的jar 包 (connector.jar 我使用5.1.41 版本)
3.修改配置文件 ： activemq.xml

4.ActiveMQ 启动后会自动在 mysql 的activemq 数据库下创建三张表：
activemq_msgs 、activemq_acks、activemq_lock
activemq_acks：用于存储订阅关系。如果是持久化Topic，订阅者和服务器的订阅 关系在这个表保存
activemq_lock：在集群环境中才有用，只有一个Broker可以获得消息，称为 Master Broker
activemq_msgs：用于存储消息，Queue和Topic都存储在这个表中

点对点类型中
消息是非持久化的，被保存在内存中
消息是持久化的，被保存在broker的相应的文件或数据库中
消息一旦被消费就从broker中删除

主题，订阅方式接受到的消息，会在 ACTIVEMQ_MSGS 存储消 息，即使MQ 服务器下线，并在 ACTIVEMQ_ACKS 中存储消费者信息 。activemq_msg中会存储被消费的信息

坑：

JDBC 改进： 加入高速缓存机制 Journal

高速缓存在 activemq.xml 中的配置：

持久化消息是指： MQ 所在的服务器down 了消息也不会丢失
持久化机制演化过程： 从最初的AMQ Message Store 方案到 ActiveMQ V4版本推出的High performance journal （高性能事务）附件，并且同步推出了关系型数据库的 存储方案， ActiveMQ 5.3 版本有推出了KahaDB 的支持，（也是5.4之后的默 认持久化方案），后来ActiveMQ 从5.8开始支持LevelDB ，现在5.9 提供了 Zookeeper + LevelDB 的集群化方案。
ActiveMQ 消息持久化机制有：
AMQ 基于日志文件
KahaDB 基于日志文件，5.4 之后的默认持久化 J
DBC 基于第三方数据库
LevelDB ： 基于文件的本地数据库存储，从5.8 之后推出了LevelDB 性能高 于 KahaDB
ReplicatedLevelDB Store 从5.8之后提供了基于LevelDB 和Zookeeper 的 数据复制方式，用于Master-slave方式的首数据复制选方案
但是无论使用哪种持久化方式，消息的存储逻辑都一样

多节点集群

流程：

三种集群方式对比：
1.基于sharedFileSystem共享文件系统（KahaDB）
2.基于JDBC
3.基于可复制的levelDB

Zookeeper+Replicated LevelDB Store
原理图：

使用Zookeeper集群注册所有的ActiveMQ Broker但只有其中的一个Broker可以提供服务它将被视为Master，其中的Broker处于待机状态被视为Slave。
如果Master因故障而不能提供Zookeeper会从Slave中选出一个Broker充当Master。Slave连接Master并同步他们的存储状态，Slave不接受客户端连接。所有的存储操作都将被复制到连接至Master的Slaves。
如果Master宕机得到了最新更新的Slave会成为Master。故障节点在恢复后会重新加入到集群中并连接Master进入Slava模式。

所有需要同步的消息操作都将等待存储状态被复制到其他法定节点的操作完成才能完成。
所以，如果你配置了replicas=3，那么法定大小是（3/2）+1=2。Master将会存储并更新然后等待（2-1）=1个Slave存储和更新完成，才汇报success。
有一个node要作为观察者存在。当一个新的Master被选中，你至少保障一个法定node在线以能够找到拥有最新状态的node。这个node才可以成为新的Master.
因此，推荐运行至少3个replica nodes以防止一个node失败后服务中断。

集群搭建： 新建 /mq_cluster 将原始的解压文件复制三个，修改端口 (jetty.xml)

增加IP 到域名的映射（/etc/hosts 文件）

修改 为相同的borkername

改为 replica levelDB（3个都配，这里列举一个）


改端口:
02 节点: 61617 03 节点 :61618
想要启动replica leavel DB 必须先启动所有的zookeper 服务， zookeper 的单机伪节点安装这里不细说了，主要说zookeper 复制三份后改配 置文件，并让之自动生成 myid 文件，并将zk的端口改为之前表格中对应的端 口 。这是conf 下的配置文件

其具体配置为：

连接zk 的一个客户端

连接之后：
查看我的节点状态
get /activemq/leveldb‐stores/00000000003

此次验证表明 00000003 的节点状态是master （即为63631 的那个mq 服 务） 而其余的（00000004 00000005） activemq 的节点是 slave

测试集群可用性：

修改代码

public static final String ACTIVEMQ_URL = "failover:(tcp://192.168.17.3:6 1616,tcp://192.168.17.3:61617, 
tcp://192.168.17.3:61618)?randomize=false";
 public static final String QUEUE_NAME = "queue_cluster";

测试：

测试通过连接上集群的 61616 MQ服务收到三条消息：

消息接收

MQ 服务也将消息出队

此时真正的可用性测试：杀死 8061 端口的进程

刷新页面后 8161 端口宕掉，但是 8162 端口又激活了