拿到TLQ 7/8这套消息中间件的时候,很多运维同事的第一反应是:这玩意儿不就是国产消息队列嘛,思路应该和RabbitMQ、Kafka差不太多。可真到了配置环境、启服务、查队列、定位故障的时候才发现,命令一多就容易乱,今天记住了明天又得翻手册。尤其是从TLQ 7升级到TLQ 8之后,部分命令参数、日志路径、配置文件写法都有调整,网上资料又少,踩坑基本靠实战。这篇文章就是我这些年维护TLQ节点时整理出来的常用命令说明。不看那些绕来绕去的官方手册,直接用命令说话,讲清楚每个命令是干什么的、什么时候用、配合哪些Linux命令能快速定位问题。做信创、做国产化项目,或者说公司刚好在用东方通这套中间件的朋友,可以直接把这里面的命令抄到自己的运维笔记里。1. TLQ 7/8 命令体系:先搞清楚命令到底在管什么1.1 三个核心对象:队列、进程、连接TLQ的命令看着多,但捋清楚背后的管理对象之后,记忆成本会低很多。整个TLQ运行体系里,最核心的就三样东西:队列、进程、连接。队列是消息存放的基本单位。业务数据从发送方写入队列,接收方从队列里取走,消息在队列里等着被消费。可以把它理解成一个仓库,一边进货一边出货,队列深度就代表仓库里积压了多少货。进程是跑在节点上的服务实例。TLQ安装完之后,不是直接一个服务管所有事,而是按业务需要拆成多个进程。每个进程负责一部分队列的收发处理,进程挂了,对应的队列消息就送不出去。所以日常巡检里查进程状态是最频繁的操作。连接是节点之间、客户端和服务端之间的通信链路。发送方和接收方要通消息,必须先把连接建立起来,再往队列里投递数据。连接断了但进程还活着,这时候消息一样会积压。所有TLQ命令,本质上都是用来操作这三类对象的。你敲tpc查的是进程,敲tpq查的是队列,敲tps查的是收发统计,思路一下就顺了。1.2 命令家族:一图理清 tlc/tpc/tpq/tps/tlvTLQ 7/8的命令基本都集中在安装目录的bin下面,命令名很有规律,一般是以tl开头,后面跟一个表示功能的字母。我按使用频率排了个序,建议新手先记住前五个就够了。命令功能定位典型用途tlc节点级启停控制启动、停止、查看整个TLQ节点状态tpc进程管理查看进程列表、启动/停止指定进程tpq队列管理查看队列、创建队列、清空队列tps统计查询查看消息收发总量、通道状态tlv日志查看查看TLQ运行日志文件tls状态查询查询节点、通道、连接等运行状态tlc 管的是整个节点,相当于总开关;tpc 管的是节点内部的各业务进程,相当于服务器上的 systemctl;tpq 管的是消息队列,对应到其他中间件里就是 Kafka 的 topic 管理命令。tps 和 tlv 则属于查看类,排查问题的时候最常用。有一个很实用的习惯:拿到一个新环境,第一件事不是翻配置,而是先把tlc、tpc、tpq各自的帮助信息打出来。TLQ 8 的命令帮助写得还算清楚,基本都能告诉你当前版本支持哪些参数。有些老同事用的习惯还是 TLQ 7 的,到了 TLQ 8 直接套,经常会遇到参数不识别的情况。2. 环境准备:装好之后先别急着敲命令2.1 TLQ_HOME、PATH、节点名这些环境变量很多新手在TLQ上栽的第一个跟头,不是命令用错,而是环境变量没配好,敲命令提示command not found。TLQ安装完成之后,至少有三个环境变量要确认:TLQ_HOME指向TLQ的安装根目录,所有配置、日志、数据文件都在这下面。TLQ_NODENAME是当前节点名,TLQ允许在一台机器上部署多个节点,通过节点名区分。PATH里需要加上$TLQ_HOME/bin,否则你每次敲命令都得写全路径。我一般会在/etc/profile或者用户自己的.bash_profile里加上这段:export TLQ_HOME/opt/tlq8 export TLQ_NODENAMENODE1 export PATH$TLQ_HOME/bin:$PATH注意,TLQ的业务进程尽量不要用root用户启动。实际项目里很多公司会单独建一个tlq用户,数据目录和日志目录的属主都设为这个用户。用root启进程不是不行,但后面配置用户权限、做审计的时候会很麻烦。在银河麒麟这种国产操作系统上,还要留意一下系统的安全策略。有些环境默认开启了强制访问控制,TLQ的启动脚本可能被拦截。遇到启动脚本执行了但进程起不来的情况,先别怀疑TLQ配置,先查一下系统安全日志,再确认bin目录下的文件有没有执行权限。2.2 三个需要认识的配置文件TLQ 7/8的配置不像Kafka那样一堆properties文件,它比较收敛,核心就是三个:tlq.conf是节点配置文件,定义节点名、监听IP、端口、日志路径等信息。节点启动时首先读这个文件,IP或端口写错,进程可能起不来,或者起来了但其他节点连不上。tpq.conf是队列配置文件,定义队列名、队列数据文件路径、队列大小限制等。需要预先规划好队列的存放目录,这个路径如果不存在,创建队列的时候会报错。tlquser.conf是用户配置文件,定义哪些用户能访问哪些队列、具备什么权限。权限配置不全,最常见的现象就是消息发不进去,报权限不足。这三个文件的存放位置通常在$TLQ_HOME/config下。不同版本的默认路径略有差异,不确定的时候可以用find $TLQ_HOME -name *.conf看一下。2.3 修改配置后如何生效TLQ 7/8的配置修改之后,不是立即生效的。tlq.conf和tpq.conf这类核心配置,需要重启节点或重启对应进程才能加载。有个细节要注意:修改tpq.conf后如果只重启了部分进程,其他进程里可能还持有旧的队列信息。稳妥起见,涉及队列配置的变更,我一般直接整节点重启。虽然麻烦一点,但能避免很多配置明明改了却没生效的诡异问题。另外,TLQ 8版本里有些配置项是支持动态刷新的,但不同模块支持程度不一样。最靠谱的判断方式还是看日志,进程启动时会在日志里打印加载了哪个配置文件、加载是否成功。看到日志里出现配置加载失败的报错,优先检查文件语法。3. 核心命令实操:运维日常离不开的那几个3.1 启停服务用 tlctlc是节点级的总控命令,先把节点的启停流程捋清楚。启动节点:tlc start这条命令会读取tlq.conf里的配置,启动节点的主控进程,然后再拉起配置好的业务进程。启动过程会输出到终端,看到类似start success才算真正起来。停止节点:tlc stop注意,停止节点会先把业务进程停掉,再停主控进程。如果队列里还有大量积压消息,直接停止节点会导致消息在本地队列里滞留,重启后继续处理,不会丢,但会影响业务连续性。所以规范的做法是:先看队列深度,确认积压量在可接受范围内,再执行停止。查看节点状态:tlc status这个命令会返回当前节点是否运行、主控进程PID等信息。排查问题时,我习惯先用它确认节点整体状态,再往下看具体进程。3.2 进程管理用 tpctpc是日常使用频率最高的命令,相当于TLQ的进程管理器。查看所有进程:tpc all输出里会列出节点下配置的所有进程,以及每个进程的运行状态。状态列有几种常见值:RUNNING 表示正在运行,STOPPED 表示已停止。实际项目里经常有这样的情况:节点整体是活的,但某个业务进程挂掉了,这时候tpc all一眼就能看出来。启动指定进程:tpc start 进程名停止指定进程:tpc stop 进程名如果你不知道节点下配置了哪些进程,可以先执行:tpc listtpc list列出来的是配置文件里声明的进程清单,tpc all列出来的是进程实际运行状态。两者对照看,就能知道哪些进程该启动却没起来。这里有个经验:排查问题的时候,先跑tpc all,再跑tpc list,把结果一起截图或记录下来。很多故障不是因为命令不会用,而是现场信息没采集全,回头分析时缺少依据。3.3 队列管理用 tpqtpq是队列管理的核心命令。队列是TLQ里消息存储的地方,所以这个命令在查积压、清数据时特别重要。查看所有队列:tpq list查看某个队列的详细信息,包括当前深度:tpq info 队列名队列深度是运维监控的重要指标。发送端一直在投递、接收端消费慢了,队列深度就会上涨。正常的深度应该是一个平稳的值,如果持续上涨,说明消费端出问题了。清空队列:tpq clear 队列名创建队列:tpq create 队列名删除队列:tpq delete 队列名这里必须强调一下,tpq clear和tpq delete都属于高风险操作。清空队列会直接丢弃队列里尚未被消费的消息,删除队列则会把队列定义和数据一起删掉。生产环境里操作之前,一定要先做备份,最好再拉一个人二次确认。我见过一次生产事故,本来想清一个测试队列,结果节点名写错,把另一个正在承载业务的队列清了,消息全部丢失。从那以后,我要求团队在TLQ上执行危险命令之前,至少得先执行一遍tpq list看清楚队列名,再复制、再执行。3.4 统计与日志用 tps / tlvtps用来查统计信息。比如你想知道某个进程或某个通道发送了多少条消息、接收了多少条消息,就可以用:tps不同版本支持的统计维度不一样,有的按进程统计,有的按队列统计,有的按通道统计。先看帮助信息,确认你需要的维度在这个版本里是否支持。tlv是日志查看命令,用来查看TLQ自身的运行日志。TLQ的日志默认写在$TLQ_HOME/logs目录下,文件名一般和进程名或节点名相关。查看最近的日志:tlv -f 日志文件实际排查时,我不太喜欢直接用tlv翻文件,更习惯直接切到日志目录用 Linux 原生命令。道理很简单:tlv的功能相对基础,而tail、grep、less这些工具组合起来效率高太多,还能按时间、按关键字过滤。4. 配合Linux命令一起用:排查效率翻倍4.1 用 ps、netstat 确认TLQ状态TLQ命令能告诉你业务层面上进程状态是什么,但有些底层问题,必须靠Linux命令来补充。查TLQ相关进程是否真的在运行:ps -ef | grep tlq这个命令会列出所有名字里带tlq的进程,包括主控进程和业务进程。如果TLQ命令显示进程是RUNNING,但ps里找不到对应PID,那大概率是进程崩溃了,但状态文件里还残留着旧标记。查端口监听状态:netstat -anp | grep 端口号TLQ节点之间通信是靠端口的。如果业务反馈节点之间连不上,先用这个命令确认监听端口是否正常。netstat输出里的LISTEN表示正在监听,ESTABLISHED表示已建立连接。端口没监听,就先检查进程是否存活,再检查tlq.conf里的IP端口配置。在国产操作系统上,netstat命令不一定默认安装。如果没有,可以用:ss -anp | grep 端口号ss是netstat的替代命令,输出格式类似,功能也够用。4.2 用 tail、grep 定位日志问题TLQ的日志文件一般比较大,直接打开翻找效率太低。我的习惯是先定位日志目录,然后用组合命令查。跟踪最新日志:tail -f $TLQ_HOME/logs/*.log按关键字过滤日志:grep -i error $TLQ_HOME/logs/*.log按时间范围过滤:grep 2025-06-17 10:2 $TLQ_HOME/logs/*.log实际救援场景里,我会开两个终端,一个跑tail -f实时跟踪,另一个用grep搜索历史日志里的关键字。一边观察当前报错,一边查找之前是否出现过相同问题,定位速度会快很多。4.3 用 telnet 验证通道连通性TLQ节点之间通信,或者客户端连接TLQ服务端,本质都是TCP连接。如果消息发不出去,先别急着怀疑TLQ配置,先验证一下网络层通不通。测试端口连通性:telnet 对端IP 端口号如果端口通了,终端会提示Connected;如果连不上,会卡住直到超时。这个测试能快速区分问题是出在网络层还是中间件层。不过现在有些环境默认不装telnet客户端。如果提示command not found,可以用nc代替:nc -vz 对端IP 端口号nc -vz返回的结果更直接,通了就输出succeeded,不通就输出failed。我排查TLQ通道问题时的基本流程是:先ssh到对端机器,用tpc all看进程;再用telnet或nc测端口;都正常了再看TLQ日志。按这个顺序,绝大多数问题都能定位到具体环节。5. 常见问题与排查技巧实录5.1 节点起不来怎么办TLQ节点启动失败,是最常见的问题之一。我遇到过的情况主要有这么几类:端口被占用。启动时提示端口绑定失败,用netstat -anp | grep 端口号看一下,通常会发现是另一个进程占用了监听端口。这种情况先确认旧进程是不是残留的TLQ进程,如果是僵尸进程就清理掉,如果是其他软件的端口冲突,就改tlq.conf里的端口配置。节点名冲突。一台机器上部署了多个TLQ节点,如果TLQ_NODENAME配成了相同的名字,后启动的节点会报错。检查每个节点的环境变量,确保节点名唯一。配置文件语法错误。TLQ启动时会解析配置文件,格式不对会直接拒绝启动。常见的有写错了括号、路径用了中文字符、某个配置项多了个等号。处理方式是用备份文件对比,或者把配置还原到上次正常的版本。启动失败后,第一时间看日志:tail -50 $TLQ_HOME/logs/*.log日志里一般会明确指出失败原因,比瞎猜快得多。5.2 队列有积压、消息发不出去队列深度持续上涨,说明消息生产速度大于消费速度。先查接收端:用tpq info 队列名查看队列深度和最近读写情况。如果队列深度很大,再看接收端进程状态tpc all,确认对应消费进程是否在运行。进程正常但消息还是积压,就要考虑网络问题。用telnet 对端IP 端口号验证连通性,再用tps查看发送统计,确认消息是不是已经发出去了、只是对端没收到。还有一种容易被忽略的情况:队列所在的磁盘满了。TLQ队列数据是写文件的,磁盘满了之后消息写入失败,积压会一路飙升。用df -h检查队列目录所在分区的剩余空间,这是必查项。5.3 权限不足、队列不存在的处理有些业务联调时反馈:消息发不进去,报权限不足。这时候先查tlquser.conf,看看对应用户有没有该队列的写权限。常见原因是新加队列之后,用户配置文件没同步更新。队列不存在的报错,则要先确认tpq list里有没有这个队列。如果配置了但没生效,检查对应进程有没有重启。如果队列真的不存在,用tpq create 队列名创建,然后记得同步补配置文件和用户权限。5.4 TLQ日志无限增长的应对TLQ运行时间长了,日志文件会非常大,不仅占磁盘,还会拖慢系统。常见原因是日志级别设置得太低,任何DEBUG信息都往文件里写。建议在配置里把日志级别调整为INFO级别,生产环境一般不需要DEBUG,除非在配合排查疑难问题。日志长时间不滚动也是原因之一。确认日志策略里是否配置了按大小或按天切分。如果默认没有滚动策略,建议在计划任务里写一个按周归档的脚本:find $TLQ_HOME/logs -name *.log -mtime 7 -exec gzip {} \;这样可以把超过7天的日志压缩归档,降低磁盘占用。归档前确保问题已经定位完,别急着把原始日志清掉。6. 实战心得与避坑指南6.1 不同版本命令有差异,先查帮助TLQ 7和TLQ 8的命令主体一致,但细节差异不少。比如某些参数在7版本里能用的,到8版本里废除了;某些命令在8版本里改名了。所以每次到新环境,我第一件事永远是带上-h或help参数跑一遍,看当前版本真正支持什么。tpc -h tpq -h tlc -h不要觉得自己是老手就跳过这一步,版本差异就藏在这种不起眼的地方。6.2 危险操作一定要慎用这一节的话值得多说几遍:tpq clear、tpq delete、tlc stop都属于会影响线上业务的命令。我的做法是,执行前至少确认三件事:确认操作对象,用tpq list看清队列名;确认操作时间,业务低峰期执行;确认有备份方案,能恢复或者能接受影响。如果是给别人做培训,我会专门强调:TLQ没有回收站,清掉的队列消息找不回来。6.3 把常用命令封装成脚本TLQ日常巡检的命令重复性比较高,我习惯写成一个巡检脚本,每次直接执行就能拿到所有关键信息。大致思路是这样的:#!/bin/bash echo TLQ Node Status tlc status echo TLQ Process Status tpc all echo TLQ Queue Depth for q in $(tpq list | awk {print $1}); do tpq info $q | head -5 done echo Port Listening ss -anp | grep tlq实际脚本可以根据业务队列数量调整,核心目的就是把人为操作变成固定流程,避免漏查。6.4 养成记录操作的习惯最后分享一个我自己的习惯:每次在TLQ上执行重要操作前,我会先在本地记录本上写一行什么时间、在哪个节点、要执行什么命令、预期结果是什么。执行完再补一行实际结果。看起来多了一步操作,但在出现问题时,这个记录能帮你在最短时间内回溯到底改了什么、改错了什么。TLQ这套中间件,命令本身不难,难的是在关键时刻能冷静判断该看哪里、该跑哪条命令。把这套命令逻辑理清楚,日常巡检和故障排查都会轻松很多。
