顶点 HyperDB vs 金证 KMDB vs 恒生 LightDB vs 华锐 ATP T7：券商自研内存数据库的四种路线

📌 核心论点 券商核心交易系统的信创替换，本质上是"去 Oracle"的底层战役。而这场战役的胜负手，就是内存数据库的技术路线选择。当前市场上形成了四条泾渭分明的技术路线——顶点的"交易全内存+外置持久化"、金证的"低时延平台内行业定制内存库"、恒生的"HTAP 融合数据库内嵌内存引擎"，以及华锐代表的"消息驱动+内存计算"极速路线。

四条路线各有哲学，殊途同归指向"微秒级时延+自主可控"。

一、为什么"内存数据库"是券商信创的胜负手

#

1.1 传统架构的三重枷锁

#

我国证券行业集中交易系统在技术架构上对美国大型 IT 公司依赖程度较高，核心是对国外商业数据库、特定商业硬件平台的高度依赖。这种依赖带来三重枷锁：

• 性能枷锁：Oracle 在极端高并发场景下的时延难以进一步压缩，无法满足微秒级交易需求。
• 成本枷锁：Oracle 商业授权费用高昂，且每年递增。
• 安全枷锁：核心系统底层不可控，不符合信创自主可控要求。

1.2 内存数据库路线的破局逻辑

#

分布式内存数据库路线有效解决了这一难题——既提升可靠性，又避免软件性能带来的延时问题。

其核心思想是：将交易期间的性能部分由内存数据库来替代，交易结束后的查询等存储功能由国产信创数据库或其他开源数据库来替代。 用技术架构手段降低对单体数据库的性能要求，也基于分布式数据库降低了系统的崩溃风险。

1.3 四家厂商的路线分化

#

2020 年是关键转折年——恒生电子推出 UF3.0（搭载 LightDB+Light-LDP）、金证股份推出 FS2.0/FS2.5（自研应用+K-LDP平台）、顶点软件推出 A5 信创版（自研 HyperDB 内存数据库）。三家厂商在内存数据库路线上做出了三种不同的工程选择，叠加华锐 ATP T7 的消息驱动路线，构成了券商核心交易系统的"内存数据库四种路线"。

二、路线一：顶点 HyperDB——“交易全内存+外置持久化"的去 O 路线

#

2.1 工程哲学：存算分离，彻底去 Oracle

#

顶点软件的路线最为激进——彻底摆脱传统商用数据库依赖。

其核心架构理念是：

日间实时交易 ──→ HyperDB 内存数据库（完全替代 Oracle）
                       ↓
交易结束后查询/存储 ──→ 国产信创数据库或开源关系型数据库

顶点 A5 采用了存算分离交易架构：在中间件和内存数据库中完成计算，弱化了数据库的作用，仅作为落地存储使用。数据存储设计分为交易型数据处理和持久化数据存储两部分，分别使用顶点自研的 HyperDB 内存数据库与开源关系型数据库。

2.2 HyperDB 的技术底座

#

• 自研起点：2013 年公司决定自主研发"飞驰"内存数据库 HyperDB。
• 架构特性：分布式架构、多核性能优化、自研算法、高可靠、自带信创属性。
• 平台适配：完全适配信创环境，在鲲鹏、海光等 ARM/x86 混合信创环境下性能表现优异，在 ARM 平台上 HyperDB 的查询能力反超英特尔平台。
• 高可用：A5 交易节点采用双活技术，内存采用事务同步技术，服务集群以及主从模式多种高可用手段。

2.3 极致演进：HTS 2X 纯血信创版

#

2024 年 12 月，顶点发布 HTS 2X 纯血信创版，将"存算分离"推向极致：

💡 HyperDB + 腾讯云 TDSQL 组合：通过自研内存数据库 HyperDB 与腾讯云数据库 TDSQL 的组合，实现交易数据实时内存计算与交易流水数据存储的分流，单笔订单处理时间降至 10 微秒以内，全链路时延小于 30 微秒；同时数据查询、存储效率等综合性能提升 30%。

2.4 标杆落地

#

• 东吴证券：A5 信创版全面上线，行业首次实现全面去"O”（即不依赖 Oracle 数据库），交易时延从 10ms 降至 <1ms。
• 中信证券：A5 Max 超级版完成头部券商亿级客户迁移标杆工程。
• 东吴、东海、华宝等 4 家券商：实现全客户全业务全栈信创。

2.5 路线本质

#

📌 顶点路线的本质：不是"用国产数据库替换 Oracle"，而是**“用架构重构消灭 Oracle 的存在必要”**——通过存算分离，让内存数据库承接所有性能敏感的实时计算，让国产关系型数据库只做它擅长的持久化存储。这是一种"釜底抽薪"式的去 O 路线。

