OpenTenBase/TXSQL应用实践

原创 D枫 2025-08-26

836

大家都知道OpenTenBase是双内核的，而且可以独立部署。结合实际，考虑到目前我所开发的应用系统大多用的都是mysql。于是我安装了TXSQL，并结合业务需求，进行了应用系统部分功能的改造适配。当然主要还是和数据操作相关的改动。常见的增删改查这些基础功能我就不多说了。主要还是对TXSQL提到的线程池、强同步、审计这些高级功能，实际应用到我的业务系统中，来解决一些之前的一些业务痛点。话不多说，下面正文开始。

一、OpenTenBase/TXSQL入门安装

已经安装好的，直接滑动看标题二即可。

详细过程我就不说了，直接看官方文档即可。

https://docs.opentenbase.org/

我是的系统是CentOS7的。但是安装过程中遇到了不少问题。这里我列一下，希望对大家有帮助。

1.Cannot find a valid baseurl for repo: base/7/x86_64

解决方法：重配DNS 配置或者更换CentOS 7 归档仓库

# 编辑 DNS 配置
sudo vi /etc/resolv.conf

# 备份原有仓库
sudo mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak
# 下载阿里云的 CentOS 7 归档仓库
sudo curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo
# 清理并重建缓存
sudo yum clean all
sudo yum makecache

2.没有可用软件包 zstd-devel

解决方法：网上别的方法无效，直接尝试从源码编译安装

# 安装编译依赖
sudo yum install -y gcc make cmake
# 下载源码
wget https://github.com/facebook/zstd/archive/refs/tags/v1.5.5.tar.gz
# 解压并编译
tar -zxf v1.5.5.tar.gz
cd zstd-1.5.5
make
sudo make install
# 刷新环境变量
source /etc/profile
# 验证
zstd --version

二、TXSQL应用实践

我所在的行业主要服务对象是航道和海事部门。我们开发的航道智慧管理系统是保障内河 / 沿海通航安全的核心基础设施，需实时处理船舶轨迹上报、通航调度指令、船员信息查询、设备故障日志四大类数据。之前一直用的也是mysql的数据库。但是呢，传统基于社区版 MySQL 的架构让我们的业务系统一直存在几个问题：船舶高峰时段连接数暴增导致吞吐下降、调度指令主备同步丢失引发安全隐患、船员隐私数据访问无追溯、设备故障大日志占用过多存储等等。

在翻看文档时，发现txsql解决了一下mysql之前的一些问题，想着正好实际应用一些，看一下效果如何。先列一个，我汇总的对比图。

一、线程池：解决船舶轨迹高并发上报的吞吐瓶颈

1. 业务痛点问题

在我们的航道系统需要实时接收辖区内船舶的 GPS 轨迹数据，每艘船每秒上报 1 条包含船舶ID、经度、纬度、航速、时间戳的记录，高峰时段（如早 8 点 - 10 点、晚 6 点 - 8 点）辖区内 500 + 艘船同时在线，连接数瞬时突破 2000。社区版 MySQL 的one-thread-per-connection模式下，线程上下文切换频繁，CPU 利用率超 90%，轨迹数据插入 TPS 从 1000 骤降至 300，部分数据会因超时丢失，这个问题当时我们团队也是多次讨论如何解决。

2. TXSQL 线程池应用逻辑

通过 TXSQL 线程池的 “线程组复用 + 优先级队列 + 定时唤醒” 机制，限制并发线程数、减少资源竞争：

按服务器 CPU 核心数（假设 16 核）设置 16 个线程组，每个线程组管理 1 个 listener 线程和多个 worker 线程；
船舶轨迹上报请求（低时延需求）放入高优先级队列，优先处理；
timer 线程每隔 100ms 扫描线程组，避免因 worker 线程 IO 等待导致的请求堆积。

3. 代码实例（参数配置 + 轨迹上报）

（1）线程池核心参数配置

-- 1. 开启线程池（TXSQL默认开启，需确认配置）
SET GLOBAL thread_pool_enabled = ON;

-- 2. 线程组个数=CPU核心数（16核服务器）
SET GLOBAL thread_pool_size = 16;

-- 3. timer线程扫描间隔（100ms，避免线程组停滞）
SET GLOBAL thread_pool_stall_limit = 100;

-- 4. worker线程空闲超时（60秒，释放闲置资源）
SET GLOBAL thread_pool_idle_timeout = 60;

-- 5. 高优先级队列模式（transactions：事务类请求优先）
SET GLOBAL thread_pool_high_prio_mode = 'transactions';

-- 查看线程池状态（确认活跃线程数、队列长度）
SHOW GLOBAL STATUS LIKE 'Threadpool%';
-- 关键状态：Threadpool_active_threads（活跃worker数）、Threadpool_queue_length（队列等待数）

