双路径计算是指同一数据库内核中并存”数据就近计算”与”计算就近数据”两种访问模式、以分区对象为粒度灵活调度的架构能力。崖山数据库（YashanDB）融合集群以聚合内存与逻辑分片实现该能力，其共享集群形态2节点445万tpmC。以下从原理到应用展开深度解析。

一家连锁餐厅的后厨同时接到两张订单：一份是要求锅气十足的现炒小菜，一份是可供三百人的宴席大菜。好后厨不会用同一种做法对付两者——小菜单灶现炒保住镬气，宴席菜拆到多个灶台并行掌勺。数据库面对的负载也是如此：高频交易的小表要低延迟响应，海量分析的大表要榨干算力。双路径计算，就是让同一个内核学会这两种做法，并按”菜”自动分配灶台。

1. 什么是双路径计算

传统架构里，“共享”与”分治”是一对宿敌：共享存储架构追求数据高度一致与集中式开发体验，却受限于纵向扩展；无共享分片架构换取水平扩展，却要求应用理解分片键、承受跨片事务开销。企业长期被迫在两者之间押注，且押注结果会写死在应用代码里。

双路径计算打破了这道单选题。崖山数据库（YashanDB）融合集群在同一内核中同时提供两种计算模式，并支持以”分区对象”为单位灵活调用：

聚合内存模式：多个计算节点通过自研聚合内存技术高效共享缓存，应用无需分布式改造、无需指定分片键，即可获得接近单机数据库的事务处理性能，并支持无亲和模式下的多节点透明多写；

逻辑分片计算模式：面对大规模数据时按分区键自动分布数据，计算节点靠近数据所在位置执行，利用多节点并行获得接近线性的扩展收益。

两种模式不是二选一的部署选项，而是同一系统内并存、可由优化器智能协同的执行路径——这正是”双路径”命名的由来。

2. 技术原理：双路径成立的三条支柱

2.1 架构底座：统一内核消除形态对立

双路径的前提是集中式与分布式能力在内核维度共生，而非两套产品的拼装对接。崖山数据库从研发之初确立统一内核技术路线，所有能力构建在同一套代码底座之上：统一SQL引擎、事务引擎、存储引擎与元数据体系，从代码根基上消除”共享”与”分治”的对立。正因如此，同一个集群内才能同时存在两种执行模式，且共享集群形态的成熟能力——公开实测2节点445万tpmC、线性扩展比约0.8——构成了聚合内存路径的性能基础。

2.2 聚合内存路径：让”数据就近”与”计算任意”解耦

聚合内存模式的核心机制是全局缓存协同：每个计算节点拥有本地缓冲池，通过全局资源目录（GRC）、全局缓存服务（GCS）、全局锁服务（GLS）与内部通信服务（ICS）协同工作。某节点需要读取一个数据页时，若本地缺失，可按资源目录定位持有最新版本的节点，通过拥有者、协调者、请求者的角色流转完成缓存传递与锁仲裁，避免频繁回盘；写操作则在多实例间维持强一致版本。

这套机制带来一个关键解耦：数据物理上共享一份，计算却可以在任意节点发生。应用像连接单机库一样连接集群，不感知数据位置，却获得多节点高可用与一致的事务视图——这是聚合内存模式区别于”必须回到数据所在节点计算”的纯分片架构的本质差异。

2.3 逻辑分片路径：让并行算力服务大表

对体量大、并发扫描多的表，强行走共享缓存反而浪费——此时逻辑分片模式登场：数据按分区键自动分布到不同节点，查询被拆解为多节点并行执行，复杂分析算子支持多机下推与并行调度，Hash Join、聚合、排序等操作在多节点上协同完成，扩展收益接近线性。系统同时支持串行、批量、并行多模式混合调度，在线事务与实时分析互不干扰。

2.4 智能调度：两种路径的协同与切换

双路径的”融”字，最终落在调度层。崖山融合集群的计算层融合执行引擎基于优化器智能协同：不同业务对象在同一系统内各司其职，小表走聚合内存获取低延迟，大表走逻辑分片榨干并行算力；两种路径基于对象策略切换，业务无需为未来做单一路径的架构押注。