三、路线二：金证 KMDB——低时延平台内的"行业定制内存数据库"

#

3.1 工程哲学：K-LDP 三件套协同

#

金证的思路与顶点截然不同。KMDB 不是孤立的内存数据库，而是 K-LDP 低时延平台的三大核心组件之一：

K-LDP 低时延平台
    ├── KGMS：统一接入，隔离外网客户端与内网服务端
    ├── HARE：高速消息总线，端到端时延低于 1.1 微秒
    └── KMDB：行业定制内存数据库

三者结合实现交易的高性能、高并发和高可靠性。

3.2 KMDB 的技术特性

#

金证官方对 KMDB 的定位是"行业定制内存数据库"：

• 传统数据库能力：具备传统数据库的数据一致性保证、SQL 执行引擎功能。
• 高可靠运行模式：支持多种高可靠运行模式。
• 与外置数据库协同：可与多种磁盘数据库同步。
• 存算分离架构：FS2.5 清算采用 KMDB 内存数据库技术，以存算分离的架构设计实现清算高性能。

3.3 KMDB 的双场景应用

#

KMDB 在 FS2.5 中承担双重角色：

3.4 持续演进

#

• 2023 年报：向头部券商客户输出基于 KOCA 平台自研的内存数据库 KMDB。
• 2024 年上半年：FS2.5 在新订单、新清算系统采用 KMDB，性能进一步提升。
• 2024 年 8 月：FS2.5 完整继承发展，KMDB 作为 K-LDP 平台核心组件持续迭代。
• 2026 年 8 月：金证与华为强强联合，KMDB+HARE+KGMS 通过 HARE 多活选举机制、KGBP 主从跟多活架构保障系统高可靠。

3.5 标杆落地

#

• 中金财富：信创一代核心交易柜台。
• 中信建投、中泰证券：整体柜台项目。
• 银河、广发：FS2.5 全栈国产化方案批量落地。
• 平安证券：新一代交易订单系统。

3.6 路线本质

#

📌 金证路线的本质：KMDB 不是要"替代"Oracle，而是要**“在 K-LDP 低时延平台内与 HARE 协同，形成一个完整的低时延交易解决方案”**。KMDB 是行业定制的内存数据库，它与 KGMS、HARE 深度耦合，构成金证原生信创的技术铁三角。这是一种"平台化"的内存数据库路线。

四、路线三：恒生 LightDB——HTAP 融合数据库内嵌内存引擎

#

4.1 工程哲学：多存储引擎融合

#

恒生的思路与前两家都不同。LightDB 不是单纯的内存数据库，而是同时支持在线事务处理与在线分析处理的融合型分布式数据库。

其核心创新是多存储引擎架构：

LightDB 融合数据库
    ├── LightSQL：SQL 协调层（接收请求、编译 SQL、全局事务协调）
    ├── GCS：全局资源和事务管理服务
    ├── LightTP：联机存储引擎（传统数据库功能）
    ├── LightMEM：内存存储引擎（微秒级事务处理）
    └── LightAP：分析存储引擎（大数据统计分析）

LightMEM 内存存储引擎是 LightDB 的"内存数据库"组件——主要用于为延时非常敏感的交易和风控场景，同时提供 API 直连和 SQL 访问接口，以提供微秒级的事务处理响应为目标而设计。

4.2 LightDB 的金融级特性

#

• 金融场景优化：快和安全是最重要的特性，LightDB 能确保在吞吐量达到 50000 tps 时延时稳定在 5-8 毫秒。
• 架构设计：计算与存储分离，支持多存储引擎，多副本高可用。
• 差异化一致性控制：支持从表、到事务、到实例层面的差异化一致性控制，确保性能诉求和一致性诉求在解耦基础上的兼顾。
• 信创适配：支持麒麟 Linux、openEuler 等国产操作系统，支持华为鲲鹏 ARM、海光 x86 处理器等国产处理器，透明数据加密支持国密标准。
• 兼容性强：兼容 Oracle、MySQL，保留 PostgreSQL 核心性能。

4.3 在 UF3.0 中的角色

#

恒生 UF3.0 依托 JRES3.0 云原生底座、自研 LDP 低时延平台、MDB 内存数据库搭建综合交易体系。LightDB 作为融合数据库，在 UF3.0 中承担核心数据存储与实时计算双重角色。

4.4 标杆落地

#

• 招商证券：2025 年 7 月全面上线 UF3.0，完成千万级客户全量切换，行业首个基于云原生架构承载千万级客户的系统整体落地。
• 东吴证券：首家与恒生在"TA+LightDB"信创项目上开展合作并落地上线。
• 整体规模：11 家券商完成上线，签约合作机构超 20 家，存量累计服务客户规模突破 5000 万。

