万亿级交易历史库：基于TiDB的HTAP架构设计与实践

作者： /

本文面向正在处理或即将面临海量交易历史数据挑战的中高级工程师与架构师。我们将从一个典型的高频交易场景出发，剖析传统分库分表与“OLTP + OLAP”分离架构的痛点。随后，我们将回归分布式系统与数据库的底层原理，系统性地拆解TiDB作为HTAP（混合事务/分析处理）数据库的核心技术基石，包括其分布式事务、共识协议与存算分离的实现。最终，我们将提供一套从表结构设计、数据写入到查询优化的完整工程实践指南，并给出一条从单体MySQL到TiDB HTAP架构的清晰演进路径，旨在为万亿级数据量的实时查询与分析场景提供一个经过生产验证的参考范本。

现象与问题背景

在任何一个中大型金融交易系统、跨境电商平台或数字货币交易所中，交易历史（Trades, Orders, Fills）都是增长最快、体量最庞大的核心数据。这类数据同时承载着两种截然不同但又同样关键的负载压力：

  • 在线事务处理（OLTP）负载：系统需要以极低的延迟（p99.9 < 50ms）和极高的吞吐量（TPS > 100k）持续不断地写入新生成的交易记录。这些写入操作通常是小事务，但并发度极高，对数据一致性要求为银行级。
  • 在线分析处理（OLAP）负载：与此同时，风控部门、量化分析团队、运营部门以及客户自身都需要对这些历史数据进行复杂查询。这些查询通常是“大查询”（Heavy Queries），扫描时间跨度长（数月甚至数年）、涉及数据量大（亿级至百亿级）、聚合逻辑复杂（多维度GROUP BY、JOIN、窗口函数），且查询模式不可预测。

这种典型的HTAP场景，让传统数据库架构捉襟见肘。一个典型的演进阵痛过程如下：

  1. 初期（单体MySQL）：业务初期，一个大规格的MySQL实例尚能应付。但随着数据量突破TB级别，单表的写入性能和查询效率急剧下降，简单的加索引已无法解决问题。一次`COUNT(*)`或一次未命中索引的范围查询，就可能导致整个数据库CPU飙升，IOPS打满，严重影响在线交易。
  2. 中期（MySQL分库分表）：为了解决单机瓶颈，团队被迫走上分库分表的道路。通常按用户ID或时间进行哈希/范围分片。这暂时解决了写入瓶颈，但带来了“运营噩梦”：DDL变更需要复杂的脚本和深夜发布窗口；跨分片的查询和JOIN变得异常困难，需要中间件（如ShardingSphere）支持，但性能和功能都受限；数据扩容（如从128个分片扩到256个）是一项高风险的、伤筋动骨的大手术。
  3. 后期（ETL + 数据仓库）：为了满足分析需求，团队不得不构建一套独立的OLAP系统。典型的架构是，通过Canal等工具订阅MySQL的binlog，经过ETL（Extract-Transform-Load）管道，将数据清洗后导入到ClickHouse、Greenplum或Hadoop生态（Hive/Spark）。这种架构虽然解决了OLAP的性能问题，但引入了新的、更尖锐的矛盾：
    • 数据时效性差：ETL流程通常是T+1或至少是小时级的，分析师和风控系统看到的是“过期”数据，无法进行真正的实时决策。
    • 架构复杂性高：需要维护两套异构的存储和计算系统，以及脆弱的ETL数据同步链路，任何环节出错都可能导致数据不一致。
    • 成本高昂：数据被冗余存储，且需要专门的团队来维护这套复杂的“数据烟囱”。

我们面临的核心矛盾是：如何在同一份数据上，同时满足高并发、低延迟的事务性写入和灵活、高效的实时分析查询，同时还要保证系统的水平扩展能力和运维的简洁性？ 这正是TiDB这类分布式HTAP数据库试图解决的根源问题。

关键原理拆解

要理解TiDB为何能解决上述矛盾，我们必须深入其架构内部，回到分布式系统的基础原理。TiDB的设计哲学并非空中楼阁，而是对Google Spanner/F1、Percolator等业界顶尖系统理论的工程化实现与超越。

（教授视角）

1. 分布式事务与全局时间戳：Percolator模型与2PC

