当前位置: 首页 > news >正文

【数据库知识】TxSQL 主从数据库同步底层原理深度解析

TxSQL 主从数据库同步底层原理深度解析

  • TxSQL 主从数据库同步底层原理深度解析
    • 一、核心架构概述
      • 1.1 主从同步数据流
    • 二、Binlog 日志系统详解
      • 2.1 Binlog 日志格式
      • 2.2 Binlog 事件结构
      • 2.3 Binlog 写入流程
    • 三、主从同步核心机制
      • 3.1 连接建立过程
      • 3.2 数据同步流程
      • 3.3 SQL线程重放机制
    • 四、GTID 全局事务标识
      • 4.1 GTID 结构
      • 4.2 GTID 复制流程
      • 4.3 GTID 状态管理
    • 五、半同步复制机制
      • 5.1 半同步复制流程
      • 5.2 ACK 确认机制
    • 六、并行复制优化
      • 6.1 基于事务的并行复制
      • 6.2 并行复制工作流程
      • 6.3 事务依赖检测
    • 七、高可用与故障切换
      • 7.1 主从切换流程
      • 7.2 数据一致性校验
    • 八、性能优化策略
      • 8.1 Binlog 优化配置
      • 8.2 延迟优化技术
    • 九、监控与故障排查
      • 9.1 关键监控指标
      • 9.2 常见故障处理
    • 十、安全与加密
      • 10.1 复制通道加密
      • 10.2 Binlog 加密
    • 总结:TxSQL 主从同步核心技术
    • 十一、TxSQL 半同步复制网络断开恢复机制深度解析
      • 一、网络断开时的处理流程
        • 1.1 主库检测与处理机制
        • 1.2 状态变量监控
      • 二、网络恢复后的数据同步机制
        • 2.1 自动重连与位点恢复
        • 2.2 数据一致性校验与恢复
      • 三、完整恢复流程示例
        • 3.1 实际场景模拟
        • 3.2 监控与告警配置
      • 四、高级恢复策略
        • 4.1 并行恢复优化
        • 4.2 流量控制与限速
      • 五、故障排查与手动干预
        • 5.1 常见问题处理
        • 5.2 数据一致性验证工具
      • 总结

TxSQL 主从数据库同步底层原理深度解析

一、核心架构概述

TxSQL(腾讯云数据库)的主从同步系统采用基于日志的异步复制架构,其核心组件和工作流程如下:

┌───────────────────────┐       ┌───────────────────────┐
│        Master         │       │        Slave          │
├───────────────────────┤       ├───────────────────────┤
│  Transaction Executor │       │  SQL Thread           │
│  Binary Log (Binlog)  │──────▶│  Relay Log            │
│  Binlog Dump Thread   │       │  I/O Thread           │
└───────────────────────┘       └───────────────────────┘

1.1 主从同步数据流

1. 事务执行 → 2. 写入Binlog → 3. 传输到从库 → 4. 写入Relay Log → 5. 从库重放

二、Binlog 日志系统详解

2.1 Binlog 日志格式

-- 查看Binlog格式
SHOW VARIABLES LIKE 'binlog_format';-- TxSQL支持的格式:
-- 1. STATEMENT: 基于SQL语句的复制
-- 2. ROW: 基于行的复制(默认)
-- 3. MIXED: 混合模式

2.2 Binlog 事件结构

struct BinlogEvent {uint32_t timestamp;      // 事件时间戳uint8_t event_type;      // 事件类型 (WRITE/UPDATE/DELETE)uint32_t server_id;     // 服务器IDuint64_t event_length;   // 事件长度uint64_t next_position; // 下一个事件位置uint16_t flags;          // 事件标志char data[];             // 事件数据
};

2.3 Binlog 写入流程

def write_to_binlog(transaction):# 1. 事务准备阶段start_event = create_event(START_EVENT)binlog_file.write(start_event)# 2. 写入所有操作事件for operation in transaction.operations:if binlog_format == ROW:event = create_row_event(operation)else:event = create_query_event(operation.sql)binlog_file.write(event)# 3. 提交事件commit_event = create_event(XID_EVENT)binlog_file.write(commit_event)# 4. 刷新到磁盘binlog_file.flush()fsync(binlog_file)

三、主从同步核心机制

3.1 连接建立过程

SlaveMasterCOM_REGISTER_SLAVE返回服务器ID和状态COM_BINLOG_DUMP发送Binlog事件流SlaveMaster

3.2 数据同步流程