4.5 路线本质

#

📌 恒生路线的本质：不是单纯追求"内存化"，而是追求**“融合化”**——LightDB 通过 LightMEM 内存引擎提供微秒级响应，但通过 LightTP、LightAP 等不同存储引擎的协同，提供 HTAP 融合能力。这是一种"数据库内解决所有问题"的融合路线，而非"存算分离、各司其职"的路线。

五、路线四：华锐 ATP T7——消息驱动+内存计算的极速路线

#

5.1 工程哲学：消息驱动，而非数据库驱动

#

华锐的路线与前三家有本质区别——它不是以内存数据库为核心，而是以自研低时延消息总线 AMI 为核心：

AMI 消息总线（微秒级通信）
    ↓
消息驱动 + 可靠内存计算 + 多分片并发处理
    ↓
内存计算 + 分布式存储

5.2 极速性能表现

#

• 系统内部处理时延：小于 80μs。
• 单节点混合压力吞吐量：大于 160 万 TPS。
• 交易时延：微秒级。
• 并发能力：支持 1 亿+证券账户。
• 可用性：多活集群，故障秒级切换，99.999% 可用性。
• 国泰君安：交易速度提升 20 倍以上。
• 国信证券：交易时延降至 50μs，吞吐量提升上百倍。

5.3 与前三家的本质差异

#

5.4 路线本质

#

📌 华锐路线的本质：在"内存数据库"之争中走出了一条"非数据库"的路线——通过自研世界级分布式低时延消息中间件 AMI 构建消息驱动架构，可靠内存计算直接在消息层完成，从根本上绕过了对传统数据库的依赖。这是极速交易场景下的最优解。

六、四种路线的十维深度对比

#

七、四种路线的底层逻辑对立

#

7.1 “存算分离” vs “融合数据库”

#

顶点和金证都选择了存算分离架构，但实现路径不同：

• 顶点：HyperDB 只做日间实时计算，持久化完全交给外置国产/开源数据库——这是一种"极致专业化分工"。
• 金证：KMDB 在 K-LDP 平台内与 HARE、KGMS 协同，但清算场景仍采用存算分离——这是一种"平台内分工"。

恒生则走了相反的路径——LightDB 通过多存储引擎（LightMEM/LightTP/LightAP）在一个数据库内完成 OLTP、内存计算、OLAP 的全部工作，是一种"融合化集成"。

7.2 “彻底去 O” vs “兼容 Oracle”

#

• 顶点：彻底去 O，HyperDB 完全替代 Oracle，A5 是行业首个实现全面去 IOE 的核心交易系统。
• 恒生：LightDB 兼容 Oracle、MySQL，保留 PostgreSQL 核心性能——这是为存量生态平滑迁移设计的"兼容式去 O"。
• 金证：KMDB 与多种磁盘数据库同步，券商可自主选择国产基础设施——这是"开放式去 O"。

7.3 “数据库驱动” vs “消息驱动”

#

前三种路线本质上都是"数据库驱动"——以内存数据库为核心构建交易系统。华锐则完全跳出这个范式：以消息总线 AMI 为核心，内存计算直接在消息层完成。

这反映了两种不同的工程哲学：

💡 数据库驱动派（顶点/金证/恒生）：相信"数据"是核心，通过内存数据库解决性能问题。

💡 消息驱动派（华锐）：相信"流转"是核心，通过消息总线解决性能问题。

八、选型决策：四类券商的推荐路径

#

8.1 头部券商（千万级客户，全面去 O 诉求）

#

推荐：顶点 A5 Max 路线

• 中信证券选择 A5 Max 完成亿级客户迁移，证明了该路线在超大规模下的可行性。
• HyperDB 彻底去 O，符合头部券商自主可控的最高诉求。
• 存算分离架构在鲲鹏、海光混合环境下线性扩展。

8.2 整体柜台新建（中大型券商，低时延诉求）

#

推荐：金证 FS2.5 + KMDB 路线

• K-LDP 平台三件套协同，HARE 端到端时延低于 1.1 微秒。
• FS2.5 已在中金、银河、广发等头部券商整体柜台项目批量落地。
• 原生信创，无需额外改造，券商可自主选择国产基础设施。

8.3 存量生态平滑迁移（恒生存量客户）

#

推荐：恒生 UF3.0 + LightDB 路线

• LightDB 兼容 Oracle、MySQL，存量迁移成本最低。
• UF3.0"敏稳双态"架构支持信创平滑过渡。
• 招商证券千万级客户全量切换已验证可行性。