（2）船舶轨迹表创建与高并发插入

-- 创建船舶轨迹表（核心业务表，需高吞吐插入）
CREATE TABLE ship_trajectory (
    trajectory_id BIGINT AUTO_INCREMENT COMMENT '轨迹ID',
    ship_id VARCHAR(32) NOT NULL COMMENT '船舶唯一标识（如IMO编号）',
    longitude DECIMAL(10,6) NOT NULL COMMENT '经度',
    latitude DECIMAL(10,6) NOT NULL COMMENT '纬度',
    speed DECIMAL(5,2) NOT NULL COMMENT '航速（km/h）',
    report_time DATETIME(3) NOT NULL COMMENT '上报时间（毫秒级）',
    PRIMARY KEY (trajectory_id),
    INDEX idx_ship_time (ship_id, report_time) -- 支持按船舶+时间查询轨迹
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT '船舶实时轨迹表';

-- 高并发插入示例（模拟单船1秒1条数据，可通过程序批量执行）
INSERT INTO ship_trajectory (ship_id, longitude, latitude, speed, report_time)
VALUES 
('IMO9876543', 120.123456, 31.654321, 15.5, NOW(3)),
('IMO9876543', 120.123567, 31.654432, 15.3, NOW(3) + INTERVAL 1 SECOND),
('IMO1234567', 120.234567, 31.765432, 18.2, NOW(3));

4. 应用实际效果

切换到txsql后，线程池启用时，高峰时段连接数 2000 + 时，CPU 利用率降至 60% 以下，轨迹插入 TPS 稳定在 1200+，数据丢失率从 5% 降至 0，这样可以满足船舶轨迹相关业务需求。

二、强同步：保障通航调度指令的主备数据一致性

1. 业务痛点问题

对航道部门来说。通航调度指令（如 “禁航通知、航道临时改道、优先通行授权”）直接关系航行安全，需确保主库（调度中心）与从库（备用中心）数据 100% 一致。传统 MySQL 半同步复制在网络波动时会退化为异步，曾出现主库宕机后从库缺失 3 条 “禁航指令”，导致 2 艘船违规进入禁航区的安全事件。

2. TXSQL 强同步应用逻辑

通过 TXSQL 强同步的 “ACK 确认 + 线程异步化” 机制，实现：

主库执行调度指令后，暂存会话不回复，等待从库 ACK 确认；
从库接收 binlog 并落盘后，立即向主库发送 ACK；
主库收到 ACK 后唤醒会话，完成指令提交，绝不退化为异步。

3. 代码实例（主从强同步配置 + 调度指令操作）

（1）主库强同步参数配置

-- 1. 开启强同步（主从需同时开启）
SET GLOBAL sqlasyn = ON;

-- 2. 等待ACK超时时间（30秒，超时报错，不降级）
SET GLOBAL sqlasyntimeout = 30;

-- 3. 禁止异步降级（核心：确保强一致）
SET GLOBAL tdsql_allow_async = OFF;

-- 4. 从库ACK发送阈值（中继日志累积20KB即发送ACK，减少延迟）
SET GLOBAL relay_log_sync_threshold = 20480;

-- 查看强同步状态（确认无超时、无降级）
SHOW GLOBAL STATUS LIKE 'sqlasyn%';
-- 关键状态：sqlasyn_acks_to_Source（从库ACK次数）、sqlasyn_timeout_num（超时次数，应=0）

（2）从库强同步参数配置

-- 1. 开启强同步（与主库保持一致）
SET GLOBAL sqlasyn = ON;

-- 2. 中继日志超时强制落盘（100ms，避免ACK延迟）
SET GLOBAL relay_log_sync_timeout = 100;

-- 3. 启用rpl_replication_ack_thread（专门处理ACK发送）
SET GLOBAL rpl_replication_ack_thread = ON;

（3）通航调度指令表创建与操作

-- 创建通航调度指令表（核心事务表，需强一致）
CREATE TABLE navigation_command (
    command_id INT AUTO_INCREMENT COMMENT '指令ID',
    command_type TINYINT NOT NULL COMMENT '指令类型：1=禁航，2=改道，3=优先通行',
    command_content VARCHAR(512) NOT NULL COMMENT '指令内容（如“长江段10:00-12:00禁航”）',
    target_ship_ids VARCHAR(1024) COMMENT '目标船舶ID（多个用逗号分隔，空=全体）',
    create_time DATETIME NOT NULL COMMENT '创建时间',
    is_valid TINYINT DEFAULT 1 COMMENT '是否有效：1=有效，0=失效',
    PRIMARY KEY (command_id),
    INDEX idx_create_time (create_time)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT '通航调度指令表';

-- 插入调度指令（强同步生效：主库等待从库ACK后才返回成功）
INSERT INTO navigation_command (command_type, command_content, target_ship_ids, create_time)
VALUES (1, '长江南京段14:00-16:00因桥梁检修禁航', 'IMO9876543,IMO1234567', NOW());

-- 主库宕机后，从库查询确认指令存在（验证一致性）
SELECT command_id, command_content, is_valid 
FROM navigation_command 
WHERE create_time >= '2025-08-25 13:59:00';

4. 应用效果

这里我在使用强同步启用后，主备数据一致性达 100%，测试几天均无任何调度指令丢失，主备切换时间从 3 分钟缩短至 1 分钟。

三、审计：实现船员隐私数据的访问追溯与安全管控

1. 业务痛点

在平时的业务场景中，登记和保存船员信息也是很重要的，但是船员信息（如身份证号、联系方式、健康证明）属于隐私数据，需记录所有访问行为（谁访问、何时访问、执行了什么操作），防止未授权查询或篡改。曾出现运维人员违规下载 100 + 船员身份证号的事件，因无审计日志导致无法追溯责任。

2. TXSQL 审计应用逻辑

通过 TXSQL 审计的 “同步判断 + 异步落盘” 机制，实现：

仅记录 “船员信息表” 的访问行为，减少冗余日志；
工作线程生成审计事件后，无锁处理（仅内存占位加锁），性能影响 < 6%；
Flush 线程异步将日志写入文件，支持事后追溯与高危操作阻断。

3. 代码实例（审计规则配置 + 日志查询）

（1）审计核心参数配置

-- 1. 审计模式：filter（仅按规则记录，不记录全量）
SET GLOBAL audit_txsql_audit_mode = 'filter';

-- 2. 需审计的数据库（船员信息库：waterway_crew）
SET GLOBAL audit_txsql_filter_db = 'waterway_crew';

-- 3. 需审计的表（船员信息表：crew_info）
SET GLOBAL audit_txsql_filter_table = 'crew_info';

-- 4. 审计日志文件大小（单个8GB，避免频繁轮转）
SET GLOBAL audit_txsql_log_file_max_size = 8589934592;

-- 5. 日志保留个数（10个，总存储80GB）
SET GLOBAL audit_txsql_rotate_file_count = 10;

-- 查看审计状态（确认无忽略、无截断）
SHOW GLOBAL STATUS LIKE 'audit_cdb%';
-- 关键状态：audit_cdb_ignore_actions（忽略审计数，应=0）、audit_cdb_truncat_counts（SQL截断数）

（2）船员信息表创建与审计日志验证

-- 创建船员信息库
CREATE DATABASE IF NOT EXISTS waterway_crew DEFAULT CHARSET=utf8mb4;
USE waterway_crew;

-- 创建船员信息表（含隐私字段）
CREATE TABLE crew_info (
    crew_id INT AUTO_INCREMENT COMMENT '船员ID',
    crew_name VARCHAR(32) NOT NULL COMMENT '姓名',
    id_card VARCHAR(18) NOT NULL COMMENT '身份证号（隐私）',
    phone VARCHAR(11) NOT NULL COMMENT '手机号（隐私）',
    health_cert VARCHAR(64) COMMENT '健康证明编号',
    join_time DATE NOT NULL COMMENT '入职时间',
    PRIMARY KEY (crew_id),
    UNIQUE KEY uk_id_card (id_card)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT '船员信息表';

-- 模拟用户查询船员信息（触发审计）
SELECT crew_name, id_card, phone 
FROM crew_info 
WHERE crew_id = 1001;

-- 查看审计日志（日志路径通过audit_txsql_log_file_path参数查询）
-- 1. 先获取日志路径
SHOW GLOBAL VARIABLES LIKE 'audit_txsql_log_file_path';
-- 假设路径为：/data/txsql/audit/audit.log

-- 2. 查看日志内容（Linux环境，需运维权限）
-- cat /data/txsql/audit/audit.log
-- 日志示例（JSON格式）：
-- {"time":"2025-08-25 10:30:00","user":"app_user","ip":"192.168.1.100","db":"waterway_crew","table":"crew_info","sql":"SELECT crew_name, id_card, phone FROM crew_info WHERE crew_id = 1001","rows_affected":1,"error_code":0}

4. 应用效果

设置了相关权限，审计功能启用后，所有船员信息访问行为均被记录，成功追溯 2 次未授权查询（运维人员超权限访问），并通过 “高危 SQL 阻断” 功能拦截 1 条 “DELETE FROM crew_info” 的恶意语句，船员数据安全风险降低 90%。

四、列压缩：优化设备故障大日志的存储与访问效率

1. 业务痛点问题

航道设备（如航标灯、雷达、水位传感器）的故障日志包含故障详情字段（存储设备异常堆栈、运维人员处理记录），平均长度 5000 字符，且访问频率低（仅故障排查时查询）。传统行压缩需解压整行数据，导致 “查询设备状态（高频）” 时性能下降；不压缩则单表存储量 3 个月达 500GB，存储成本都很高。以前我们不得不使用定期转移数据和清理表的方式来提高查询速度。

2. TXSQL 列压缩应用逻辑

通过 TXSQL 列压缩的 “精准字段压缩 + 按需解压缩” 机制，实现：

仅对 “故障详情” 大字段启用压缩，小字段（如设备 ID、故障时间）不压缩；
访问小字段时不触发解压缩，访问大字段时才调用 zstd 算法解压缩；
压缩率达 60%（5000 字符压缩后约 2000 字符），大幅节省存储。

3. 代码实例（压缩列配置 + 故障日志操作）

（1）列压缩核心参数配置

-- 1. 压缩阈值：字段长度>1000字符才压缩（匹配故障详情字段）
SET GLOBAL innodb_min_column_compress_length = 1000;

-- 2. 压缩算法：zstd（压缩率高，性能均衡）
SET GLOBAL innodb_column_compression_algo = 'zstd';

-- 3. zstd压缩级别：3级（默认，平衡压缩率与性能）
SET GLOBAL innodb_zstd_column_compression_level = 3;

（2）设备故障日志表创建与数据操作

-- 创建设备故障日志表（大字段“fault_detail”启用压缩）
CREATE TABLE device_fault_log (
    log_id BIGINT AUTO_INCREMENT COMMENT '日志ID',
    device_id VARCHAR(32) NOT NULL COMMENT '设备ID（如航标灯ID：BEACON-001）',
    fault_type TINYINT NOT NULL COMMENT '故障类型：1=断电，2=信号丢失，3=数据异常',
    fault_time DATETIME NOT NULL COMMENT '故障发生时间',
    -- 大字段启用压缩：COLUMN_FORMAT COMPRESSED
    fault_detail TEXT COLUMN_FORMAT COMPRESSED COMMENT '故障详情（含堆栈、处理记录，大字段）',
    handler VARCHAR(32) COMMENT '处理人',
    PRIMARY KEY (log_id),
    INDEX idx_device_time (device_id, fault_time)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT '航道设备故障日志表';

-- 插入故障日志（“fault_detail”自动压缩存储）
INSERT INTO device_fault_log (device_id, fault_type, fault_time, fault_detail, handler)
VALUES (
    'BEACON-001',
    2,
    NOW(),
    '2025-08-25 09:15:00 航标灯信号丢失，排查发现天线松动；09:20 重新固定天线，信号恢复；09:25 测试信号强度：-75dBm，正常。堆栈信息：SignalLossException: timeout=5000ms, retry=3次',
    'zhang_san'
);

-- 1. 访问小字段（不触发解压缩，性能快）
SELECT device_id, fault_type, fault_time 
FROM device_fault_log 
WHERE device_id = 'BEACON-001';

-- 2. 访问压缩字段（触发解压缩，仅故障排查时使用）
SELECT fault_detail 
FROM device_fault_log 
WHERE log_id = 10001;

-- 查看压缩效果（对比压缩前后存储）
-- 1. 查看表占用空间
SELECT TABLE_NAME, DATA_LENGTH/1024/1024 AS data_size_mb 
FROM information_schema.TABLES 
WHERE TABLE_SCHEMA = 'waterway_system' AND TABLE_NAME = 'device_fault_log';
-- 2. 未压缩时500GB的表，压缩后约200GB，节省60%存储

4. 应用效果

列压缩启用后，设备故障日志表存储量从 500GB 降至 200GB，存储成本降低 60%；访问小字段（如设备故障类型）的查询耗时从 15ms 降至 8ms，故障排查时访问大字段的耗时仅增加 3ms，完全满足业务需求。同时，也对我们解决历史数据查询有了极大的帮助。

三、总结与改进建议

就个人使用体验来说，TXSQL 的高级功能在我们智慧航道管理系统中的应用还是“利远大于弊”的，覆盖了航道系统的核心需求，同时也解决以前的一些痛点问题。后续随着航道系统向 “智慧通航” 升级（如引入 AI 船舶轨迹预测、无人机航道巡检），以及国产化改造。可以进一步探索 TXSQL 与大数据平台的协同能力（如审计日志对接数据安全中台、压缩日志同步至数据湖），实现更深度的技术赋能。当然txsql还需要完善一下社区生态，在使用过程中，相关的问题解决文档还是太少了。

「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」

关注作者

OpenTenBase/TXSQL应用实践

一、OpenTenBase/TXSQL入门安装

二、TXSQL应用实践

一、线程池：解决船舶轨迹高并发上报的吞吐瓶颈

二、强同步：保障通航调度指令的主备数据一致性

三、审计：实现船员隐私数据的访问追溯与安全管控

四、列压缩：优化设备故障大日志的存储与访问效率

三、总结与改进建议

评论