要在多台机器上实现ACID事务，核心是解决两个问题：原子提交和隔离性。TiDB借鉴了Google的Percolator模型，其本质是一个经过优化的两阶段提交（Two-Phase Commit, 2PC）协议。为了保证全局事务的线性一致性（Serializable快照隔离），系统需要一个全局授时服务，即Placement Driver (PD)中的Timestamp Oracle (TSO)。

  • TSO：PD作为集群的“大脑”，会提供一个全局唯一且单调递增的时间戳。任何一个事务开始时，都会从PD获取一个`start_ts`；在准备提交时，会获取一个`commit_ts`。这个时间戳不仅是“时间”，更是逻辑上的“版本号”。
  • 2PC过程：当一个事务`INSERT INTO trade_history …`执行时，涉及的多个数据分片（Region）会参与2PC。客户端选择一个Key作为Primary Key，其余为Secondary Keys。
    1. Prewrite阶段：协调者（TiDB Server）对所有涉及的Key加锁，并将数据写入，但标记为“未提交”，同时将`start_ts`写入锁信息。
    2. Commit阶段：如果所有Prewrite都成功，协调者向PD获取`commit_ts`，然后提交Primary Key，释放锁并标记数据在`commit_ts`版本可见。随后异步地提交所有Secondary Keys。

    这个过程保证了即使在节点宕机、网络分区的情况下，一个事务要么全部成功提交，要么全部回滚，确保了原子性。MVCC（多版本并发控制）机制利用`start_ts`和`commit_ts`来判断数据对不同事务的可见性，从而实现快照隔离。

2. 数据高可用与一致性：Raft共识算法

TiDB的存储层TiKV将数据切分成若干个Region（默认96MB），每个Region是数据复制和负载均衡的基本单位。每个Region的数据拥有多个副本（通常是3个），这些副本构成一个Raft Group。Raft是一个比Paxos更易于理解和实现的共识算法，用于保证数据副本之间的一致性。

  • Leader与Follower：在一个Raft Group中，有且仅有一个Leader负责处理所有读写请求。写请求必须先在Leader上写入日志，然后复制到多数派（Quorum，3副本时为2个）的Followers上，才能向客户端确认写入成功。
  • 容灾切换：如果Leader宕机，剩下的Followers会通过选举机制在数秒内选出新的Leader，继续提供服务。这个过程对上层TiDB Server是透明的。只要多数派副本存活，数据就不会丢失，服务就不会中断，这构成了TiDB高可用的基石。

3. 写优化的存储引擎：LSM-Tree

TiKV的底层存储引擎采用RocksDB，一个基于LSM-Tree（Log-Structured Merge-Tree）的KV存储。这与MySQL的InnoDB使用的B+Tree有根本不同。

  • B+Tree：写操作是“in-place”更新，可能会导致大量的随机I/O，尤其是在机械硬盘时代。为了优化，InnoDB设计了Change Buffer等机制，但本质未变。
  • LSM-Tree：写操作是“out-of-place”的。新的写入首先进入内存中的MemTable（一个有序数据结构），当MemTable写满后，会刷写到磁盘上成为一个只读的、有序的SSTable（Sorted String Table）文件。后台线程会定期对不同层级的SSTable文件进行合并（Compaction）。

这种设计的核心优势在于，它将随机写转换为了内存中的高效操作和磁盘上的顺序写，极大地提升了写密集型业务（如交易历史记录）的吞吐能力。其代价是读操作可能需要查询多个层级的SSTable，存在“读放大”问题，但通过Bloom Filter等机制可以有效缓解。

4. HTAP的“秘密武器”：MPP与列式存储（TiFlash）

为了解决OLAP查询，TiDB引入了TiFlash。TiFlash是TiKV的一个特殊副本，它通过Raft Learner协议实时、无缝地从TiKV的Leader复制数据。关键在于，TiFlash在接收到数据后，会将其从行式存储转换为列式存储。

  • Raft Learner：Learner只接收Raft日志并应用，但不参与投票选举，因此不会增加OLTP写路径的延迟。这保证了TiFlash的加入对在线交易毫无影响。
  • 列式存储：对于分析查询，如`SUM(price * quantity)`，系统只需要读取`price`和`quantity`这两列的数据，而无需读取`trade_id`、`user_id`等其他无关列。这极大地减少了I/O量。
  • MPP架构：当一个分析查询下发到TiFlash时，TiDB的优化器会生成一个分布式的执行计划。TiFlash的多个节点会并行地扫描各自负责的数据分片，进行局部的计算（如聚合、过滤），然后通过网络进行数据交换（Shuffle），最终将结果汇聚起来。这种大规模并行处理（Massively Parallel Processing）能力使得复杂的分析查询也能在秒级或分钟级完成，而非小时级。

系统架构总览