8.4 极速交易/量化订单（专项场景）

#

推荐：华锐 ATP T7 路线

• 系统内部处理时延小于 80μs，单节点混合压力吞吐量大于 160 万 TPS。
• 国泰君安交易速度提升 20 倍以上。
• 超百套生产系统上线运行。

8.5 “核心+极速"双引擎架构（头部券商趋势）

#

越来越多头部券商选择"核心交易系统+极速交易系统"双引擎架构：

核心交易系统（承载全业务）
    ├── 顶点 A5 Max / 金证 FS2.5 / 恒生 UF3.0
    └── 内存数据库：HyperDB / KMDB / LightDB

极速交易系统（承载量化订单）
    └── 华锐 ATP T7 + AMI 消息总线

这种"核心+极速"的双引擎架构，正在成为头部券商的核心系统标配。

九、2027 终局判断：四种路线的攻守之道

#

9.1 顶点 HyperDB：攻"彻底去 O"高地

#

顶点的路线最为激进，但也最具自主可控说服力。A5 Max 在中信证券完成亿级客户迁移，证明了"存算分离+HyperDB"路线在超大规模下的工程可行性。随着 2027 信创大限逼近，彻底去 O 的诉求将推动更多头部券商选择顶点路线。

9.2 金证 KMDB：守"低时延平台"阵地

#

金证 KMDB 的护城河不在于内存数据库本身，而在于 K-LDP 低时延平台的完整生态——KGMS+HARE+KMDB 三件套的协同效应。HARE 端到端时延低于 1.1 微秒，这是单纯的 KMDB 无法提供的整体价值。金证路线在整体柜台新建项目中具备领先优势。

9.3 恒生 LightDB：守"存量生态"基本盘

#

恒生 UF3.0 已累计服务客户突破 5000 万，11 家券商完成上线，签约合作机构超 20 家。LightDB 的 Oracle 兼容能力，使其成为恒生存量客户平滑迁移的最优选择。兼容式去 O 虽然不够彻底，但是最稳的路线。

9.4 华锐 ATP T7：攻"极速细分"赛道

#

华锐不走"替代 Oracle"的路，而是走"绕开数据库"的路。在量化交易、极速订单等细分赛道，华锐具备不可替代性。超百套生产系统上线运行，证明了消息驱动路线的商业可行性。

9.5 四强共存的根本原因

#

四种路线不是零和博弈，而是按场景分层共存：

极速交易层（微秒级） ──→ 华锐 ATP T7（消息驱动）
       ↓
核心交易层（毫秒级） ──→ 顶点 A5 / 金证 FS2.5 / 恒生 UF3.0
       ↓
持久化存储层 ────────→ 国产关系型数据库（OceanBase/TDSQL/Kingbase 等）

每一层都有最合适的技术路线，每一家厂商都在自己最擅长的层级建立了壁垒。

十、结语：内存数据库路线的"信创哲学”

#

回到文章开头的核心问题——顶点 HyperDB、金证 KMDB、恒生 LightDB、华锐 ATP T7，四种内存数据库路线究竟有何本质差异？

💡 四种路线，四种哲学：

• 顶点 HyperDB：用"存算分离+彻底去 O"回答"如何完全摆脱 Oracle"。
• 金证 KMDB：用"低时延平台三件套协同"回答"如何构建原生信创的整体柜台"。
• 恒生 LightDB：用"HTAP 融合+Oracle 兼容"回答"如何平滑迁移存量生态"。
• 华锐 ATP T7：用"消息驱动+内存计算"回答"如何实现微秒级极速交易"。

这四种哲学没有绝对优劣，只有场景适配。顶点适合彻底去 O 的头部券商，金证适合新建整体柜台的中大型券商，恒生适合存量平滑迁移，华锐适合极速交易细分场景。

2027 信创大限前，四种路线将共同推动一件事——让中国证券核心交易系统的"心脏"，跳动的全部是中国自己的代码。当东吴证券的交易时延从 10ms 降至 <1ms，当华锐 ATP T7 在国泰君安实现交易速度提升 20 倍以上，当招商证券 UF3.0 完成千万级客户全量切换——这些数字背后，是四种内存数据库路线共同书写的中国证券信创史。

📌 博主注：内存数据库路线的选择，本质上是券商 CIO 对"自主可控程度"与"迁移风险"的权衡。顶点赌"彻底去 O"的长期收益，金证赌"平台化协同"的整体价值，恒生赌"兼容平滑"的存量红利，华锐赌"极速专精"的细分壁垒。四种赌注，四种未来——而历史会证明，在 2027 信创大限的考场上，没有错误的路线，只有不适合的场景。