YashanDB V23.5：弹性伸缩，永远在线！崖山共享集群YAC实战分享

最新推荐文章于 2025-12-16 15:09:47 发布

原创最新推荐文章于 2025-12-16 15:09:47 发布 · 726 阅读

4 ·

CC 4.0 BY-SA版权

文章标签：

#数据库 #崖山数据库 #YashanDB #YashanDB V23.5 #国产数据库

YashanDB V23.5 专栏收录该内容

5 篇文章

订阅专栏

11月26日，YashanDB V23.5线上发布会于线上举办，YashanDB解决方案首席架构师廖传军在线上分享中，跳出纯技术原理的讲解，以两个典型行业实战案例、两种核心架构对比，用真实数据和落地经验，揭秘了崖山共享集群YAC如何解决“弹性伸缩”与“永远在线”两大核心难题。

本文将此次分享的精华内容整理成文，希望能为正在考虑数据库国产化与架构升级的企业提供参考。

弹性伸缩，保障业务增长不设限

典型场景1：消费贷，适配互联网+业务节奏

该场景属于典型的互联网时代场景，类似于白条、花呗等实时信贷服务，用户在购物后需实时获得授信结果。业务具备强实时性、促销峰值高、弹性需求迫切等特点。

（1）业务诉求

时效性要求高：用户下单后需实时推送授信结果，延迟将直接影响转化率。
业务敏捷性要求高：每年会有若干次促销活动，大促期间流量激增，需快速弹性扩缩容。
按需扩缩容：IT架构需快速适配大促期间流量波动，避免为应对峰值长期浪费资源，节省时间和成本。

该客户原使用Oracle单机主备架构，处理能力受限；但Oracle RAC授权成本高昂，服务支持体验差，且技术支持多绕到印度，响应慢、沟通不畅。此外，在选型过程中，客户曾测试某国产分布式数据库，不但应用改造周期长，且发现其“伸出去容易缩回来难”，在业务高峰后缩容风险高、操作复杂，无法满足消费贷场景的弹性需求。

（2）why崖山共享集群YAC?

真正的弹性伸缩：支持计算节点与存储节点独立扩缩，且扩缩过程对业务影响小，风险可控；
代码几乎零修改：仅需调整JDBC连接串，应用层无需大规模重构，降低迁移成本和风险；
本土化服务支持：架构师团队+研发团队直接对接，问题响应速度远超Oracle的海外服务。

（3）YashanDB解决方案

很多用户在使用共享集群时会遇到“1+1≠2”的性能损耗问题，基于用户的痛点，YashanDB进行了如下优化：

首先，在不改应用数据结构的前提下，新增虚拟ID实现数据分区，避免了数据插入时因索引块冲突导致的性能瓶颈；其次，采用应用服务器组部署模式，让应用服务器与对应的数据分区、实例精准绑定，配合前端路由分发客户请求，确保访问路径最优；同时，针对金融客户的高安全需求，采用两地部署方案，配置最大保护模式与仲裁节点，兼顾业务连续性与数据安全性。

（4）项目收益：3倍性能提升，成本直降50%+

在崖山共享集群YAC两节点下，性能达到原Oracle系统的3倍以上；
总体拥有成本（TCO）较Oracle RAC降低超过50%；
支持业务无缝伸缩，适应促销等高并发场景。

典型场景2：民生服务，适配快速业务变更+服务永续诉求

第二个案例来自某公用事业单位，业务涵盖水、垃圾、污水处理等计费系统。随着“互联网+”与智能化改造，业务变更频率加快，计费周期从按月转向按日，对系统处理能力与弹性提出更高要求。

（1）业务诉求

业务变更快，计费周期、计费时间持续调整，需要架构快速适配；
公共服务属性要求业务绝对不能中断，保障民生服务连续性；
按需扩缩容，在业务增长时快速提升处理能力，业务低谷时缩回处理能力。

原有Oracle数据库版本老旧，无法平滑升级；授权费用昂贵且服务能力不足，难以满足业务发展需求；更棘手的是系统对接复杂，涉及多个上下游系统，数据交换格式多样，迁移与集成难度极大。

（2）why崖山共享集群YAC?

弹性伸缩能力：适应业务频繁变更与流量波动，无需重构架构，轻松适配按日/按小时的高频计费需求；
架构平滑替代：几乎无需修改原有应用代码，兼容客户原有架构体系，降低迁移与集成风险；
处理能力大幅提升：实现十倍批处理计费处理能力的目标，并支持并行批处理与数据分析。

（3）YashanDB解决方案

该项目的核心难点在于关联系统繁多，上游关联流程审批系统、智能设备平台等，下游衔接财务系统、省/市财政系统等等，涉及多种连接方式与数据格式的对接。

崖山共享集群YAC凭借强大的兼容性与集成能力，实现了全链路平滑适配：通过JDBC实现数据库访问，Kafka完成数据同步，NBU保障备份恢复；同时集成监控告警、安全审计、APM等工具，与客户的开发和运维平台无缝对接。值得一提的是，YAC无需分库分表，无需分布式应用改造，仅通过数据架构优化（如分区技术）和应用部署优化就实现了线性性能提升，但应用代码无需修改。