一个典型的TiDB HTAP集群部署架构由以下几个核心组件构成，它们各司其职，共同构成一个逻辑上统一的数据库：

  • TiDB Server (SQL层):
    • 角色：无状态的计算节点。
    • 功能：负责接收客户端的SQL请求，解析SQL，生成和优化执行计划，与底层的TiKV/TiFlash进行数据交互。它兼容MySQL协议，使得应用几乎可以零成本迁移。
    • 扩展性：由于无状态，可以根据计算压力简单地增加或减少TiDB Server节点，并通过负载均衡器（如LVS、HAProxy）对外提供统一入口。
  • TiKV Server (行存引擎):
    • 角色：分布式、事务性的Key-Value存储引擎。
    • 功能：负责存储OLTP业务的核心数据。数据被切分为Region，每个Region及其副本通过Raft协议保证高可用和一致性。它是系统高性能点查和短范围扫描的主力。
    • 扩展性：当存储容量或OLTP负载成为瓶颈时，可以通过增加TiKV节点来水平扩展。PD会自动将部分Region迁移到新节点上，实现负载均衡。
  • TiFlash Server (列存引擎):
    • 角色：TiKV数据的列式存储副本。
    • 功能：通过Raft Learner协议实时复制TiKV数据，并将其转换为高效的列存格式。它利用MPP架构并行处理复杂的分析查询，是HTAP能力的基石。
    • 扩展性：可以独立于TiKV进行扩展。如果分析负载加大，只需增加TiFlash节点即可。
  • Placement Driver (PD Server, 集群大脑):
    • 角色：整个集群的元数据管理器和调度中心。
    • 功能：1) 存储集群的元数据（如Region的分布位置）；2) 分配全局唯一且单调递增的时间戳（TSO）给分布式事务；3) 智能调度，如根据节点的负载情况自动分裂/合并/迁移Region，实现自动化的负载均衡。
    • 高可用：PD本身也由3个或5个节点构成一个Raft集群，保证自身的高可用。

这套架构的精妙之处在于存算分离与存储引擎分离。TiDB Server是计算层，TiKV/TiFlash是存储层，二者可以独立扩展。同时，行存（TiKV）和列存（TiFlash）共存，但共享同一份数据源（通过Raft复制），由TiDB的优化器根据查询的成本自动选择最佳的执行引擎。这从根本上解决了传统“ETL + 数据仓库”架构的数据割裂和延迟问题。

核心模块设计与实现

（极客工程师视角）

原理再牛，落地是另一回事。在交易历史库这个场景下，魔鬼全在细节里，一个错误的表设计就可能让整个集群瘫痪。

1. 表结构设计：告别自增ID，拥抱数据散列

在分布式数据库里，MySQL里天经地义的`AUTO_INCREMENT`主键是性能头号杀手。因为递增的ID会导致所有写入请求都集中在最后一个Region上，形成一个巨大的写入热点。PD的负载均衡机制根本来不及反应，这个Region所在的TiKV节点CPU和I/O会瞬间被打满。

错误示范：


-- 绝对禁止！这会在TiDB中造成严重的热点问题
CREATE TABLE trade_history_bad (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  user_id BIGINT,
  trade_time TIMESTAMP(6),
  ...
);

正确姿势：

我们的目标是让写入均匀地分布到所有TiKV节点上。方法是让主键变得“无规律”和“高基数”。

方案一：使用`SHARD_ROW_ID_BITS`

如果你没有合适的业务主键，又想用类似自增ID的整数ID，TiDB提供了`SHARD_ROW_ID_BITS`选项。它会将行ID的高几位进行随机打散，避免连续写入。


CREATE TABLE trade_history (
  -- 注意：这里的id不再是严格递增的，但对于代理主键场景足够
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  user_id BIGINT,
  instrument_id VARCHAR(50),
  price DECIMAL(18, 8),
  quantity DECIMAL(18, 8),
  trade_time TIMESTAMP(6) DEFAULT CURRENT_TIMESTAMP(6),
  KEY idx_user_time (user_id, trade_time),
  KEY idx_time (trade_time)
)
-- 将row_id的前4位（2^4=16）打散，写入会分散到16个不同的逻辑分片
SHARD_ROW_ID_BITS = 4
-- 在建表时就预先切分好Region，避免启动时集中分裂
PRE_SPLIT_REGIONS = 4;

方案二：联合主键

如果业务上存在高基数的字段，比如`user_id`或`order_id`，用它作为联合主键的前缀是更好的选择，这让数据在逻辑上自然地按高基数列分散。