// 主库Binlog Dump线程
void binlog_dump_thread() {while (running) {// 1. 等待从库连接Connection conn = accept_connection();// 2. 获取从库请求位置Position slave_pos = conn.read_request();// 3. 定位Binlog文件位置BinlogFile file = find_binlog_file(slave_pos);// 4. 发送事件流while (has_more_events(file)) {Event event = file.read_next_event();conn.send_event(event);// 流量控制if (conn.backlog_size > MAX_BACKLOG) {wait_for_slave_ack();}}}
}// 从库I/O线程
void io_thread() {while (running) {// 1. 连接主库Connection master = connect_to_master();// 2. 请求Binlog事件Position pos = get_last_relay_log_pos();master.request_binlog(pos);// 3. 接收并写入Relay Logwhile (event = master.read_event()) {relay_log.write(event);relay_log.flush();// 定期更新位置信息if (++event_count % 100 == 0) {update_relay_log_info(event.position);}}}
}

3.3 SQL线程重放机制

class SQLThread:def __init__(self):self.current_pos = 0self.relay_log = RelayLog()self.executor = QueryExecutor()def run(self):while True:# 1. 读取Relay Log事件event = self.relay_log.read_event(self.current_pos)# 2. 解析事件类型if event.type == QUERY_EVENT:self.execute_query(event.query)elif event.type == ROW_EVENT:self.apply_row_change(event)elif event.type == XID_EVENT:self.commit_transaction()# 3. 更新位置self.current_pos = event.next_pos# 4. 更新复制状态update_slave_status(self.current_pos)# 5. 错误处理if error := self.check_error():handle_replication_error(error)

四、GTID 全局事务标识

4.1 GTID 结构

GTID = source_id:transaction_id
示例: 3E11FA47-71CA-11E1-9E33-C80AA9429562:23

4.2 GTID 复制流程

未执行
已执行
主库事务开始
分配GTID
写入Binlog
从库接收GTID
检查GTID是否已执行
重放事务
跳过事务

4.3 GTID 状态管理

-- 查看已执行GTID集合
SHOW GLOBAL VARIABLES LIKE 'gtid_executed';-- 查看已接收GTID集合
SHOW GLOBAL VARIABLES LIKE 'gtid_received';

五、半同步复制机制

5.1 半同步复制流程

// 主库事务提交流程
int commit_transaction(Transaction trx) {// 1. 准备阶段prepare_phase(trx);// 2. 写入Binlogwrite_binlog(trx);// 3. 等待从库ACKif (semi_sync_enabled) {int timeout = semi_sync_timeout;while (timeout > 0) {if (receive_ack_from_slave(trx.gtid)) {break;}usleep(1000); // 1ms等待timeout--;}if (timeout <= 0) {downgrade_to_async(); // 降级为异步}}// 4. 提交事务commit_phase(trx);return SUCCESS;
}

5.2 ACK 确认机制

class SemiSyncSlave:def handle_event(event):# 1. 写入Relay Logrelay_log.write(event)# 2. 发送ACK给主库if event.type == XID_EVENT:ack_packet = create_ack_packet(event.gtid,event.position)master_connection.send(ack_packet)

六、并行复制优化

6.1 基于事务的并行复制

-- 配置并行复制模式
SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';
SET GLOBAL slave_parallel_workers = 8;

6.2 并行复制工作流程

Relay Log
分发器
Worker 1
Worker 2
Worker 3
事务重放
提交顺序控制

6.3 事务依赖检测

// 事务依赖关系检测
bool has_dependency(Transaction trx1, Transaction trx2) {// 1. 检查表冲突if (trx1.tables ∩ trx2.tables !=) {return true;}// 2. GTID依赖检测if (trx1.last_committed < trx2.sequence_number) {return true;}// 3. 外键依赖检查if (check_foreign_key_conflict(trx1, trx2)) {return true;}return false;
}

七、高可用与故障切换

7.1 主从切换流程

def failover(new_master):# 1. 停止所有写入stop_all_writes()# 2. 选择新主库candidate = select_best_slave()# 3. 提升为新的主库promote_to_master(candidate)# 4. 重新配置从库for slave in other_slaves:slave.change_master_to(candidate)# 5. 应用层切换update_app_config(new_master=candidate)# 6. 恢复写入resume_writes()

7.2 数据一致性校验

-- 使用pt-table-checksum工具
pt-table-checksum \--host=master_host \--user=check_user \--password=secret \--databases=production \--replicate=test.checksums

八、性能优化策略

8.1 Binlog 优化配置

# my.cnf 优化配置
[mysqld]
# Binlog 设置
binlog_format = ROW
binlog_row_image = MINIMAL
binlog_cache_size = 4M
max_binlog_size = 1G
sync_binlog = 1# 并行复制
slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 16
slave_preserve_commit_order = ON# 网络优化
slave_net_timeout = 60
slave_compressed_protocol = ON

8.2 延迟优化技术

// 多线程并发应用
void apply_events_in_parallel(EventQueue queue) {ThreadPool pool(worker_count);vector<Future> futures;while (!queue.empty()) {EventBatch batch = form_batch(queue);futures.push_back(pool.submit([batch]{apply_batch(batch);}));}// 保证提交顺序for (auto& future : futures) {future.wait();}
}// 批量提交优化
void apply_batch(EventBatch batch) {start_transaction();for (event in batch) {switch (event.type) {case WRITE_ROW:execute_insert(event.data);break;case UPDATE_ROW:execute_update(event.data);break;case DELETE_ROW:execute_delete(event.data);break;}}commit_transaction(); // 批量提交
}

九、监控与故障排查

9.1 关键监控指标

-- 复制延迟监控
SHOW SLAVE STATUS\G
*************************** 1. row ***************************Slave_IO_State: Waiting for master to send eventMaster_Host: 192.168.1.100Master_User: repl_userMaster_Port: 3306Connect_Retry: 60Master_Log_File: master-bin.000123Read_Master_Log_Pos: 753159Relay_Log_File: slave-relay.000456Relay_Log_Pos: 842617Relay_Master_Log_File: master-bin.000123Slave_IO_Running: YesSlave_SQL_Running: YesReplicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0Last_Error: Skip_Counter: 0Exec_Master_Log_Pos: 753159Relay_Log_Space: 842617Until_Condition: NoneUntil_Log_File: Until_Log_Pos: 0Master_SSL_Allowed: NoMaster_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0  # 关键延迟指标

9.2 常见故障处理

# 1. 复制中断处理
STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; # 跳过错误事务
START SLAVE;# 2. 数据不一致修复
pt-table-sync --execute \--sync-to-master slave_host \--databases production \--user=admin \--password=secret# 3. 主从切换后重建
# 在新主库上执行
RESET MASTER;
# 在从库上执行
STOP SLAVE;
RESET SLAVE ALL;
CHANGE MASTER TO ...;
START SLAVE;

十、安全与加密

10.1 复制通道加密

-- 配置SSL复制
CHANGE MASTER TO MASTER_SSL = 1,MASTER_SSL_CA = '/path/to/ca.pem',MASTER_SSL_CAPATH = '/path/to/ca/',MASTER_SSL_CERT = '/path/to/client-cert.pem',MASTER_SSL_KEY = '/path/to/client-key.pem';

10.2 Binlog 加密

# my.cnf 配置
[mysqld]
binlog_encryption = ON

总结:TxSQL 主从同步核心技术

TxSQL 的主从同步系统通过以下关键技术实现高可靠、高性能的数据复制:

  1. 多日志格式支持:动态选择ROW/STATEMENT格式平衡效率和可靠性
  2. GTID全局事务:确保事务在集群中的唯一性和顺序性
  3. 半同步复制:在性能和可靠性之间取得平衡
  4. 并行复制:多线程并发重放提高同步速度
  5. 智能流量控制:自适应网络状况调整传输速率
  6. 加密传输:保障数据传输安全性
  7. 自动容错:错误检测与自动恢复机制
  8. 在线切换:无缝主从切换保障业务连续性

通过深度优化Binlog处理、网络传输和事务重放等关键路径,TxSQL能够在保证数据一致性的前提下,实现毫秒级的复制延迟,满足金融级业务的数据同步需求。

十一、TxSQL 半同步复制网络断开恢复机制深度解析

一、网络断开时的处理流程

1.1 主库检测与处理机制
rpl_semi_sync_master_timeout > 0
rpl_semi_sync_master_timeout = 0
网络断开
主库等待ACK超时
超时策略判断
降级为异步复制
持续等待永不超时
记录降级事件
继续处理事务
更新状态变量

核心代码逻辑:

// 主库等待ACK的核心逻辑
int wait_for_slave_ack(THD* thd, int timeout_ms) {int result = 0;struct timespec start_ts, current_ts;// 记录开始时间clock_gettime(CLOCK_MONOTONIC, &start_ts);while (true) {// 检查是否收到从库ACKif (check_slave_ack_received()) {result = 1;  // 成功收到ACKbreak;}// 检查超时clock_gettime(CLOCK_MONOTONIC, &current_ts);long elapsed_ms = (current_ts.tv_sec - start_ts.tv_sec) * 1000 +(current_ts.tv_nsec - start_ts.tv_nsec) / 1000000;if (timeout_ms > 0 && elapsed_ms >= timeout_ms) {result = 0;  // 超时break;}// 短暂休眠后重试usleep(1000);  // 1ms}return result;
}// 事务提交时的处理
void handle_commit_with_semi_sync(THD* thd) {bool semi_sync_enabled = thd->variables.semi_sync_master_enabled;long timeout_ms = thd->variables.semi_sync_master_timeout;if (semi_sync_enabled) {// 等待从库ACKif (wait_for_slave_ack(thd, timeout_ms)) {// 成功收到ACK,统计计数atomic_add(&semi_sync_master_ack_success, 1);} else {// 超时,降级为异步复制atomic_add(&semi_sync_master_ack_timeout, 1);thd->semi_sync_master_status = SEMI_SYNC_OFF;// 记录警告日志sql_print_warning("Semi-sync replication timeout, ""switching to async replication");}}// 继续正常的事务提交commit_transaction(thd);
}
1.2 状态变量监控
-- 监控半同步复制状态的关键指标
SHOW STATUS LIKE 'Rpl_semi_sync%';-- 重要状态变量说明:
-- Rpl_semi_sync_master_status: ON/OFF 表示当前是否处于半同步模式
-- Rpl_semi_sync_master_yes_tx: 成功通过半同步复制的事务数
-- Rpl_semi_sync_master_no_tx: 超时降级为异步复制的事务数
-- Rpl_semi_sync_master_timeout_failures: 超时次数统计

二、网络恢复后的数据同步机制

2.1 自动重连与位点恢复
主库从库Relay_LogBinlog网络恢复重新建立连接验证从库身份上报最后接收的GTID/位点根据位点查找对应的Binlog文件返回从断点开始的Binlog事件发送缺失的Binlog事件流写入Relay LogSQL线程重放事务发送ACK确认恢复半同步模式主库从库Relay_LogBinlog

重连与位点恢复代码:

// 从库IO线程重连逻辑
void slave_io_thread_reconnect() {while (true) {try {// 1. 重新连接主库MYSQL* mysql = mysql_init(NULL);if (!mysql_real_connect(mysql, master_host, master_user, master_password, NULL, master_port, NULL, 0)) {sleep(RECONNECT_INTERVAL);continue;}// 2. 上报从库的复制位置char query[256];snprintf(query, sizeof(query),"SET @master_binlog_checksum=@@global.binlog_checksum");mysql_real_query(mysql, query, strlen(query));// 3. 发送COM_BINLOG_DUMP命令send_binlog_dump_command(mysql, current_log_file, current_log_pos);// 4. 开始接收Binlog事件流receive_binlog_events(mysql);break; // 连接成功,退出重连循环} catch (const std::exception& e) {sql_print_error("Slave I/O thread reconnect failed: %s", e.what());sleep(RECONNECT_INTERVAL);}}
}// GTID位点恢复算法
GtidSet calculate_gtid_recovery_set() {// 获取主库的已执行GTID集合GtidSet master_gtid_executed = get_master_gtid_executed();// 获取从库的已执行GTID集合GtidSet slave_gtid_executed = get_slave_gtid_executed();// 计算需要补发的GTID集合(差集)GtidSet recovery_set = master_gtid_executed.subtract(slave_gtid_executed);// 过滤掉已经在Relay Log中但未执行的事务GtidSet slave_gtid_received = get_slave_gtid_received();recovery_set = recovery_set.subtract(slave_gtid_received);return recovery_set;
}
2.2 数据一致性校验与恢复
-- 网络恢复后的自动校验流程(TxSQL内部逻辑)
-- 1. 比较主从GTID集合
SELECT @master_gtid_executed := @@global.gtid_executed as master_gtid,@slave_gtid_executed := @@global.gtid_executed as slave_gtid;-- 2. 计算需要补发的GTID范围
SET @recovery_gtid_set = GTID_SUBTRACT(@master_gtid_executed, @slave_gtid_executed);-- 3. 根据GTID定位Binlog位置
SELECT MIN(SUBSTRING_INDEX(SUBSTRING_INDEX(gtid, ':', 2), ':', -1)) as start_transaction_id,MAX(SUBSTRING_INDEX(SUBSTRING_INDEX(gtid, ':', 2), ':', -1)) as end_transaction_id
FROM (SELECT SUBSTRING_INDEX(SUBSTRING_INDEX(@recovery_gtid_set, ',', n), ',', -1) as gtidFROM numbers_table WHERE n <= LENGTH(@recovery_gtid_set) - LENGTH(REPLACE(@recovery_gtid_set, ',', '')) + 1
) gtid_list;-- 4. 从对应位置开始复制
CHANGE MASTER TO MASTER_AUTO_POSITION = 0,MASTER_LOG_FILE = 'binlog.000123',MASTER_LOG_POS = 1073741824;
START SLAVE;

三、完整恢复流程示例

3.1 实际场景模拟

假设网络断开期间主库执行了以下事务:

-- 主库执行的事务序列
GTID1: INSERT INTO orders VALUES (1001, 'pending', NOW());
GTID2: UPDATE inventory SET stock = stock - 1 WHERE product_id = 5;
GTID3: INSERT INTO payments VALUES (2001, 1001, 99.99, 'completed');
GTID4: UPDATE orders SET status = 'paid' WHERE order_id = 1001;

恢复过程详细步骤:

class SemiSyncRecoveryManager:def __init__(self, master_conn, slave_conn):self.master = master_connself.slave = slave_conndef execute_recovery(self):# 步骤1: 检查网络连接状态if not self.check_connectivity():raise Exception("Network connectivity check failed")# 步骤2: 比较GTID集合master_gtid_set = self.get_master_gtid_executed()slave_gtid_set = self.get_slave_gtid_executed()# 步骤3: 计算需要恢复的GTID范围recovery_gtids = self.calculate_recovery_gtids(master_gtid_set, slave_gtid_set)if not recovery_gtids:print("No data loss detected, replication can resume normally")return self.resume_normal_replication()# 步骤4: 定位Binlog起始位置start_position = self.find_binlog_start_position(recovery_gtids)# 步骤5: 启动补偿复制self.start_compensation_replication(start_position)# 步骤6: 等待数据追平self.wait_for_catch_up()# 步骤7: 恢复半同步模式self.restore_semi_sync_mode()print("Semi-sync replication recovery completed successfully")def calculate_recovery_gtids(self, master_set, slave_set):"""计算需要恢复的GTID差集"""recovery_gtids = []for gtid in master_set:if gtid not in slave_set:# 检查该GTID是否在传输中(Relay Log存在但未执行)if not self.is_gtid_in_relay_log(gtid):recovery_gtids.append(gtid)return recovery_gtidsdef wait_for_catch_up(self, timeout=300):"""等待从库追平主库"""start_time = time.time()while time.time() - start_time < timeout:master_gtid = self.get_master_gtid_executed()slave_gtid = self.get_slave_gtid_executed()if master_gtid == slave_gtid:print("Slave has caught up with master")return True# 检查复制延迟seconds_behind = self.get_seconds_behind_master()print(f"Current replication lag: {seconds_behind} seconds")time.sleep(5)raise Exception("Slave failed to catch up within timeout period")
3.2 监控与告警配置
# 监控配置示例(Prometheus + Alertmanager)
groups:
- name: semi-sync-alertsrules:- alert: SemiSyncTimeoutexpr: increase(rpl_semi_sync_master_timeout_failures[5m]) > 0for: 1mlabels:severity: warningannotations:summary: "半同步复制超时"description: "主从复制在5分钟内发生{{ $value }}次超时"- alert: SemiSyncNetworkDisconnectexpr: mysql_slave_status_slave_io_running == 0for: 30slabels:severity: criticalannotations:summary: "主从网络连接断开"description: "从库IO线程已停止运行"- alert: SemiSyncRecoveryCompleteexpr: mysql_global_status_rpl_semi_sync_master_status == 1for: 0slabels:severity: infoannotations:summary: "半同步复制已恢复"description: "网络恢复后半同步模式已自动重新启用"

四、高级恢复策略

4.1 并行恢复优化

对于大量数据需要恢复的场景,TxSQL采用并行恢复策略:

-- 启用并行恢复(TxSQL自动优化)
SET GLOBAL slave_parallel_workers = 8;
SET GLOBAL slave_parallel_type = LOGICAL_CLOCK;-- 监控并行恢复进度
SELECT THREAD_ID, PROGRAM, STATE, CURRENT_GTID,PROCESSED_EVENTS
FROM performance_schema.threads 
WHERE PROGRAM LIKE '%parallel%';
4.2 流量控制与限速

为防止恢复过程对生产系统造成影响,TxSQL实现智能流量控制:

class RecoveryFlowController {
private:size_t max_bandwidth;  // 最大带宽限制size_t current_rate;    // 当前传输速率public:void adjust_transmission_rate() {// 基于系统负载动态调整传输速率double system_load = get_system_load_average();double network_congestion = get_network_congestion_level();if (system_load > 0.8 || network_congestion > 0.7) {// 系统负载高或网络拥堵,降低传输速率current_rate = max_bandwidth * 0.3;} else if (system_load < 0.3 && network_congestion < 0.3) {// 系统空闲,提高传输速率current_rate = max_bandwidth * 0.9;} else {// 正常速率current_rate = max_bandwidth * 0.6;}apply_rate_limit(current_rate);}
};

五、故障排查与手动干预

5.1 常见问题处理
# 1. 检查复制状态
mysql -e "SHOW SLAVE STATUS\G" | grep -E "Running|Error|Behind"# 2. 查看半同步状态
mysql -e "SHOW STATUS LIKE 'Rpl_semi_sync%'"# 3. 检查网络连通性
ping -c 3 master_host
telnet master_host 3306# 4. 检查Binlog文件完整性
mysqlbinlog --verify-binlog-checksum binlog.000123# 5. 手动触发恢复(极端情况)
STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;  # 跳过错误事务
START SLAVE;
5.2 数据一致性验证工具
-- 使用TxSQL内置的校验工具
CALL mysql.rpl_semi_sync_verify('check_table_consistency', 'database_name', 'table_name'
);-- 生成一致性报告
SELECT table_schema,table_name,checksum_result,inconsistency_count
FROM information_schema.table_consistency_checks
WHERE check_timestamp > DATE_SUB(NOW(), INTERVAL 1 HOUR);

总结

TxSQL半同步复制在网络断开后的恢复机制体现了高度的智能化和可靠性:

  1. 自动降级保护:超时后自动降级为异步,确保主库可用性
  2. 精准位点恢复:基于GTID实现精确的断点续传
  3. 智能流量控制:根据系统负载动态调整恢复速度
  4. 并行恢复优化:大幅提升大量数据恢复效率
  5. 完备监控体系:实时跟踪恢复进度和系统状态

这种机制确保了即使在网络不稳定的环境中,TxSQL仍然能够保证数据的最终一致性,同时最大限度地减少对业务的影响。

http://www.dtcms.com/a/431036.html

相关文章:

  • 17zwd一起做网站百度地图怎么看沿途服务区
  • 语义场理论中的5个关键概念
  • 如何自己建立网站前端自己做博客网站
  • 812. 最大三角形面积
  • 【开题答辩全过程】以 springboot药店同城配送系统为例,包含答辩的问题和答案
  • 淘小说APP(免费阅读海量小说)
  • 自动化测试系列之pytest<一>
  • 上海自建站招聘网络营销的含义和特点
  • 闵行建设机械网站游戏开发指南
  • 30.响应式联系信息板块,采用 HTML 和 CSS | CSS 新形态设计
  • 高端营销网站建设新出的网络游戏排行榜
  • 湘潭房产网站建设wordpress自定义栏目是什么
  • iBizModel 实体界面行为(PSDEUIACTION)及实体界面行为组(PSDEUAGROUP)模型详解
  • InfiniBand 技术解析(3):解码 IB “黑话”—— 核心术语与架构概览
  • Node.js面试题及详细答案120题(101-110) -- 安全与部署篇
  • 主打社交应用,OpenAI发布视频生成模型Sora2,开启全新互动体验
  • SpringBoot对比FastAPI,优势与劣势
  • 八座立和气垫船:破解复杂地形救援难题的“黄金力量“
  • 高端「寺庙管理软件」的标志是什么?
  • 哈尔滨快速建站服务搜索引擎案例分析结论
  • C#基础02-Net框架
  • 淘宝网站开发店铺什么类别淄博网站制作服务推广
  • io多路复用:reactor模型的封装及与上层简单业务的实现(webserver)
  • Pod 的 init Containers
  • 个人网站备案 导航单位门户网站怎么做
  • 网站建设充值入口pc营销型网站
  • ML4T - 第7章第6节 使用Alphalens进行分析 Alphalens Analysis
  • Lazarus下载和安装教程(附安装包,图文并茂)
  • 高端自适应网站设计深圳市年年卡网络科技公司是什么
  • 安卓基础组件017--ImageView组件