证券核心系统的国产化替代，难点从来不是能不能建表。真正难的是只用一套数据库要同时承接交易、报盘、盘前盘后批量、数仓供数这四类负载，过去Oracle被广泛应用也是因为这个原因。
它们的延迟容忍度、锁行为、节奏完全不同，本文我会用一个脱敏后的案例，说明怎么用一套支持多种兼容模式的国产数据库，通过多实例部署把这四类负载隔开。
一、先区分五类业务负载
在讨论部署方式之前，需要先说明这几个系统在证券业务里各自承担什么角色，以及它们对数据库的需求为什么不同。
主交易柜台，是面向营业部和客户的委托受理与账务处理系统。客户下的每一笔普通交易指令，从接收、验资验券、冻结、报盘到成交回报和日终清算，都要经过主交易柜台。它的负载特征是交易时段持续的高频事务读写，每一笔委托都涉及多个表的行级锁和事务提交，对一致性和延迟确定性的要求最高。盘中任何一次非预期的尾延迟，都可能表现为客户委托确认变慢或成交回报延迟。
极速交易柜台，面向的是对延迟极度敏感的专业交易客群，比如量化策略、高频交易和做市业务。它的核心设计是把撮合和报单逻辑放在内存里完成，热点数据在盘前一次性加载到内存，盘中不再逐笔访问数据库。它的数据库依赖被压缩到盘前加载基准数据和盘后归档流水两个窗口。盘中它几乎不碰数据库，但盘前加载窗口对I/O带宽和内存吞吐的瞬时要求极高，窗口一旦被压缩，整个盘中零依赖的前提就会被侵蚀。
合规检查服务，承担的是交易前和交易后的合规校验，比如反洗钱、客户风险、异常交易识别。它在盘中有查询，也有落库，但它的查询通常不是每一笔委托的必经路径，更多是批量扫描和规则匹配。它对延迟抖动的容忍度高于交易核心，但它的数据不能丢、结论要可审计。
实时风控引擎，和合规检查服务不同，实时风控需要在盘中以低延迟判断持仓风险、自成交风险和限额占用，它的规则引擎同样跑在内存里，盘前从数据库加载风控参数和持仓基准，盘中不逐笔查询数据库。它和极速交易柜台共享盘中零依赖数据库的架构前提，但它的盘后结果落库和盘前参数加载是独立的负载。
报盘接口组件，是主交易柜台和交易所之间的桥梁。主交易柜台把委托写入接口表，报盘接口组件高频轮询接口表，把新委托报送给交易所，再把交易所的回报写回接口表。它的负载特征是持续的高频小事务轮询，对接口表的锁行为和事务可见性极其敏感。轮询节奏一旦漂移，委托上报时效就会出问题。
除了这些和交易相关的核心业务，还要再加上客户主数据服务和合规辅助服务，以及分析数据平台，都是证券公司日常运营必备的系统。
介绍完这些业务相关内容，我们接下来开始拆解原来方案的不足之处。
二、改造前的数据流与约束
改造前，各系统按数据库类型自然分布，因为来自不同的供应商，所以使用的数据库也很多元化。
交易核心、客户主数据服务和合规检查服务使用 Oracle；合规辅助服务使用 PostgreSQL；报盘接口组件使用 SQL Server；极速交易、极速风控的盘前盘后底座以及分析数据平台的供数层使用 MySQL。分析数据平台承担ODS接入和DWD整合视图，向交易终端、经营分析分析、合规报表和实时风控引擎供数。
核心约束有三条：
交易时段不可中断：交易核心和客户主数据服务的事务延迟必须可预期，不能因为其他系统的批量操作出现尾延迟抖动。
报盘轮询的锁行为敏感：报盘接口组件以高频小事务轮询接口表，接口表的可见性延迟和锁争用会直接影响委托上报时效。
极速交易与极速风控盘中不依赖数据库：两者依赖内存撮合和内存规则引擎，数据库只负责盘前加载基准数据、盘后归档流水和结果。
这三条约束决定了不能用一套数据库实例同时承接所有负载，兼容模式不能在一个实例内在线切换，负载特征不同的系统必须做隔离。这些需求我们能否用一个国产数据库都接住？
答案是肯定的，这次的主角是电科金仓。
三、当前四种数据库栈，不足在哪里
改造前的分布，从每个系统用什么库的角度看是合理的：交易核心、客户主数据服务、合规检查服务用 Oracle；合规辅助服务用 PostgreSQL；报盘接口组件用 SQL Server；极速底座和分析数据平台供数源用 MySQL。每个选择都有历史原因，单独看都不算错。
但四套栈并行，在证券核心系统里会积累三类结构性成本，而且这三类成本不会因为每个库都跑得”而消失。
第一类成本：故障定位被切成了四份。 交易链路上一笔委托出了问题，DBA要同时面对Oracle的等待事件、SQL Server 的锁等待、MySQL的慢查询日志和PostgreSQL的活动会话视图。四套监控体系、四套诊断逻辑、四套性能基线，故障定位时间不是取最长的那一个，而是在四个方向之间来回切换的总和。券商核心系统对故障恢复时间的要求是分钟级甚至秒级，四套栈的定位成本会直接吃掉这个窗口。
第二类成本：资源池被切成了四份，但负载不是按库类型分布的。 Oracle实例在盘中持续高压，SQL Server的报盘接口库在盘中高频轮询，MySQL的极速底座在盘前盘后脉冲式爆发，PostgreSQL的合规辅助服务全天低频。四套栈意味着四组独立的资源池，每一组都要按峰值预留容量，而峰值发生的时间点并不重合。结果是总资源利用率被四组峰值叠加拉低，运维却要为四套栈分别做容量规划。
第三类成本：迁移和替换的路径被切成了四份。 国产化替代不是换一个库就结束，它要解决的是换完之后，四套栈的运维逻辑能不能收敛成一套。如果Oracle换成A产品、SQL Server换成B产品、MySQL换成C产品，替换完成之后仍然是四个厂商、四套工具链、四种故障处理方式，只是把国外四栈换成了国产四栈，结构性成本一点没少。
所以替换的动机，不是某个库性能不够或某个库功能缺失，而是需要找到一个底座，让四种兼容模式在同一个软件体系里并存，同时让谁该独立、谁该共享这件事由负载特征决定，而不是由数据库品牌决定。
这才是我们用金仓需要解决的问题。
四、金仓为什么能接住
金仓能接住这套场景，靠的不是一个实例兼容四种模式，而是两件事叠在一起：兼容模式在同一个软件体系里收敛，实例边界把不同负载隔开。
先看兼容模式。 KingbaseES V9具备Oracle、MySQL、SQL Server、PostgreSQL四种兼容模式，每种模式是在初始化阶段通过参数选定的内核行为，一个实例初始化成某种模式之后，就在该模式下运行。这意味着，原来分布在四个数据库品牌上的兼容性需求，可以在同一套金仓软件上、通过不同实例来承接，不需要为每种模式单独引入一个独立产品。迁移工具链也是同一套，用KDMS做评估扫描，用KDTS做数据迁移，用KFS做增量同步。四种兼容模式没有消灭实例数量，但它把四个厂商、四套工具链收敛成了一个软件体系、多种模式。
再看实例边界。 金仓的实例级多租户，每个租户独占一个数据库实例，配合KEMCC统一纳管和做CPU、内存、I/O的隔离。
这恰好给了上面那个问题一个可落地的答案，不是所有系统都需要独立集群，也不是所有系统都应该塞进同一个实例。 交易核心、报盘轮询、极速底座这三类负载，延迟确定性不能有外部变量，用独立主备集群；合规辅助服务和供数源这两类负载，延迟抖动可以被业务容忍，进多租户池共享资源组。
换句话说，金仓接住的不是四个库的语法，而是4个库背后的四类负载，能不能在一个软件体系里被分开管。
五、从四套栈推到一个底座
接下来我们开始规划，之前的五个实例怎么分配资源，以及为什么要这么做。
实例1：Oracle 兼容模式，主备集群
承接交易核心、客户主数据服务、合规检查服务。三个系统原来都在Oracle上，存量存储过程、包、触发器和 Oracle 特有数据类型与业务逻辑深度耦合，选 Oracle 兼容模式迁移改造量最小。
架构用金仓读写分离集群KingbaseRWC，主节点承接交易核心的写入、客户主数据服务在盘中的高频读取以及合规检查的落库结果；合规检查的批量扫描和规则匹配查询分流到只读备节点，不竞争主节点上交易写入的 WAL 刷盘和行锁资源。主备之间采用同步复制，主节点等待备节点确认WAL日志后才提交事务，满足交易链路不丢数据的前提。查询路由由 JDBC 驱动在语句级别完成，读语句发备节点、写语句和事务发主节点，合规检查不需要改代码就能走备库。
实例2：SQL Server 兼容模式，主备集群
承接报盘接口组件，核心是委托表、回报表、状态表。组件原来跑在SQL Server上，高频轮询接口表做小事务扫描和状态更新，接口表的结构和轮询逻辑依赖SQL Server的行为语义，选SQL Server兼容模式避免行为偏差。
架构用金仓原生高可用集群，一主多备，基于日志同步复制保证主备数据强一致，故障检测到切换在秒级完成，对应用透明。独立部署的原因不是“高可用需要”，是轮询负载的调优目标只服务于接口表的锁等待和事务可见性节奏，不与其他负载共享实例的调优方向。
实例3：PostgreSQL 兼容模式，多租户池
承接合规辅助服务，主要是客户身份识别类辅助数据。原来跑在PostgreSQL上，每日同步一次、盘中低频查询，不在交易关键路径上。选PostgreSQL兼容模式是因为存量数据结构基于PG的类型系统和语法。
架构用金仓实例级多租户，每个租户独占一个独立数据库实例，给每个实例设定CPU、内存、I/O的硬上限，防止同池实例之间的资源争抢。合规辅助服务进池不是因为不重要，是因为它的延迟抖动可以被业务容忍，同步晚几分钟、查询晚几秒不影响委托和账务，不需要像实例1、2、4那样独占物理资源。
实例4：MySQL 兼容模式，主备集群
承接极速交易柜台和极速风控引擎的盘前/盘后底座。撮合和风控规则跑在内存里，数据库只在盘前加载基准数据和风控参数、盘后归档流水和结果。选 MySQL 兼容模式是因为底座原有的数据结构和批量写入方式基于MySQL行为。
架构用独立主备集群，同步复制保证盘前加载的数据和盘后归档的结果不丢。独立部署的关键不在高可用形态，在盘前窗口的独占性，极速底座的负载是脉冲式的，盘前和盘后集中爆发，如果和供数源共用实例，盘前加载窗口可能撞上早间批量查询。
实例5：MySQL 兼容模式，租户池
承接分析数据平台的供数源，也就是ODS接入区。原来也跑在MySQL上，负载是全天候增量写入加上ODS/DWD的持续批量查询。选MySQL兼容模式是因为接入区的表结构和增量写入逻辑基于MySQL语法。
架构和实例3同属一个实例级多租户池，和实例4拆开、放进多租户池，是因为它和极速底座的负载节奏相反，一个是全天候持续批量，一个是盘前盘后脉冲。拆开之后，实例4守盘前窗口，实例5和合规辅助服务共享标准资源组，不需要独占物理资源。
六、五个实例怎么协同
五个实例不是五套孤岛。整套架构跑起来之后，盘中真正连数据库的链路只有三条，盘前盘后各有一条批量链路，其余全是静默或低频。
盘中三条链路：
交易核心、客户主数据服务、合规检查服务写实例1。 交易核心的委托写入和客户主数据的验资验券读取走主节点本地缓冲区，合规检查的落库写回主节点，批量扫描查询由驱动层路由到只读备节点。这条链路是交易账务的底座，盘中持续高压。
报盘接口组件轮询实例2。 主交易柜台把委托写入接口表，报盘接口组件高频轮询委托表，向交易所接口报盘，交易所回报写回回报表，报盘接口组件再轮询读取回报、回写内存。这条链路是持续高频小事务，对锁行为和事务可见性最敏感。
合规辅助服务低频查实例3。 每日同步一次客户身份识别类数据，盘中偶尔有查询，不在交易关键路径上。
盘中静默或只接写入的：
实例4（极速底座）盘中基本静默。 极速交易柜台和极速风控引擎只操作内存，盘中不连任何数据库。
实例5（供数源）盘中只承接KFS增量写入，不参与交易判断，分析数据平台的ODS/DWD批量查询主要在盘后和早间。
盘前盘后两条链路：
实例4 ↔ 极速交易/极速风控。 盘前实例4向极速交易柜台加载基准数据和账户快照、向极速风控引擎加载风控参数和持仓基准；盘后极速交易柜台把流水批量归档回实例4，极速风控引擎把风控结果落库回实例4。这是脉冲负载，集中在盘前和盘后两个窗口。
实例1和实例4 → KFS → 实例5 → 分析数据平台。 KFS从实例1和实例4抽取增量变更，写入实例5的ODS接入区，实例5向分析数据平台供ODS，分析数据平台在DWD整合视图上做批量查询和合规报表，再向交易终端、经营分析、合规检查服务供数。这是持续批量负载，全天候运行。
七、迁移顺序：先非交易链路，最后动交易核心
几个实例不可能全部一次迁移完成，一定是有一个顺序，先从哪个开始？我也给出我自己的看法，可供参考。
五个实例不是同一天割接的。迁移顺序的原则只有一条，先迁不碰盘中交易的，再迁只碰轮询的，最后迁交易写入的。 风险从低到高，每一步都有回退窗口。
第一步：实例3和实例5先迁。 合规辅助服务和供数源不在交易关键路径上，延迟可容忍，最坏情况是同步晚几分钟。这一步的目的是验证兼容模式能不能覆盖存量语法、KFS增量链路能不能稳定、多租户池的配额能不能卡住资源。跑通了，后面几步才有底。回退成本最低，即使出问题，影响的是辅助数据和批量查询，不碰委托和账务。
第二步：实例4再迁。 极速底座只做盘前盘后，不碰盘中交易。这一步的验证重点是盘前加载窗口和盘后归档吞吐：全量基准数据加载时间是否留足余量，盘后流水批量归档会不会超窗口。跑通之后，极速交易和极速风控的盘中零依赖前提才算真正立住。
第三步：实例2单独迁。 报盘接口组件只服务轮询，单独割接，不和交易核心混批。这一步必须用真实轮询压力验证，不能只看语法通过率。验证项是接口表在写入峰值时的锁等待分布和事务可见性延迟——如果轮询扫描把写入路径堵住，委托上报时效会直接出问题。这一步的回退窗口要留足，报盘链路一断，委托上不去交易所。
第四步：实例1最后迁。 交易核心、客户主数据、合规检查一起割接，是风险最高的一步。割接前必须完成两件事，KingbaseRWC主备切换演练，确认故障切换时间和数据一致性；只读备节点分流验证，确认合规检查的批量扫描压上去之后，备节点复制延迟仍在毫秒级，不拖累主节点写入。这一步没有先迁一部分的选项，交易账务的写入路径必须整块切换。
八、尾声
如果只是单纯的用一套软件替换4套，那其实我没有必要写这篇文章。
这套架构说到底就干了一件事，把每类负载放到它该待的位置上，然后让它们互不打扰。 交易核心的写入路径独占主节点，合规检查的扫描查询被赶到只读备节点上去跑。报盘接口组件自己守着一个实例，专门伺候那个高频轮询的锁。极速交易和极速风控盘中根本不碰数据库，但盘前加载那半小时的窗口，谁也别来抢。合规辅助服务和供数源不是不重要，是它们晚几分钟出结果天塌不下来，所以放进池子里共享资源，省下来的物理资源留给真正不能抖的系统。
迁移顺序也不是拍脑袋排的。先拿不碰交易链路的开刀，把兼容性和KFS链路跑顺；再动极速底座，验证盘前窗口撑不撑得住。报盘接口单独割，用真实轮询压力把锁等待摸清楚。最后才动交易核心，主备切换演练做完、备节点分流验证完，才敢切。每一步都有回退窗口，每一步都知道自己在验什么。
截稿时，已经看到了金仓发布V10，探索完V10新特性，我们再来看看有没有别的可以做。