CREATE TABLE trade_history_v2 (
  -- 将高基数的user_id放在前面，写入会根据user_id分散
  user_id BIGINT,
  trade_id BIGINT, -- 保证唯一性
  instrument_id VARCHAR(50),
  -- ... other fields
  PRIMARY KEY (user_id, trade_id),
  KEY idx_time_instrument (trade_time, instrument_id)
);

2. 数据写入：批量，批量，还是批量！

对于交易系统这种高频写入场景，逐条`INSERT`的开销是巨大的。每一次`INSERT`都意味着一次完整的网络往返、SQL解析、事务开启与提交。正确的做法是攒批（Batching）。

假设你的成交回报是通过Kafka消息队列过来的，你的消费端应用应该做的是：从Kafka拉取一批消息（比如100条），在内存里组装成一条大的`INSERT`语句，然后一次性提交给TiDB。这能极大降低网络开销和事务开销，TPS能提升一个数量级。

下面是一个Go语言的示例，演示如何构建批量`INSERT`：


package main

import (
	"database/sql"
	"fmt"
	"strings"
	// "github.com/go-sql-driver/mysql"
)

type Trade struct {
	UserID       int64
	TradeID      int64
	InstrumentID string
}

// batchInsertTrades 将一批交易数据高效写入TiDB
func batchInsertTrades(db *sql.DB, trades []Trade) error {
	if len(trades) == 0 {
		return nil
	}

	// 1. 准备SQL语句模板和参数占位符
	// SQL: INSERT INTO trade_history (user_id, trade_id, instrument_id) VALUES (?), (?), ...
	const batchSize = 100 // 根据实际情况调整batch大小
	valueStrings := make([]string, 0, batchSize)
	valueArgs := make([]interface{}, 0, batchSize*3)

	for i, t := range trades {
		valueStrings = append(valueStrings, "(?, ?, ?)")
		valueArgs = append(valueArgs, t.UserID, t.TradeID, t.InstrumentID)

		// 2. 当攒够一个批次或遍历完所有数据时，执行一次数据库操作
		if (i+1)%batchSize == 0 || i == len(trades)-1 {
			stmt := fmt.Sprintf("INSERT INTO trade_history (user_id, trade_id, instrument_id) VALUES %s",
				strings.Join(valueStrings, ","))

			// 3. 使用预编译或直接执行，对于TiDB，直接拼接影响不大
			_, err := db.Exec(stmt, valueArgs...)
			if err != nil {
				// 实际生产中需要有重试和错误处理逻辑
				return fmt.Errorf("batch insert failed: %w", err)
			}

			// 4. 重置，准备下一个批次
			valueStrings = make([]string, 0, batchSize)
			valueArgs = make([]interface{}, 0, batchSize*3)
		}
	}
	return nil
}

3. 查询优化：让优化器为你工作

TiDB HTAP的魅力在于，你写的是标准SQL，而底层的优化器会自动决策是从TiKV（行存）还是TiFlash（列存）读取数据。这个决策基于成本估算（Cost-Based Optimization）。

启用TiFlash副本：

首先，你需要告诉TiDB为你的大表创建TiFlash副本。这个操作是在线的，不会阻塞读写。


-- 为trade_history表创建1个TiFlash副本
ALTER TABLE trade_history SET TIFLASH REPLICA 1;

场景一：C端用户查自己的交易记录（OLTP查询）

这是一个典型的点查或小范围扫描，期望毫秒级响应。


SELECT * FROM trade_history
WHERE user_id = 12345
AND trade_time >= '2023-10-01 00:00:00'
ORDER BY trade_time DESC
LIMIT 20;

执行`EXPLAIN ANALYZE`，你会看到执行计划中，`operator info`列会显示`TableReader`从TiKV读取数据，并使用了`idx_user_time`索引。这是正确的，因为走TiKV的索引扫描效率最高。

场景二：运营人员统计某交易对的全市场交易量（OLAP查询）

这是一个典型的大范围聚合查询，扫描数据量巨大。


SELECT
  DATE_FORMAT(trade_time, '%Y-%m-%d') AS trade_date,
  SUM(price * quantity) AS total_volume
FROM trade_history
WHERE instrument_id = 'BTC/USDT'
  AND trade_time BETWEEN '2023-01-01' AND '2023-12-31'
GROUP BY trade_date
ORDER BY trade_date;

再次执行`EXPLAIN ANALYZE`，你会看到神奇的一幕：执行计划的`operator info`列会显示`TableReader`从TiFlash读取数据。计划中会出现`TableFullScan`（在TiFlash节点上），并且`task`类型为`mpp`。这意味着TiDB优化器识别出这是一个分析型查询，自动将其路由到TiFlash，并启动了MPP模式进行并行计算。同样一条SQL，根据其模式，走向了完全不同的执行路径。

