1 工程编译打包:

进入工程根目录,执行命令:

  1. mvn clean package -Dmaven.test.skip

例如将TubeMQ源码包放在E盘根目录,按照如下方式执行上述命令,当各个子目录都编译成功时工程编译完成:

部署示例 - 图1

大家也可以进入各个子目录进行单独编译,编译过程与普通的工程编译处理过程一致。

2 部署服务端:

如上例子,进入..\InLong\inlong-tubemq\tubemq-server\target目录,服务侧的相关内容如下,其中apache-inlong-tubemq-server-0.9.0-incubating-SNAPSHOT-bin.tar.gz为完整的服务端安装包,里面包括执行脚本,配置文件,依赖包,以及前端的源码;apache-inlong-tubemq-server-0.9.0-incubating-SNAPSHOT.jar为服务端处理逻辑包,包含于完整工程安装包的lib里,单独提出是考虑到日常变更升级时改动点多在服务器处理逻辑上,升级的时候只需要单独替换该jar包即可:

部署示例 - 图2

这里我们是全新安装,将上述完整的工程安装包部署到待安装机器上,我们这里是放置在/data/inlong目录下:

部署示例 - 图3

3 配置系统:

服务包里打包了3种角色:Master、Broker、Tools,业务使用时可以将Master和Broker放置在一起,也可以单独分开不同机器放置,依照业务对机器的规划进行处理。我们通过如下3台机器搭建一个完整的有2台Master的生产、消费环境:

机器所属角色TCP端口TLS端口WEB端口备注
9.23.27.24Master809981998080元数据存储在/stage/meta_data
Broker812381248081消息储存在/stage/msg_data
ZooKeeper2181Offset储存在根目录/tubemq
9.23.28.24Master809981998080元数据存储在 /stage/meta_data
Broker812381248081消息储存在/stage/msg_data
9.23.27.160Producer
Consumer

部署Master时需要注意:

  1. 部署Master的机器,Master集群可以部署1台、2台或者3台:如果要保证高可靠建议3台(任意坏1台Master对外仍然可读写配置及接入新的生产或者消费),如果只需要保证一般情况2台(任意坏1台Master对外仍然可读配置及已接入的生产和消费不受影响),最低1台(坏1台Master对外配置不可读写及已接入的生产和消费不受影响);
  2. 在完成Master的规划后,对于配置Master的机器,需要将Master所在机器加入时间同步,同时Master各个机器的IP要在各个Master机器的/etc/hosts配置里进行设置,如:

部署示例 - 图4

以9.23.27.24和9.23.28.24为例,我们部署了Master和Broker两种角色,需要在/conf/master.ini,/resources/velocity.properties,/conf/broker.ini里进行如下配置,首先是9.23.27.24的配置:

部署示例 - 图5

然后是配置9.23.28.24:

部署示例 - 图6

要注意的是右上角的配置为Master的Web前台配置信息,需要根据Master的安装路径修改/resources/velocity.properties里的file.resource.loader.path信息。

4 运行节点

4.1 启动Master:

完成如上配置设置后,首先进入主备Master所在的TubeMQ环境的bin目录,进行服务启动操作:

部署示例 - 图7

我们首先启动9.23.27.24,然后启动9.23.28.24上的Master,如下打印可以表示主备Master都已启动成功并开启了对外服务端口:

部署示例 - 图8

访问Master的管控台(http://9.23.27.24:8080 ),点击页面可以查看到如下集群信息,则表示master已成功启动:

部署示例 - 图9

4.2 启动Broker:

启动Broker和启动master有些差别:Master负责管理整个TubeMQ集群,包括Broker节点运行管理以及节点上部署的Topic配置管理,还有生产和消费管理等,因此,实体的Broker启动前,首先要在Master上配置Broker元数据,增加Broker相关的管理信息,如下图示:

部署示例 - 图10

点击确认后形成一个草稿的Broker记录:

部署示例 - 图11

我们对该broker节点进行启动操作:

部署示例 - 图12

结果发现报错信息:

部署示例 - 图13

因为该broker目前还处在草稿状态Broker信息没有正式生效,我们回到Master管控台进行上线生效操作:

部署示例 - 图14

Master上所有的变更操作在点击确认的时候,都会弹出如上输入框,要求输入操作授权码。该信息由运维通过Master的配置文件master.ini的confModAuthToken字段进行定义:如果你知道这个集群的密码,你就可以进行该项操作,比如你是管理员,你是授权人员,或者你能登陆这个master的机器拿到这个密码,都认为你是有权操作该项功能:

部署示例 - 图15

然后我们再重启Broker:

部署示例 - 图16

部署示例 - 图17

查看Master管控台,broker已经注册成功:

部署示例 - 图18

5 数据生产和消费

5.1 配置及生效Topic:

配置Topic和配置Broker信息类似,都需要先在Master上新增元数据信息,然后才能开始使用,要不生产和消费时候会报topic不存在错误,如我们用安装包里的example对不存在的Topic名test进行生产: 部署示例 - 图19

Demo实例会报如下错误信息:

部署示例 - 图20

我们在Master管控台的Topic列表上加入该Topic先:

部署示例 - 图21

部署示例 - 图22

点击确认后会有一个选择部署该新增Topic的Broker列表,选择部署范围后进行确认操作;在完成新增Topic的操作后,我们还需要对刚进行变更的配置对Broker进行重载操作,如下图示:

部署示例 - 图23

重载完成后Topic才能对外使用,我们会发现如下配置变更部分在重启完成后已改变状态:

部署示例 - 图24

大家需要注意的是: 我们在重载的时候,要对待重载的Broker集合分批次进行。我们的重载通过状态机进行控制,会先进行不可读写—〉只读操作—〉可读写—〉上线运行各个子状态处理,如果所有待重启Broker全量重载,会使得已在线对外服务的Topic对外出现短暂的不可读写状况,使得生产、消费,特别是生产发送失败。

5.2 数据生产和消费:

在安装包里,我们打包了example的测试Demo,业务也可以直接使用tubemq-client-0.9.0-incubating-SNAPSHOT.jar封装自己的生产和消费逻辑,总的形式是类似,我们先执行生产者的Demo,我们可以看到Broker上已开始有数据接收: 部署示例 - 图25

部署示例 - 图26

我们再执行消费Demo,我们也可以看到消费也正常:

部署示例 - 图27

在Broker的生产和消费指标日志里,相关数据已经存在:

部署示例 - 图28

在这里,已经完成了TubeMQ的编译,部署,系统配置,启动,生产和消费。如果需要了解更深入的内容,就需要查看《TubeMQ HTTP API》里的相关内容,进行相应的配置设置。


Back to top