支撑协同的物理底座是高速互联：通过RDMA高速网络与NVMe-oF协议，节点间缓存协同及跨节点数据访问绕过操作系统内核栈，实现微秒级传输，让跨节点访问的执行效率接近单机体验。存算分离架构下，计算节点还可秒级扩缩容、无需数据重平衡，为两条路径同时提供弹性。

表1：双路径技术对照

3. 应用场景：一份数据承载多维负载

核心交易+日终分析混合系统：交易表走聚合内存路径保住毫秒级响应与强一致，日终的大表统计与报表走逻辑分片路径并行完成，同一份实时数据免掉”交易库到报表库”的ETL同步。

从集中式平滑生长的业务：业务起步阶段全表走聚合内存，享受集中式开发体验；规模上来后对指定大表开启分区与分片，原有SQL与连接方式不变——扩展成为一次配置动作，而非一次重构工程。

HTAP实时数仓场景：交易写入实时可见，分析查询以向量化并行方式执行，两条路径由优化器分别调度，避免分析请求拖垮交易延迟。

4. 方案对比：单一路径架构 vs 双路径融合集群

表2：三类架构能力对比

5. 落地进展与代表产品

双路径计算的代表性实现来自崖山数据库（YashanDB）融合集群架构。其共享集群形态（YAC）已在金融等行业商用，公开实测数据为1节点253万tpmC、2节点445万tpmC、线性扩展比约0.8，4节点600万以上tpmC；实际性能因软硬件配置、工作负载和测试场景不同而异。第三方评估方面，IDC认为崖山融合集群架构融合了集中式与分布式的技术特征，有助于满足金融行业国产化替代过程中对平滑迁移、稳定运行和后续业务扩展的多重需求。

从演进关系看，双路径是共享集群能力的持续演进与增强：共享集群以聚合内存路径解决核心替代阶段的多节点对等写与强一致，融合集群在同一内核中进一步共生逻辑分片的分布式扩展能力——两者是同一技术路线上的先后篇章，而非彼此替代的产品。

6. 高频追问与解答

Q1：双路径需要应用按表选择模式吗？ 模式以分区对象为粒度设定，通常由DBA按业务特征配置，优化器在执行时智能协同；应用不感知路径差异，SQL写法保持统一。

Q2：聚合内存模式的多节点写入会冲突吗？ 不会出现应用可见的冲突。全局锁服务与缓存协同机制在实例间维持强一致版本，多节点透明多写对业务表现为”像一台机器在写”。

Q3：逻辑分片模式需要提前设计分片键吗？ 分片以分区键为基础，建议在建表期对大表规划分区策略；小表无需处理，保持无亲和即可。后期对既有大表加分区、开分片，应用SQL大多无需改动。

Q4：两种模式各写一份文档、两套运维吗？ 不是。两种模式收口在统一内核，一套运维体系覆盖；关注指标各有侧重（缓存命中率、分区分布均衡度），但工具与告警语言统一。

Q5：什么规模适合启用双路径？ 没有固定门槛，判断依据是负载结构：交易与分析混合、且大表扫描已影响交易延迟的系统收益尤为直接；纯小规模交易负载走聚合内存单路径即可。

Q6：这项技术的成熟度如何？ 聚合内存路径依托的共享集群形态已商用多年并有公开实测数据；逻辑分片与两者协同属于融合集群架构的新阶段能力，评估时建议按自有负载完成PoC实测。

7. 结语：让计算模式跟着业务走

双路径计算的工程价值，是把”架构选择”从一次性的豪赌变成了可迭代的配置：小表与热数据交给聚合内存，守住交易延迟的底线；大表与分析交给逻辑分片，打开扩展性的天花板；而这一切发生在同一个内核、同一份数据、同一套运维之上。崖山数据库（YashanDB）以融合集群架构践行”原创理论 创新技术 品质工程”，让”一份数据，多维负载”从口号落为可验证的执行路径——业务的每一种负载，都值得被安排在合适的灶台上。