在极少数优化器选择错误的情况下，你也可以用Hint强制指定执行引擎：


-- 强制从TiFlash读取
SELECT /*+ READ_FROM_STORAGE(TIFLASH[t]) */ * FROM trade_history t ...;

-- 强制从TiKV读取
SELECT /*+ READ_FROM_STORAGE(TIKV[t]) */ * FROM trade_history t ...;

性能优化与高可用设计

热点问题再审视：除了写入热点，读取也可能产生热点。例如，某个超级大户的交易记录被频繁查询，导致该用户数据所在的Region成为读热点。TiDB Dashboard是你的好朋友，它能可视化地展示各个TiKV节点的CPU、IO和Region读写情况。一旦发现热点，除了在业务层面进行缓存，还可以手动干预：`SPLIT REGION …`，将热点Region一分为二，让PD将其调度到不同节点上。

大事务规避：分布式事务的代价昂贵。在TiDB中，一个事务涉及的Key越多、持续时间越长，发生冲突和回滚的概率就越大，对系统性能的影响也越大。经验法则是，将事务大小控制在100MB以内，涉及的Key数量在数万级别以下。对于需要修改大量历史数据的后台任务，一定要分页、分批处理，将一个大事务拆解成数千个小事务。

高可用部署：生产环境的TiDB集群必须考虑跨可用区（AZ）甚至跨数据中心（DC）部署。标准的3副本模式可以部署在同一城市的3个不同AZ，可容忍任意单个AZ故障。对于金融级的“两地三中心”容灾需求，可以部署5副本（3个在主DC，2个在同城灾备DC），并通过Placement Rules精细控制Raft Leader的分布，保证主DC拥有多数派的Leader，从而在提供跨城容灾能力的同时，不牺牲日常的读写延迟。

架构演进与落地路径

直接从MySQL切换到TiDB是一项重大决策，一个务实、分阶段的演进路径至关重要。

  1. 第一阶段：评估与验证。不要直接在核心系统上马。选择一个对实时性要求不高但数据量大的旁路系统，如用户行为日志、审计日志库，先用TiDB进行替换。在这个过程中，让团队熟悉TiDB的运维、监控和性能调优。
  2. 第二阶段：作为MySQL从库。利用TiDB Data Migration (DM) 工具，将TiDB作为现有MySQL分片集群的一个“特殊从库”。DM工具可以实时同步上游多个MySQL分片的binlog到TiDB中，自动处理合库合表。此时，线上读写流量依然走MySQL，但可以将所有复杂的分析和报表查询切到TiDB上，立即缓解主库的OLAP压力。这是风险最低的一步。
  3. 第三阶段：读写分离与部分迁移。将部分读流量（特别是那些可以容忍极低延迟的查询）切换到TiDB。同时，可以考虑将`trade_history`这样只写不改、数据量暴增的表，其写流量直接切换到TiDB。此时，你的架构是MySQL和TiDB并存，服务于不同类型的表。
  4. 第四阶段：全面切换，拥抱HTAP。当团队对TiDB的稳定性和性能有了充分信心后，完成最后的迁移。将所有核心交易表的读写流量全部切换到TiDB，并下线老旧的MySQL分片集群和ETL数据仓库。此时，在`trade_history`表上启用TiFlash副本，你便拥有了一个真正的、统一的HTAP平台。原先需要T+1才能生成的报表，现在可以实时在在线库上直接查询，业务的想象空间被彻底打开。

从单体瓶颈，到分片之苦，再到“烟囱式”架构的割裂，交易历史数据的存储与查询一直是后台架构演进的缩影。以TiDB为代表的分布式HTAP数据库，通过将分布式事务、多副本共识、LSM-Tree以及列式存储MPP等计算机科学的经典理论进行系统性的工程整合，为这个长期存在的难题提供了一个优雅且强大的解决方案。它不仅是数据库技术的演进，更是上层业务架构简化的催化剂。

延伸阅读与相关资源

  • 想系统性规划股票、期货、外汇或数字币等多资产的交易系统建设，可以参考我们的
    交易系统整体解决方案。
  • 如果你正在评估撮合引擎、风控系统、清结算、账户体系等模块的落地方式，可以浏览
    产品与服务
    中关于交易系统搭建与定制开发的介绍。
  • 需要针对现有架构做评估、重构或从零规划，可以通过
    联系我们
    和架构顾问沟通细节，获取定制化的技术方案建议。
滚动至顶部