今天就跟大家聊聊有关Apache TubeMQ使用时要注意哪些点，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。
1. 前言
Apache TubeMQ使用时要注意哪些点？为什么要这么设计？我在这里汇总解答下，便于大家了解。
2. 问题
2.1 为什么Broker要先配置再使用？
这个应是Apache TubeMQ在使用体验上与其他MQ的最大不同，如下图所示，集群要先部署Master；Master部署好Broker上线前，要先在Master配置好Broker相关配置，并调整其状态为上线状态后，Broker才能加入集群对外服务。TubeMQ为什么要这样设计，为什么不能如其他MQ，比如Kafka，配置好Broker的文件后，直接启动进程就可以加入集群直接使用呢？
为了集群管控： 大家可以试想下，如果直接加入有什么不足的地方，虽然方便使用，但如果我作为一个仿冒者，是否可以不知不觉加入集群让系统运行混乱，形成数据泄漏；或者有人会说启动时候配置文件里加入认证授权哈，但如果这个节点挂了，我从哪里方便的了解线上各个节点的总体情况呢？ TubeMQ采用的是SAAS模式进行集群管理，对应的它需要明确的知道集群的各个Broker节点当前状态是怎样，需要有一个地方来集中的管理它们；为了达到这个效果，我们设计了一个状态机：
Broker的主体状态为草稿--> 上线 --> 下线，新增加Broker配置均为草稿状态，只有将Broker状态设置为上线及之后的状态后才能正常启动新版本的Broker进程；在Broker配置变更后，还需要进行Broker加载操作，才能使配置最终生效；在broker下线时，只需要调用Broker下线操作即可。在进行状态机操作时我们还有需要特别注意的地方：
每个状态的流转都有状态机，在操作时，避免同一时刻对集群里所有的Broker节点做操作，只有等到运行子状态为idle时才能对下一批节点做处理；
Topic相关的配置变更后，要对被修改的Broker做重载操作，配置才能生效，Topic配置的[分区数，可发布、可订阅] 变更会触发流转状态机，对这些参数的变更要分批进行。
通过如上的设计，我们实现了整个节点的状态管理和配置管理。
2.2 为什么Topic不支持自动添加，同时新增时要输入授权码？
权限管控： 这块和Broker管理类似，采用SAAS模式，资源是集中且有限的，需要业务提前切分资源，准备好后再使用；同时页面上的所有变更操作，以及某些查询超过要输入授权码，是在于从系统的管理角度来看，这些操作本身就是分级的：
我们内部是运维来运营管理系统，授权码设置比较简单，放置在master.ini文件的confModAuthToken参数里，谁有权限登录该主机就有权限操作；这块大家也可以根据各自的实际情况进行调整，比如对你们的接认证系统。
我们的接口在指定Topic配置的时候是要求指定配置该Topic的BrokerId集合的，其作用在于精确的将Topic分配到指定的Broker，避免负载不一致问题；新增完Topic配置后，我们还需要对新增Topic的Broker集合做Reload操作，我们的做法是将Broker分批进行Reload，前一批Broker Reload完毕后再做下一批Broker的Reload，完成整体的配置变更。
2.3 为什么每次配置变更都要做Reload，并且要持续这么长时间？
这个应该也是Apache TubeMQ和其他MQ在使用体验上的最大差异之一，TubeMQ做配置变更时是通过Broker的Reload操作进行，一个Broker从调用Reload发起变更到变更最终结束，整个过程会耗费大约1.2分钟的间隔，为什么TubeMQ变更要这样做，为什么不像其他MQ一样，比如Kafka和Pulsar，将配置数据直接写入zk，这样配置就可以实时生效了？
上图是Reload的一个完整状态迁移图，Broker的Reload操作实际上包含了如下9个步骤：
执行Reload命令，Master将指定Broker的acceptPublish状态设置为false，先执行暂停生产操作，并等待1个最大心跳等待周期（25秒）；
向该Broker生产数据的Producer收到变更通知，暂停向该Broker发送数据，等待配置完成；
Master继续指定Broker的acceptSubscribe为false，执行暂停消费，并等待1个最大心跳等待周期；
订阅该Broker数据的Consumer感知Broker的配置将发生变更，暂停消费，等待配置完成；
Broker在如上过程完成（8秒内）配置变更；
Master指定Broker的acceptSubscribe为true，开启该Broker的消费，并等待1个最大心跳周期；
Consumer发起到该Broker的订阅操作；
Master指定Broker的acceptPublish状态设置为true,开启该Broker的生产，并等待1个心跳周期；
Master设置管理状态为空闲态。
为什么要这么做呢？这样操作下来时间很长且繁杂。
为了避免数据丢失： 从流程大家可以看到，TubeMQ的Reload采用这种近似系统重启的流程是为了尽可能的让消费先于生产加入集群，应对的就是系统扩容时，Consumer 以【缺省首次从最大位置开始消费，后续接续消费】设置时，遇到分区信息被Producer先于Consumer获取并生产数据时的数据丢失情况。
有同学可能会说，为什么不像Pulsar样，扩容时先将元数据写入ZooKeeper设置初始的offset位置来解决该问题呢？
与ZooKeeper解耦： 从系统实现大家也可以看到，ZooKeeper在TubeMQ里支持做offset的持久化用，系统实际运行起来后是可以脱离ZooKeeper而存在的，如果我们扩容时先将元数据写入ZooKeeper设置初始的offset位置，就会形成系统对ZooKeeper的依赖，比如Master连不上ZooKeeper时就会出现数据仍有丢的情况，同时，这样设计会加重配置变更的处理逻辑，以及延长了扩容的时间，甚至有可能因为ZooKeeper异常导致扩容操作失败。
考虑到线上的Topic操作其实是不需要即时产生，同时随着系统发展，后续不同类型的配置有可能又需要做状态机管理且多个变更合在一起操作时，仍有需要多个心跳周期同步后才能更新完的情况；所以，目前我们采用了如上异步模式进行。
注意： 从上面的描述我们可以看到，Broker进行Reload时，会有短暂的停读停写操作，因此，线上使用，我们都是对需要更新配置的Broker分批操作，逐批的Broker更新来完成Topic的配置更新。
2.4 为什么0.8.0版本的客户端连不上0.3.0的服务端？
SAAS管控： Apache TubeMQ采用的是强管控服务器模式，线上我们运用模式一定是服务端高版本客户端允许低版本形式存在；也即服务端兼容低版本客户端，但高版本的客户端不兼容低版本服务端，解决客户端复杂化的问题。
2.5 为什么WEB的API操作和Restful像，又不太像？为什么要手工拼接WEB API的查询返回？
方便使用及性能考虑： 反Restful模式主要是考虑新增修改操作可以直接在浏览器里输入url即可完成查询或者修改操作，缺点就是修改操作的量一次可能只能到几百的记录条数（最大URL长限制）；手工拼接json的返回结果，主要是性能考虑，从我们测试来看，手工操作可以达到毫秒级时耗，采用组件有可能是秒级，带来的问题就是编码上需要特别注意。
2.6 哪里查指标数据，比如每个分区的生产消费情况？
在Log日志目录下，生产指标存储于get_transfer.log，消费指标存储于put_transfer.log，细化到每个partition粒度。由于我们系统负载实在是很高，采用的方案都是吐指标，依靠第三方组件完成对应数据深加工。
2.7 后续TubeMQ的功能有什么方向？
个人觉得这个看开源社区的走向：Apache TubeMQ现在已经捐献给了Apache，虽然我们是项目的原创团队，但我们现在也只是参与社区。从我们的角度来说，我们会满足我们内部的业务需求，并将我们的特性贡献给社区；所以欢迎大家一起来共建共同促进社区的繁荣。
看完上述内容，你们对Apache TubeMQ使用时要注意哪些点有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注编程之家行业资讯频道，感谢大家的支持。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。