（4）项目收益：10倍吞吐+零中断，合规运维双优化

系统处理能力较原有架构提升10倍，成功支撑按日/按小时的高频计费业务；
实现业务零中断运行，满足公共服务高可靠性要求，保障民生服务连续性；
基于全国产技术栈部署，符合安全合规要求，同时简化运维流程，降低整体维护成本。

永远在线，筑牢业务连续性防线

“永远在线”是核心业务的生命线，崖山共享集群YAC提供“同城双活读写分离”与“同城双中心双活双写”两种架构，前者主打高性价比与读压力分流，后者聚焦顶级容灾与读写并发，企业可按需选择。

一、同城双活读写分离，有效避免备中心故障影响主中心

高可用不能脱离业务连续性原则，YashanDB构建高可用能力的核心思路是“保生产、降影响”。基于该思路，YashanDB制定了同城双活读写分离架构下的9大设计原则：

故障恢复优先级：本地>同城>异地；
节点故障恢复，应在同一数据中心内完成；
同城中心故障，不应影响生产中心的业务运行；
异地灾备中心的故障，不影响生产中心的业务运行；
数据中心之间的网络故障和网络抖动，应不影响生产中心的业务运行；
网络延迟增加的情况下能降级（最大保护降级为最大性能）；
RPO=0，需在不影响生产中心业务运行的前提下实现；
绝大部分故障场景下RTO＜30秒，实际值取决于故障类型、系统负载等；
切换后自动维持数据复制链路。

YashanDB实战表现：

YashanDB同城双活读写分离架构如下图所示，部署主备两个集群，备中心仅承担读请求，主备之间采用最大可用模式，避免备中心故障影响主中心。

此外，为验证架构在真实业务场景的稳定性，我们基于客户实际峰值负载的数十倍压力，模拟了生产环境中常见的多种故障场景，从单节点故障到全中心故障，覆盖数十个故障场景，全面测试架构的容错能力与恢复速度，具体测试结果如下图所示:

二、同城双活双写架构：一套集群跨双中心，两中心均可读写

与“读写分离”架构不同，“双活双写”架构中，同一套集群跨两个数据中心部署，两端均可读写，通过底层存储层实现数据同步。

同城双活双写架构的核心是解决存储同步和脑裂问题，YashanDB通过仲裁节点判断存储状态，集群动态心跳检测，确保跨中心数据一致性。

YashanDB实战表现：

以下是YashanDB近期的实战数据，基于40公里光纤的真实跨中心环境测试，集群部署为“3节点+3节点”跨双中心，测试压力为客户实际峰值负载的数十倍。

“大家需要明确一点，上述所有性能数据都是生产环境配置，不是跑分结果。”廖传军强调，切勿混淆其与宣传海报上的理论峰值。性能表现取决于硬件、网络、存储配置，YashanDB的优势是最小化同步复制带来的性能损耗和保障客户典型负载下RTO<30秒（具体的切换时间和具体场景相关）。

三、架构选型对比：读写分离vs双活双写，如何选择？

架构选型无绝对优劣之分，关键在于适配性。以下是两种同城双活方案的核心差异，建议企业根据业务特点、容灾等级、预算等因素综合决策。

此外，集群节点升级维护如下所示：

读写分离架构：小版本补丁可集群内滚动升级，大版本需集群间滚动升级；
双活双写架构：小版本、补丁可节点级滚动升级，大版本需配合逻辑复制软件。

选型建议：遵循4大核心价值+1个必做动作

国产数据库选型应要找到既适配自身业务特性，又能兼顾性能、弹性、高可用与低迁移风险的解决方案，需结合业务场景需求、容灾等级要求、成本预算以及现有架构兼容性等多维度因素综合考量。崖山建议可按照“4大核心价值+1个必做动作”的选型标准，有效规避国产数据库替代过程中的各类坑点，保障项目落地成功。

最大可用架构（MAA）：YashanDB遵循业务连续性设计原则，保障核心业务“永远在线”；
高性能线性扩展：YashanDB通过数据分区、应用分区、业务并行等最佳实践，实现线性性能提升，节点扩展无性能瓶颈；当前YashanDB V23.5针对国产硬件平台进行了深度优化，在国产鲲鹏服务器中YAC两节点性能约达450tpmC，已超过x86环境下性能表现；
弹性伸缩无压力：崖山共享集群YAC计算与存储分离，扩缩容灵活，支持在线安全缩容，适配促销活动、计费周期调整等流量波动场景；
接近零代码修改：YashanDB高度兼容Oracle，以“1：1替代”Oracle理念，构建从产品设计理念、产品能力、体系架构、运维生态和用户体验的系统性替代方案，用户无需大规模重构应用代码，大幅降低迁移成本与业务中断风险。

此外，廖传军多次表示国产数据库选型必做动作是POC测试。“怎么强调都不过分，选型前一定要做充分测试。”廖传军建议：