写在前面，本人目前处于求职中，如有合适内推岗位，请加：lpshiyue 感谢。同时还望大家一键三连，赚点奶粉钱。本系列已完结，完整版阅读课联系本人

高可用不是简单的冗余堆砌，而是无状态化、水平扩展与故障转移三者协同的艺术品

在掌握了系统压测方法论，能够准确评估系统容量边界后，我们面临一个更根本的挑战：如何让系统在真实流量冲击和故障发生时保持稳定？高可用架构设计正是解决这一挑战的核心手段。本文将深入解析无状态化、水平扩展与故障转移三大支柱技术的协同设计，帮助构建真正弹性可靠的系统架构。

1 高可用的本质：从故障避免到故障容忍的哲学转变

1.1 高可用性的核心价值重估

传统观念中，高可用意味着尽可能避免故障，而在分布式系统环境下，这一理念已转变为快速发现和恢复故障。根据Gartner的统计，企业IT系统平均每分钟的宕机成本超过5600美元，对于大型电商平台，这个数字可能达到数万美元。

高可用设计的哲学转变体现在三个层面：

• 从完美预防到快速恢复：接受故障必然性，专注于最小化MTTR（平均修复时间）
• 从单体坚固到分布式韧性：通过系统设计而非组件质量保证可用性
• 从人工干预到自动化愈合：建立系统自愈能力，减少人工依赖

这种转变使我们需要重新定义高可用的成功标准：不是追求100%无故障，而是确保故障发生时业务影响可控、恢复过程自动。

1.2 可用性等级的理性定位

不同业务场景对可用性有不同要求，理性定位是避免过度设计的第一步：

99.9%可用性（年停机时间≤8.76小时）适合内部管理系统
99.95%可用性（年停机时间≤4.38小时）适合一般业务系统
99.99%可用性（年停机时间≤52.6分钟）适合核心业务系统
99.999%可用性（年停机时间≤5.26分钟）适合金融交易系统

确立合理的可用性目标后，我们才能有针对性地选择技术方案，在成本与可靠性间找到平衡点。

2 无状态化：弹性架构的基石

2.1 无状态设计的本质与价值

无状态化不是简单去除会话数据，而是将状态与计算分离，使应用实例变得可替代。这种分离是水平扩展和故障转移的基础。

有状态架构的典型问题：

// 问题示例：会话绑定导致扩展困难
@RestController
public class StatefulController {
    // 会话状态存储在内存中
    private Map<String, UserSession> userSessions = new ConcurrentHashMap<>();
    
    @GetMapping("/userinfo")
    public String getUserInfo(HttpSession session) {
        UserSession userSession = (UserSession) session.getAttribute("currentUser");
        // 此实例绑定特定用户会话，无法随意替换
        return userSession.getUserInfo();
    }
}

状态内嵌导致实例不可替换

无状态化改造方案：

@Configuration
@EnableRedisHttpSession // 启用Redis会话存储
public class StatelessConfig {
    // 会话外部化配置
}

@RestController
public class StatelessUserController {
    @GetMapping("/userinfo")
    public String getUserInfo(@RequestHeader("Authorization") String token) {
        // 从Redis获取用户信息，不依赖本地状态
        String userJson = redisTemplate.opsForValue().get("session:" + token);
        User user = JsonUtil.fromJson(userJson, User.class);
        return user.toString();
    }
}

状态外置使实例可任意替换

2.2 无状态化的多层次实践

无状态化需要在不同层级实施协同策略：

应用层无状态：会话数据外部化到专用存储（Redis Cluster）
服务层无状态：API设计保证请求自包含，不依赖服务实例内存状态
任务层无状态：计算任务参数和结果完全自包含，支持任意重调度

无状态设计的业务适配策略：

• 完全无状态：适合查询类、计算型业务（商品查询、价格计算）
• 外部状态：适合需要会话保持但无需实例绑定的业务（用户登录状态）
• 轻量状态：适合短暂业务流程，状态生命周期与请求周期一致

2.3 无状态架构的代价与应对

无状态化不是银弹，需要认识其代价并制定应对策略：

性能代价：状态外部化增加网络开销，需要通过缓存、批处理优化
一致性挑战：分布式状态需要处理并发更新，采用乐观锁或版本控制
复杂度增加：需要引入额外组件（Redis、ZooKeeper），增加运维复杂度

合理的无状态化是有选择的无状态，而非盲目去除所有状态。核心是确保实例可替换性，而非完全消除状态。

3 水平扩展：流量压力的分布式化解

3.1 水平扩展的本质与架构前提

水平扩展通过增加实例数量而非提升单机性能来应对流量增长，其有效性直接依赖于无状态化程度。

水平扩展的架构前提：

• 无状态设计：实例间无数据依赖，可任意增减
• 负载均衡：流量按策略分发到多个实例
• 服务发现：动态感知实例上下线，实时更新路由
• 健康检查：自动隔离故障实例，保证流量只会到达健康节点

3.2 分层扩展策略

系统不同层级需要采用不同的水平扩展策略：

接入层扩展：通过DNS轮询、全局负载均衡实现流量入口扩展

# Nginx上游服务配置示例
upstream backend_servers {
    server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.12:8080 backup;  # 备份节点
    least_conn;  # 最少连接负载均衡
}

接入层通过集群化实现扩展

应用层扩展：无状态服务实例水平扩展，结合自动伸缩策略

# Kubernetes HPA配置示例
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: frontend-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: frontend
  minReplicas: 3
  maxReplicas: 100
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

应用层根据负载自动伸缩

数据层扩展：通过分片、读写分离等技术实现数据访问扩展

-- 数据库分片示例：用户数据按ID分片
-- 分片1：用户ID以0-4结尾
CREATE TABLE users_1 (
    id BIGINT PRIMARY KEY,
    name VARCHAR(100),
    -- 其他字段
);

-- 分片2：用户ID以5-9结尾  
CREATE TABLE users_2 (
    id BIGINT PRIMARY KEY,
    name VARCHAR(100),
    -- 其他字段
);

数据层通过分片实现水平扩展

3.3 水平扩展的粒度控制

科学的水平扩展需要精细化粒度控制，避免过度或不足扩展：

单元化扩展：按业务单元而非整体系统进行扩展，如用户服务独立于订单服务扩展
弹性伸缩：基于预测和实时指标动态调整实例数量，平衡性能与成本
分级扩展：核心服务与非核心服务差异化扩展策略，确保关键业务资源

4 故障转移：从被动应对到主动容错

4.1 故障检测：快速发现的艺术

有效的故障转移始于精准的故障检测，需要在及时性与准确性间找到平衡：

多层次健康检查策略：

# Kubernetes就绪与存活探针配置
apiVersion: v1
kind: Pod
metadata:
  name: web-application
spec:
  containers:
  - name: web
    image: nginx:latest
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 30
      periodSeconds: 10
      timeoutSeconds: 5
      failureThreshold: 3
    readinessProbe:
      httpGet:
        path: /ready  
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 3
      failureThreshold: 1

通过探针机制实现精准故障检测

智能故障判定：结合多个指标（响应时间、错误率、资源使用率）综合判断，避免单指标误判。

4.2 故障隔离：防止雪崩的屏障

故障转移不仅是将流量从故障实例移走，更重要的是隔离故障影响：

熔断器模式：在连续失败达到阈值时自动熔断，避免重试风暴

@Component
public class ProductService {
    @CircuitBreaker(name = "productService", 
                   fallbackMethod = "getProductFallback")
    public Product getProduct(Long productId) {
        return remoteProductService.getProduct(productId);
    }
    
    public Product getProductFallback(Long productId, Exception ex) {
        return cacheService.getBasicProduct(productId);
    }
}

熔断器防止故障扩散

隔离策略：

• 线程池隔离：不同服务使用独立线程池，避免资源竞争
• 信号量隔离：控制并发调用数，防止资源耗尽
• 超时控制：设置合理超时时间，避免长时间阻塞
• 限流降级：流量超过阈值时自动降级，保护系统不被冲垮

4.3 流量切换：无缝转移的技术实现

故障转移的核心是流量重路由，需要在不同层级实现协同：

负载均衡器切换：健康检查失败时自动从路由表中移除故障节点

upstream backend {
    server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.12:8080 backup;
    
    # 故障转移配置
    proxy_next_upstream error timeout http_500 http_502 http_503;
}

负载均衡器实现自动故障转移

服务网格流量管理：基于Istio等服务网格实现细粒度流量控制

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: product-service
spec:
  host: product-service
  trafficPolicy:
    outlierDetection:
      consecutiveErrors: 5
      interval: 10s
      baseEjectionTime: 30s
      maxEjectionPercent: 50

服务网格提供高级故障检测与转移能力

5 三大支柱的协同设计

5.1 协同工作的架构模式

无状态化、水平扩展与故障转移不是孤立技术，而是相互依赖的有机整体：

无状态化赋能水平扩展：只有无状态设计，才能实现真正的无缝水平扩展
水平扩展增强故障转移：多实例为故障转移提供目标节点，使转移成为可能
故障转移保障水平扩展：在扩展过程中，故障转移确保个别实例故障不影响整体

协同架构示例：

用户请求 → 负载均衡器（故障检测/转移）
                   ↓
           无状态应用集群（水平扩展）
                   ↓  
          集中式状态存储（Redis集群）
                   ↓
          数据存储层（分片/主从）

5.2 协同设计的反模式与陷阱

伪无状态陷阱：表面无状态但实际存在隐性状态依赖（如本地缓存、文件存储）
不平衡扩展：计算层扩展但数据层成为瓶颈，或相反
过度转移：过于敏感的故障检测导致频繁转移，反而影响稳定性
单点转移：故障转移机制本身存在单点故障

5.3 协同效能的度量体系

三大支柱的协同效果需要可度量的指标验证：

无状态化程度指标：

• 实例启动时间（应小于30秒）
• 请求路由一致性（任意实例处理结果相同）
• 状态外部化比例（超过90%状态外部化）

水平扩展效能指标：

• 线性扩展比（实例增加与性能提升比例）
• 扩展速度（从触发到完成扩展的时间）
• 资源利用率（避免过度或不足扩展）

故障转移质量指标：

• 故障检测时间（秒级检测）
• 转移恢复时间（分钟级恢复）
• 转移成功率（超过99%的转移成功）

6 实战案例：电商平台高可用架构演进

6.1 单体架构的高可用改造

初始状态：单体应用，会话绑定，数据库单点

改造步骤：

1. 无状态化改造：用户会话外置到Redis集群
2. 水平扩展准备：应用容器化，配置负载均衡
3. 故障转移基础：数据库主从分离，读写分离
4. 渐进式迁移：先读流量，后写流量；先非核心功能，后核心功能

改造效果：可用性从99.9%提升至99.95%，扩展时间从小时级降至分钟级

6.2 微服务架构的高可用深化

架构特点：服务拆分，分布式依赖，复杂调用链

深化措施：

• 精细化无状态：API网关无状态化，业务服务按需无状态
• 弹性扩展策略：基于业务优先级差异化扩展策略
• 智能故障转移：基于调用链分析的精准故障定位和隔离

深化效果：可用性提升至99.99%，故障恢复时间从30分钟降至5分钟以内

总结

高可用架构的本质是通过无状态化、水平扩展、故障转移三大支柱的协同设计，构建能够容忍故障、快速恢复的弹性系统。

核心洞察：

1. 无状态化是基础：只有解耦状态与计算，才能实现真正的弹性
2. 水平扩展是手段：通过分布式架构将集中式风险分解为可管理单元
3. 故障转移是保障：在故障发生时快速隔离和恢复，最小化业务影响
4. 协同设计是关键：三大支柱必须统一设计，相互配合，而非孤立优化

成功的高可用架构不是追求零故障，而是确保在故障发生时：

• 系统能够快速检测并定位问题
• 故障影响被有效隔离，防止扩散
• 业务流量被无缝转移到健康实例
• 系统能够自动恢复，减少人工干预

在云原生时代，随着Kubernetes、服务网格等技术的成熟，高可用能力已经日益平台化、标准化。然而，技术选型只是起点，真正的挑战在于根据业务特点合理运用这些能力，构建既可靠又经济的高可用体系。

📚 下篇预告
《CDN与边缘缓存策略——静态、动态与签名鉴权的组合拳》—— 我们将深入探讨：

• 🌐 缓存层次体系：浏览器缓存、边缘缓存、中心缓存的协同分工
• ⚡ 动态内容加速：边缘计算、智能路由与协议优化技术
• 🔐 安全缓存挑战：签名URL、权限验证与敏感内容保护
• 📊 缓存效能优化：命中率提升、失效策略与成本平衡
• 🚀 边缘架构演进：从内容分发到边缘计算的范式转变

点击关注，构建高效安全的全球内容分发体系！

今日行动建议：

1. 评估现有应用的无状态化程度，制定状态外部化改造路线
2. 设计水平扩展的容量规划与自动伸缩策略
3. 建立多层级的故障检测与转移机制，定期进行故障演练
4. 制定三大支柱协同效能的度量体系，持续优化高可用能力

小T导读：作为国内领先的智能办公整体方案提供商，成都极企科技有限公司已为全球上万家企业提供智能化建设方案，覆盖办公楼宇与园区面积已超百万平米。为应对日益增长的物联网数据接入需求，极企科技引入 TDengine TSDB 时序数据库，实现海量设备数据的实时采集、高效存储与智能分析，显著提升了设备监控系统的响应速度与数据处理能力。本文将分享这一智慧楼宇解决方案基于 TDengine的应用经验与实践成果。

背景和痛点

我们的智慧楼宇解决方案主要面向集团总部、新建办公大楼、政府园区等行业头部客户。这类客户普遍具备完善的 IT 基础与多年的办公系统建设经验，正处于从传统办公向智能化、数字化升级的关键阶段。在这一过程中，他们对智能化办公、物联网和数字化管理有较高的认知与明确的建设需求，期望通过新一代技术手段实现办公环境的智能协同与运营效率的全面提升。

在某大厦智能化项目中，共有 30 层楼宇，部署近万台传感器设备，涵盖人体感应、空气质量、厕位、烟雾、电量、水浸等多种类型。所有传感器均以秒级频率上报数据，日均数据量高达数千万条，对系统的数据采集与处理能力提出了极高要求。

该项目面临设备数据高频采集、多维度实时分析（设备状态、能耗、故障预测）以及历史数据长期存储三大挑战。传统关系型数据库在此类场景中存在明显不足，如写入性能瓶颈、查询延迟高、存储成本激增等问题。以 MySQL 和 PostgreSQL 为例，在存储设备时序数据时，由于缺乏原生的时间分区支持，当单表数据量超过千万级后，查询性能会出现断崖式下降，需人工分表分库，运维复杂度激增。同时，未压缩的原始数据占用空间庞大，存储成本高昂。

为什么选择 TDengine TSDB

在智慧楼宇项目的建设过程中，数据接入规模大、处理链路复杂、系统稳定性要求高，对底层数据库的性能与可靠性提出了极高要求。经过多方技术选型与验证，我们最终选择了 TDengine TSDB 作为核心时序数据库，主要基于以下考虑：

• 高效数据接入能力：支持 MQTT 数据写入方式，可通过低代码方式快速接入业务平台，实现高并发数据写入，确保近万台传感器上报数据的完整与可靠。
• 强大的流式计算能力：具备实时数据聚合与分析能力，能够对上报的时序元数据进行整合并高效供给业务平台，同时通过多副本机制保障数据高效写入与可靠备份。
• 完善的技术支持体系：提供一对一、7×24 小时技术支持服务，确保项目在开发、部署及运维阶段的稳定运行。
• 国产化与生态兼容性：作为 100% 自主可控的时序数据库，TDengine TSDB 符合信创标准，并已与华为云、麒麟软件等生态厂商完成深度集成，满足极企科技在国产化替代中的技术选型需求。
• 领先的综合性能与可拓展性：在同类型数据库中，TDengine TSDB 在数据压缩率、写入速度、分析效率及分布式架构等方面表现突出，后续版本还将持续增强易用性与 AI 能力，支持更多的功能和场景，助力企业进一步提升应用效果。

TDengine TSDB 落地实践

架构描述

系统采用 Node-Red 作为数据流控制与可视化管理核心，实现全链路的数据采集、处理与展示。整体架构如下：

1. 各类传感器采集的数据首先由 Node-Red 进行预处理后写入 EMQ 消息中间件；
2. TDengine TSDB 通过 taosX 模块从 EMQ 中高效读取并存储数据，实现时序数据的集中管理；
3. EMQ 再通过 Restful / WebSocket 接口从 TDengine TSDB 获取所需数据，为上层业务应用与可视化系统提供实时访问能力。

智能应用场景示例

• 当指定区域内连续 5 分钟无人时，系统自动关闭照明；
• 当某项监测指标超过设定阈值时，自动触发告警并记录相关信息；
• 当检测到某区域无人时，系统自动关闭空调以节约能源。

项目初期采用 3 节点集群架构，数据库配置为 3 副本模式，以实现系统高可用与数据冗余，具体配置如下：

系统上线后该集群运行稳定，能够高效处理全部传感器采集数据，全面满足项目预定的各项指标。在确认技术架构稳定可靠后，我们将订阅模式变更为永久模式，将长期使用以 TDengine TSDB 为核心的技术架构。

数据库建模

1. 超级表定义

CREATE STABLE IF NOT EXISTS airsensor (
  ts timestamp,        时间
  pm25 int,        PM2.5
  pm10 int,        PM1.0
  tvoc int,                TVOC
  co2 int,                二氧化碳
  formaldehyde float,        甲醛
  noise float,        噪音
  temperature float,                温度
  humidity float,        湿度
  light int,                光照
  h2s int,                硫化氢
  ch4 int,                甲烷
  co int,                一氧化碳
  no2 float,        二氧化氮
  h2 int,                氢气
  odor float        异味
) TAGS (
  position NCHAR(200),
  space NCHAR(20),
  floor_area NCHAR(20),
  floor NCHAR(20),
  area NCHAR(20),
  device_code NCHAR(20),
  device_id int,
  factory NCHAR(50),
  model NCHAR(50)
);

• 流计算

  • 会议室人员判定

  create stream if not exists mroom_stream trigger at_once into mroom_stream_status (ts,status) tags(
      space,
      floor_area,
      floor,
      area 
  ) subtable(
      cast(
          concat('mss_', space, '_', floor_area, '_', floor, '_', area) as varchar
      )
  ) as
  SELECT
      _wstart as ts,
      case
          when sum(status) > 0 then 1
          else 0
      end as status
  FROM
      bxserver.humensensor partition by space,
      floor_area,
      floor,
  area interval(1m) fill(value,-1);

• 楼层用电量统计

select _wstart as ts, max(total_kwh)-min(total_kwh) as used from bxserver.powersensor partition by tbname interval(1d);

• 订阅数据

落地效果

• 针对电量传感器采集的元数据通过 TDengine TSDB 转换后的每个楼层用电量统计如下：

• 针对每个设备状态上报数据通过 TDengine TSDB 转化为设备告警情况如下：

• 针对空气传感器采集的数据，系统通过 TDengine TSDB 进行转换与分析，并根据当前区域的平均温度执行相应的温控策略：

TDengine 应用经验分享

1. 时钟同步问题

在使用过程中，我们发现某会议室的人体传感器流计算结果存在异常，最近一分钟的数据未被正常计算。经排查，原因是服务器时间未与时间服务器同步。安装并配置 NTP 服务完成时间同步后，流计算功能恢复正常。

2. 查询 SQL 语句优化

powersensor_loop 表按行记录传感器的瞬时实测值。为计算当天的用电量，需要对相邻两行取差值后再用 SUM 求和。最初我们采用的是如下嵌套子查询方案，不仅执行时间长，而且占用较大的临时空间：

select TO_CHAR(_wstart, 'YYYY/MM/DD HH24:MI:00') as ts, TO_CHAR(_wstart, 'HH24') as hour, sum(kwh) as kwh, space,floor_area,floor,type from (select _rowts as ts, diff(kwh) as kwh, space, floor_area, floor, area, device_id, loop, type frombxserver.powersensor_loop partition by space, floor_area, floor, area, device_id, loop, type) where ts >= TO_UNIXTIMESTAMP('2025-08-28 00:00:00') and ts <= TO_UNIXTIMESTAMP('2025-08-28 23:59:59') partition by space, floor_area, floor, type interval(1d) order by floor asc;  

powersensor\_loop 表结构如下图所示：

经分析发现，上述嵌套查询语句只在外层添加了时间范围条件，而内层查询未作限制，导致内层查询需读取全量数据，执行耗时长且占用大量临时空间。优化后，我们将时间范围条件前移至内层查询，使其仅在指定时间范围内读取数据，从而显著减少数据扫描量并提升执行效率。

select TO_CHAR(_wstart, 'YYYY/MM/DD HH24:MI:00') as ts, TO_CHAR(_wstart, 'HH24') as hour, sum(kwh) as kwh, space,floor_area,floor,type from (select _rowts as ts, diff(kwh) as kwh, space, floor_area, floor, area, device_id, loop, type frombxserver.powersensor_loop where ts >= TO_UNIXTIMESTAMP('2025-08-28 00:00:00') and ts <= TO_UNIXTIMESTAMP('2025-08-28 23:59:59') partition by space, floor_area, floor, area, device_id, loop, type) partition by space, floor_area, floor, type interval(1d) order by floor asc;

未来规划

当前系统使用的版本为 TDengine TSDB 3.3.6，因流计算暂不支持 diff 函数，无法直接计算相邻数据差值。后续我们计划升级至最新版本 3.3.8，新版本已支持 diff 函数，可将每日电量数据的差值计算结果直接写入流计算结果表，进一步简化后续的查询与汇总分析流程。

关于成都极企科技

成都极企科技有限公司成立于 2014 年，注册资本 392 万元，专注于智能化办公解决方案的研发与落地。公司具备自主软硬件研发能力，已取得多项国家专利及资质认证，为全球上万家企业提供智能化解决方案，累计完成超过百万平方米的办公楼宇与园区智能化建设。客户涵盖美团、爱奇艺、腾讯、阿里、联想、华为、富力、金地等行业头部企业，形成了从硬件设计、软件开发到工程实施的一体化核心竞争力。

关于作者

何铮，公司创始人兼项目带头人，毕业于电子科技大学，国家特聘专家。拥有二十年办公领域产品开发经验，带领企业完成三轮千万级融资。

最新消息，Apache DolphinScheduler 3.4.0 已正式发布！

本次版本带来了多租户调度隔离、工作流并行性能优化、任务重试与告警机制增强，以及资源管理和日志处理改进。无论是复杂企业业务场景，还是高并发任务调度，3.4.0 都让系统更高效、更可靠、更易用。立即升级，体验全新调度能力！

升级与下载

下载页面（可选择镜像下载）：
https://dolphinscheduler.apache.org/zh-cn/download/3.4.0

GitHub Release 页面：
https://github.com/apache/dolphinscheduler/releases/tag/3.4.0
升级时建议参考官方文档中的集群升级指南，确保兼容性和配置一致性。

核心功能增强与重要更新

通用 OIDC 认证支持

3.4.0 引入了对 OpenID Connect（OIDC）的通用支持，旨在简化与企业身份认证系统的集成。通过 OIDC，用户可以使用统一的身份提供商（如 Keycloak、Okta 等）进行 SSO 登录，无需额外实现复杂自定义逻辑。这提升了安全性和用户体验，尤其是在多系统联邦登录与统一认证场景中，能够使 DolphinScheduler 更自然地融入企业级认证体系，减少重复配置和验证成本，从而提高登录配置的扩展性和一致性。

（参考图）

gRPC 任务插件支持

本版本新增了 gRPC 任务插件能力，使调度器能够通过原生 gRPC 协议直接与远程服务交互。用户可以将后端微服务暴露的 gRPC 接口作为任务执行目标，无需中间脚本封装。这种方式特别适合微服务生态或跨语言执行场景，通过明确参数契约和高性能通信协议提升任务整合效率，从而减少资源调度延迟、提高任务可靠性。

支持工作流串行策略

实现了 工作流串行执行策略（Workflow Serial Strategy） 的核心逻辑重构，通过引入一个全新的串行命令队列机制（t_ds_serial_command 表及相关 DAO/Mapper），配合一套串行执行协调器（WorkflowSerialCoordinator）及策略处理器，使 DolphinScheduler 能更智能地管理串行类型的工作流（如 SERIAL_WAIT、SERIAL_PRIORITY、SERIAL_DISCARD）。

该设计改进了工作流触发流程的执行类型判断、状态管理、命令队列处理等关键路径，使串行调度逻辑更清晰、更可靠，有助于提升串行工作流场景下的调度稳定性与可控性。同时，3.4.0 重构了触发器与状态机相关代码，增强该能力的可维护性和扩展性。

移除 PyTorch 任务类型

3.4.0 对任务类型体系进行了精简，正式移除了内置的 PyTorch 任务类型。该调整主要基于实际使用情况和长期维护成本的考量，因为原有 PyTorch 任务实现使用率较低，且与调度器核心任务模型耦合度较高，增加了版本演进和兼容性维护的复杂度。通过移除该任务类型，DolphinScheduler 能保持核心架构的简洁与稳定。

我们鼓励用户通过更通用的 Shell、Python 或插件化方式运行 PyTorch 作业，从而提升系统整体的可维护性和扩展性。

稳定性与重要修复

Kubernetes Worker 部署增强

在 Kubernetes 原生部署场景下，3.4.0 使 Worker StatefulSet 的 Helm Chart 支持注入 Secrets 和 InitContainers。通过 Secrets 注入，可以安全传递证书或凭据；InitContainers 允许在主容器启动前完成必要的初始化逻辑，如准备文件系统或校验环境依赖。

这些增强有助于在容器化环境下实现更安全、更一致的部署策略和生命周期管理。

SQL 任务取消能力

针对 SQL 任务类型，本次版本提供了对任务执行取消的原生支持。当执行的 SQL 语句由于逻辑错误或长期运行导致资源占用时，用户可以通过调度器下发取消操作，使任务尽快中止，而不是简单失败或等待超时。这一能力改善了任务控制能力，避免长时间运行对集群资源的无效占用，有助于提升整体资源利用率和执行调度体验。

条件任务节点在前置失败情况下执行逻辑修复

在某些复杂工作流中，当条件任务节点的前置任务失败时，条件节点未按预期执行。3.4.0 修复了这一调度核心逻辑，确保条件节点能够正确响应前置失败状态。这样，工作流分支逻辑能够按照既定 DAG 定义可靠运行，从而避免因逻辑错误导致的流程中断或不一致执行。

ZooKeeper 节点清理问题修复

在使用 ZooKeeper 作为协调组件的高可用部署中，部分用户反馈 Master Server 在启动失败后未正确清理已注册的 failover 节点路径，可能导致后续状态异常。该版本修复了这个问题，使 Master 在异常启动路径中能够正确清理关联注册节点，保持注册中心状态一致，确保高可用场景下集群状态的健康和可靠性。

Worker Group 分配逻辑错误修复

此前版本中，项目与 Worker Group 关联/移除操作可能在 API 层出现逻辑不一致，导致调度器未能正确识别项目与 Worker Group 的关系。本次版本修正了相关逻辑，使 API 行为与用户预期一致，从而改善 Worker 管控、资源隔离和调度分配体验。

此外，3.4.0 版本还进行了很多功能优化和问题修复，包括文档与配置规范完善（时区、安全、负载均衡）、核心调度与注册中心稳定性增强（TraceId、Failover 清理、可重入锁）、性能与资源管理优化（任务组索引）、前端与插件体验改进（日志查询、DataX 校验、文件展示）、依赖与安全更新（PostgreSQL JDBC、Spring Boot CVE 修复）等，篇幅所限不再一一展开，详情可查询完整更新列表：https://github.com/apache/dolphinscheduler/releases/tag/3.4.0

Bug 修复亮点

标记任务为 Inactive 状态逻辑修复

某些生命周期事件中，当任务状态需要被标记为 Inactive 时，状态变更可能未正确触发，导致 UI 和执行引擎状态不一致。此版本修复了这一逻辑，使状态标记与生命周期事件更加一致。

Workflow Lineage 删除逻辑优化

在工作流血缘关系删除操作中，系统可能未能彻底清理相关引用，导致历史血缘链路残留。3.4.0 改进了删除逻辑，使 DolphinScheduler 在删除血缘链时能够更精确地清理对应关系，避免分析后续依赖时出现错误链路。

其他 Bug 修复包括前置任务失败导致条件节点不执行问题修复、项目级 Worker Group 绑定与移除逻辑修正、子工作流触发参数丢失问题修复等，详情请查询完整 Release Note：https://github.com/apache/dolphinscheduler/releases/tag/3.4.0

文档更新

1. 发布并完善 Apache DolphinScheduler 3.3.2 版本发布说明文档。
2. 修复文档 CI 构建错误，提升文档发布流程的稳定性。
3. 补充 Prometheus 指标接口的认证机制及其在 Kubernetes 环境下的使用说明。
4. 同步更新 JdbcRegistry 引入事务机制后的相关文档描述，保证文档与实际行为一致。

致谢

本次版本发布离不开社区各位贡献者的热情参与与支持。特别感谢 @ Gallardot 作为 3.4.0 的 Release Manager，从版控、构建、候选版验证到最终投票组织，确保发布流程高质量推进。

同时，感谢以下本次版本的所有贡献者（GitHub ID，排名不分先后）：

Gallardot、njnu‑seafish、det101、Mrhs121、EinsteinInIct、sanfeng‑lhh、ruanwenjun、tusaryan、qiong‑zhou、SbloodyS、kvermeulen、npofsi、CauliflowerEater、ChaoquanTao、dill21yu、sdhzwc、zhan7236、KwongHing、jmmc‑tools、liunaijie

感谢所有通过提交 PR、Issue、文档贡献、社区讨论、测试验证等方式参与 Apache DolphinScheduler 项目的人。正是你们的努力推进了 DolphinScheduler 的持续演进与社区繁荣，欢迎更多人加入我们的队伍！

摘要：

OceanBase 凭借原生分布式、零停机、全栈多云兼容三大核心技术优势，精准破解 TNG Digital 在高并发支撑、业务连续性等方面的痛点，助力其实现从“宕机危机”到“99.99%高可用”的跨越式升级,成为其规模化盈利的技术基石，打造了分布式数据库以硬核技术赋能东南亚头部金融科技企业核心支付场景的标杆范例，为分布式数据库基础软件出海提供“技术适配+低成本落地”的全新实践路径。

作为马来西亚金融科技领域的领军者，TNG Digital 凭借 TNG eWallet 深度融入民众支付生活，全面覆盖交通出行、餐饮消费、资金转账等高频场景。

自 2018 年起，其用户规模实现超 10倍爆发式增长，截至 2025 年，已服务马来西亚 3300 万人口中的 2500 万验证用户，成为支撑区域数字经济运转、贯穿民生服务的关键信息基础设施。

然而，高速增长背后暗藏技术“生死考验”，OceanBase 凭借原生分布式、零停机、全栈多云兼容三大核心技术优势，精准破解 TNG Digital 在高并发支撑、业务连续性等方面的痛点，助力其实现从“宕机危机”到“99.99%高可用”的跨越式升级。

本次合作不仅成为 TNG Digital 规模化盈利的技术基石，更打造了分布式数据库以硬核技术赋能东南亚头部金融科技企业核心支付场景的标杆范例，为分布式数据库基础软件出海提供“技术适配+低成本落地”的全新实践路径。

增长阵痛：金融科技高并发场景下的核心数据底座短板

作为承载马来西亚数千万用户日常支付的核心平台，TNG Digital 的系统稳定性直接关系到民生服务体验与金融市场秩序。

Leslie Lip（TNG Digital CTO）坦言，业务年增长率达 2-3 倍的背后，是技术团队不断与“规模陷阱”博弈的过程。

核心痛点集中于数据底座的四大短板：

· 突发流量峰值应对失效

午间支付高峰时段，全钱包系统需承载巨大的交易压力，而原有数据库难以支撑政府补贴发放等非常规突发流量。TNG Digital 曾在 6 年前发生的数据异常，正是因为原有数据库架构缺陷导致服务器资源未充分利用从而陷入瓶颈，暴露了核心数据底座的“抗冲击”能力不足。

· 业务迭代中的停机风险

金融科技平台需通过高频表结构更新，适配支付场景创新，但原有数据库的 DDL 变更常导致生产环境停机，直接影响用户支付、转账等核心操作的连续性，成为业务快速迭代的“绊脚石”。

· 多云扩展的兼容性壁垒

业务初期依托阿里云，随规模扩张延伸至 Azure、AWS 等多平台，但不同云厂商的数据库服务存在适配鸿沟，既无法实现跨云协同运维，又面临被单一厂商绑定的“vendor lock-in”风险，制约 TNG Digital 的全球化布局步伐。

· 性能与成本的失衡困境

用户增长带来数据量爆发式累积，原有数据库存储效率低下，导致 IDC 运维与存储成本持续攀升；同时在相同硬件规格下，吞吐量难以匹配业务增长需求，形成“成本涨、性能滞”的恶性循环。

OceanBase 破局之道：以“支付级”能力适配金融科技核心需求

Leslie Lip 强调，选择 OceanBase 的核心逻辑是“解决真实业务痛点，而非单纯追求技术参数升级”。

针对 TNG Digital 在支付场景高并发、业务连续性、多云扩展等方面的核心诉求，OceanBase 提供了贴合金融科技特性的全链路解决方案：

01零停机解决核心技术破解迭代难题

依托原生分布式架构设计，OceanBase 实现核心表 DDL 操作零停机执行的关键技术突破——在 POC 阶段即完成 4 万 TPS CRUD 并发场景下的表结构更新测试，全程无业务中断、无性能衰减。

这一技术特性彻底解决了 TNG Digital 高频迭代中的停机隐患，为支付场景快速创新扫清核心技术障碍。

02原生分布式架构扛住峰值压力

OceanBase 采用“share-nothing”原生分布式架构，具备线性弹性扩展能力，可按需扩容支撑业务增长。

该技术特性使其既能轻松承接午间的常规高峰流量，更能应对政府补贴发放等非常规突发流量的冲击，从底层架构层面杜绝宕机风险，完美匹配支付场景对高可用的极致要求。

03全栈多云一致性体验能力

OceanBase 内置全栈多云兼容技术模块，通过统一的技术接口与适配层，完美兼容阿里云、Azure、AWS 三大云平台的底层环境，实现不同云平台下的部署架构、运维操作、性能表现及合规审计的全链路一致性体验。

这一核心技术特性，不仅为 TNG 搭建了 “以私有化部署为核心、多云协同为延伸” 的弹性 IT 架构，保障了征信数据跨云流转与管理的稳定性、安全性，更从技术层面帮助 TNG Digital 彻底摆脱 “vendor lock-in” 制约，为其后续拓展东南亚其他区域征信服务、接入更多全球云服务提供商奠定了核心基础，让 TNG Digital 在全球化业务布局中具备更强的技术灵活性与成本可控性。

04高压缩比+高性能优化技术提升效益

OceanBase 基于高压缩的数据引擎，实现 5 倍数据体积缩减的技术效果，大幅降低存储与运维成本。

同时凭借分布式执行引擎优化技术，在相同硬件规格下实现 40% 的吞吐量提升，精准破解 TNG Digital “成本涨、性能滞”的核心困境，为金融科技企业盈利化发展提供技术支撑。

05全量 MySQL 兼容技术加速落地见效

OceanBase 深度打磨 MySQL 兼容层技术，实现语法、应用行为、驱动的全量兼容。

这一技术特性使 TNG Digital 技术团队无需额外学习成本即可快速上手，大幅缩短项目升级与落地周期，实现技术升级的“平滑过渡”。正如 Leslie Lip 所言，OceanBase 不仅是数据库，更是“能伴随企业野心共同成长的技术平台”。

实现从“生存线”到“增长线”的价值跃升

基于 OceanBase 完成核心数据底座升级后，TNG Digital 在业务稳定性、运营效率、创新能力三大维度实现质的飞跃，关键成效完全匹配金融科技支付场景的核心诉求：

01支付连续性达行业顶尖水平

核心系统实现 99.99% 的高可用，与 OceanBase 合作至今，未发生任何数据库事故，成功支撑多轮政府补贴发放等重大场景的平稳运行，彻底摆脱过往宕机阴影，筑牢支付业务“生存线”。

02性能与成本效益双突破

相同硬件规格下，业务吞吐量提升 40%，高效承接高峰期高并发交易；5 倍数据压缩比大幅降低存储成本，为企业盈利化发展提供有力支撑，将数据底座从“成本中心”转化为“效益中心”。

03创新与拓展能力全面释放

零停机 DDL 与多云协同能力，为 TNG Digital 的场景迭代与跨平台拓展扫清障碍。

目前双方已启动键值数据库模型搭建、跨云双活架构合作等计划，将基于 OceanBase 构建更具弹性的时间敏感型支付应用，进一步拓宽业务增长边界。

从服务本土支付场景的分布式数据库，到支撑海外支付场景的分布式数据库

金融科技的规模化增长，本质是数据底座“抗冲击能力、迭代能力、扩展能力”的综合较量。

TNG Digital 作为东南亚支付领域的龙头企业，其面临的“高并发、零中断、多云扩展”痛点，是全球金融科技企业规模化过程中的共性难题。OceanBase 的成功落地，不仅解决了单一企业的技术困境，更提供了适配支付场景核心需求的可复制技术方案。

OceanBase 与 TNG Digital 的合作，标志着分布式数据库凭借“原生分布式+零停机+全栈多云兼容”等硬核技术特性，已具备支撑海外头部金融科技核心支付场景的成熟能力，实现从“国内核心场景验证”到“海外高频支付场景落地”的关键跨越。

区别于其他出海案例，此次合作的核心亮点在于以技术特性精准匹配支付场景需求——零停机保障业务迭代连续性，原生分布式支撑高并发峰值，多云兼容打破拓展壁垒，这些技术优势共同重塑了海外市场对分布式数据库基础软件在支付场景下的技术认知。

未来，OceanBase 将持续深化与 TNG Digital 的协同创新，助力其实现云服务提供商拓展、跨云韧性升级等战略目标，同时进一步完善东南亚市场的本地化服务体系，聚焦金融科技支付、数字钱包等核心场景，为更多海外企业提供“支付级”稳定、高效、经济的数据底座支撑，推动分布式数据库基础软件全球化布局向“场景化深度赋能”新阶段迈进。

欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/

作者：张红霞，青岛雨诺网络信息股份有限公司新零售产品部总监

综述

当前，医药零售企业已不再满足于“卖药”，而是致力于成为“健康管理伙伴”。通过构建以 CRM 会员系统为核心、线上与线下深度融合的全渠道服务架构，企业实现了服务时间与空间的无限延展、会员数据的集中管理与智能应用、营销活动的精准触达与高效转化。

作为医药零售的头部企业，重庆医药（集团）股份有限公司（简称“重药集团”）前身是成立于1950年的中国医药公司西南区公司，服务于医药全产业链，同时从事医药研发（MAH）、医疗器械生产，并投资参与医药工业。重药集团拥有全级次分、子公司200余家，正在从传统的配送商业企业向“互联网+医药”融合型现代医药企业转型。

随着CRM会员系统的使用时间拉长，其底层的传统数据库逐渐难以满足复杂数据的高效处理需求。面对海量交易和多维度行为数据的汇聚，重药集团CRM会员系统亟需采用具备高可用、强一致、可扩展特性的数据库。经过对比三款国产分布式数据库，重药集团选择OceanBase，最终实现系统稳定运行、复杂场景实时分析、查询效率提升25倍、存储空间节约60%。

此次重药集团CRM系统的数据库升级不仅提升了用户体验与品牌忠诚度，也为后续集团构建高性能、高可用的“集团级数字化运营中枢”提供了明确的业务需求与数据基础，构建可扩展、可复制、可监管的集团化运营体系。

医药零售商业模式变革，CRM系统实现全渠道协同

随着消费者行为的数字化转型和健康需求的持续升级，医药零售行业正经历深刻的商业模式变革。传统药店“有啥卖啥”的经营逻辑，逐步向“顾客需要什么”的逻辑转变，除了提供到店服务外，还支持线上服务，比如通过企业微信、公众号等渠道建立长期沟通机制。微商城代客下单、在线解答疑问等。

为构建以专业化服务为基础的顾客信任体系，医药企业建立了完整的会员服务体系——CRM 会员系统，以实现绑定多重会员信息、建立精准的会员标签画像，为会员提供更多的服务和营销。通过数据驱动决策的专业化服务能力提升来提高企业在行业内的竞争力，实现增收。

如图1 所示，CRM 会员系统可以实现线上、线下全渠道协同，支持会员档案统一、标签体系完善、自动触发机制、店员触达赋能、社群营销等关键功能。完成顾客到店/线上购药 → 完成交易 → 数据沉淀至 CRM → 触发服务与营销 → 二次消费 → 再次触达，实现“交易—服务—再交易”的正向循环。

图1 CRM会员系统实现线上、线下全渠道协同

为实现一体化管理需求，构建CRM会员系统

重药集团CRM会员系统的搭建背景，源自于其各子公司会员管理分散，系统缺乏统一规划，导致数据难沉淀、服务差异大、运营难复制，且缺乏实时监控，难以支撑决策。

为实现一体化管理，重药集团CRM会员系统分阶段建设。第一阶段完成会员营销平台的底座建设，打造集团化、标准化、数据化运营基础，核心目标如下。

• 搭建集团化会员运营平台。现集团—子公司—门店的一体化管理，打通组织架构与业务链路，确保会员在不同层级和渠道中都能获得一致的服务体验。
• 统一的会员运营服务体系。构建覆盖会员管理、营销活动、服务交付的标准化流程，减少分散运作带来的效率损耗，提升整体运营协同能力。
• 可快速复制标准化服务能力。形成可落地的服务模板和运营机制，帮助新业务和子公司快速复制成熟经验，缩短建设周期，提升推广效率。
• 实现经营数据统一分析。沉淀完整的数据资产，打破信息孤岛，实现对会员、门店、区域的多维度统一分析，为企业战略决策与合规审计提供有力支撑。

在上述目标指导下，我们做了三个核心举措：

• 联合集团会员中心，推进一体化进程。覆盖集团全品牌及线上会员，实现线上和线下会员统一运营和全域价值管理（见图2）。
• 构建多层级组织架构视角报表。支持集团、品牌、门店的权限管理，权限灵活配置，便于集团总部进行跨品牌的数据报表分析。
• 集团统一下达任务。集团可向各品牌下发销售任务、患者教育活动任务及拉新任务，实现集团任务统一管理与执行监督。

图2 集团会员同意运营架构

我们计划以集团内个别区域公司为试点，试行以上举措，若成功，则进行全面推广。推广成功后，重药集团会员运营平台将实现从“单一业务系统”向“集团级数字化运营中枢”演进。依托统一的技术底座与标准化流程，平台不仅实现对多家子公司、多个品牌的全面接入，更构建起可扩展、可复制、可监管的集团化运营体系。

此外，为实现全渠道会员统一运营，平台通过整合分散在各系统中的数据，构建统一、动态、多维度的会员标签画像体系（见图3），支撑精细化运营决策。

图3 多维度会员标签画像体系

通过会员系统精准化的服务来反哺我们的线上和线下的会员营销和服务，实现线上精准营销、个性化推荐、好物推送、会员关怀，线下关联用药建议、慢病管理提醒、店员主动触达等，提升营销转化率，增强客户粘性，实现“数据驱动服务”的闭环。

精细化会员服务，带来海量数据的查询、存储难题

然而，随着集团化会员运营平台的推进，精细化服务模式持续深化，导致用户数据规模呈指数级增长，显著提升了系统的查询与存储复杂性。

• 会员量：突破千万级，覆盖多个品牌及区域公司。
• 交易数据量：达到亿级，涵盖线上线下购药、用券、复购等行为。
• 用户行为类数据：包括商品浏览、搜索、加购等，总量亦达千万级以上。

这些数据来源于线上商城、私域平台、公众号等多个渠道，经标签体系整合后，用于构建立体化的会员画像，支撑精准营销与双向引流。

但数据体量大、类型多样、实时性要求高，对数据库的高并发读写能力、存储扩展性与查询性能提出严峻考验。面对千万级会员、亿级交易和多维度行为数据的汇聚，传统数据库难以满足高效处理需求，亟需采用具备高可用、强一致、可扩展特性的分布式数据库系统进行支撑。

CRM会员系统数据库升级，应对千万级数据处理难题

传统数据库的技术瓶颈制约业务发展

重药集团会员服务平台的规模化发展，使系统数据总量迅速增长至千万级、数十 TB 存储规模，传统关系型数据库在支撑精细化会员运营场景时，暴露出四大核心挑战。

• 性能：百万大表 InnoDB 在高并发读写及复杂查询场景下，性能显著下降，无法满足业务需求，且有事务访问，无法通过拆分提升性能。同时，业务强依赖事务一致性，无法通过拆分提升性能。
• 效率：核心归档由于业务需求，需要保留大量数据（数十 TB），会造成 DDL 周期长，延迟业务上线时间。
• 成本：随着企业数量增多、历年数据累积，存储成本将越来越高。
• 及时性：在各种场景下，对应数据处理的及时性需求越来越强。

上述技术挑战不乏真实业务案例。

例 1：某大型连锁店，以满足信创要求为前提进行性能保障

如今国家对信息技术应用创新（简称“信创”）的要求日益严格，特别是在国有企业中，系统必须符合相关标准才能上线。为了响应这一趋势，我们严格按照信创目录选择数据库产品，并对其进行了全面的业务场景适配与性能验证。

• 数据准备：会员卡 9950万+、订单 1 亿 9980万+。
• 验证数据库：OceanBase 数据库、某数据库1、某数据库2。
• 验证功能：报表 14 项内容、高级筛选 8 项内容。
• 参考标准：报表查询小于 20s、静态化数据小于 60s、高级筛选小于 15s。

测试结果如图4所示。OceanBase 在所有测试项中均显著优于其他两个国产数据库，在报表查询、高级筛选、静态化数据三个场景的性能表现都远超预期：

• 报表查询小于 7s，平均提速 78 倍以上。
• 高级筛选响应高级筛选小于 1s，速度提升 200–700 倍。
• 静态化数据静态化数据小于 46s，效率提升 6.7 倍以上。

图4 OceanBase 数据库、某数据库1、某数据库2的测试结果

在严格遵循国家信创要求的前提下，OceanBase 不仅完全满足合规性准入条件，更在百亿级数据规模下的复杂查询与批量处理场景中展现出卓越性能，远超同类国产数据库产品。基于此，我们总结了三个数据库的性能数据，向客户提交了一份详细的分析报告。

例 2：连锁会员、订单交易数据量增长迅速，实时性查询瓶颈

除了信创需求外，客户对业务的实时性、及时性要求也越来越高。过去，企业主要依赖 BI 工具进行周期性报表生成，可容忍数小时甚至数天的数据延迟。然而，随着营销策略向精准触达和即时响应演进，业务人员需要在高价值客户识别、复购提醒触发、定向营销投放、健康知识推荐等场景中获取近实时数据支持。为实现精准服务，运营人员经常需要基于会员信息、会员属性、历史消费、会员标签、商品集合等多个维度进行多维组合筛选，由于关联维度过多，可能会出现查询失败、查询时间过长、范围跨度受限、复杂查询无法支持等问题，显然，这些问题是我们服务的客户无法接受的。

例 3：海量业务数据，系统可用性与存储成本难平衡

连锁医药企业会员体系的不断扩展和数字化运营的深入，必然会带来业务数据量的指数级增长，海量数据带来的高存储成本成为制约系统可持续发展的关键瓶颈之一。

• 用户数据：累计会员数量突破千万级（>1000万）。
• 交易流水：日均订单量达百万级，历史累计超过亿级（>1亿条）。
• 用户行为数据：包括浏览、搜索、加购、收藏等行为记录，总量亦达千万级以上。

单个业务数据库实例空间占用已达到 N 个 TB 级别，且随时间推移呈线性增长。随着客户数量增加和业务持续扩张，业务数据库实例的空间占用迅速攀升至数十TB甚至上百TB级别，这些数据不仅用于支撑日常业务运行，还需长期保留以满足合规审计、精准营销、客户画像构建等需求。企业面临保障性能与可用性的前提下降低存储成本的难题。

因此，引入具备高效数据压缩、自动冷热分层、弹性扩展能力的新一代分布式数据库，是实现“数据价值最大化、存储成本最小化”的必然选择。

数据库技术引入，支撑海量交易数据的高效处理

综合业务需求与传统数据库的技术瓶颈考虑，我们需要替换传统数据库，升级为高性能、稳定性强、成本低、 HTAP 一体化的分布式数据库。

自 2023 年起，我们开始系统性地评估并引入 OceanBase，历经技术认知、多轮测试、工具链验证、SaaS 级试点上线等关键阶段（见图5），最终成功应用于重药集团会员管理平台。

图5 上线OceanBase的关键阶段

1.技术引入与评估阶段（2023年）

测试重点包括三部分。

其一，日常抖动测试。在对 OceanBase 初期测试时，我们首先进行了业务压力测试。低峰期业务配合100%模拟线上流量直接发压，高达4轮的压力测试，每次持续 3 小时以上。

其二，扩容/缩容测试。在业务流量低时进行相关操作验证。为了验证是否存在小概率事件，进行了为期一周的脚本自动扩、缩容操作以观察其稳定性。

其三，Add Index 测试。与扩容、缩容相仿，基于业务流量对1T大表进行多达几十次的add index操作，观察延迟情况。

2.SaaS 产品试点上线（2023 年 12 月）

在完成全面技术验证后，我司将 OceanBase 应用于内部 SaaS 类产品中，作为首个生产级试点场景。该阶段实现了：

• 数据库稳定运行于真实业务环境中。
• 验证了迁移、运维、监控等全生命周期管理能力。
• 积累了宝贵的实战经验，为后续客户项目打下坚实基础。

3.重药集团项目正式上线（2025 年 4 月）

基于前期充分验证与试点成果，我们于 2025 年 4 月正式启动重药集团会员管理平台项目，OceanBase 正式投入生产使用，支撑海量交易数据的高效处理。

会员服务平台“新面貌”：稳定、高性能、低成本

构建标准化数据链路，稳定、高效处理海量数据

目前，OceanBase 主要支撑重药集团会员服务平台的分析型业务场景，支撑高并发、多维度的会员数据查询、标签计算、报表生成及精准营销决策。其核心价值体现在：高效处理海量历史数据、支持复杂实时分析、保障查询性能与系统稳定性。

整个数据链路遵循“源系统 → CRM 中转清洗 → OceanBase 分析库”的三层架构，如图6所示。

图6 会员服务平台的数据分析链路

数据来源（源系统）包括POS 订单数据、各渠道会员信息、组织人员数据、会员标签数据、档案测量数据、全部商品主数据。

• 中转与清洗层（CRM 系统）：所有原始数据通过定时抽取或实时接入方式进入 CRM 系统，进行统一的数据清洗、去重、合并与标准化处理。关键处理策略包括历史数据清洗、订单数据合并、积分逻辑处理、会员标签动态更新、消费行为计算、活跃度模型计算。
• 目标存储与分析层（OceanBase 分析库）：清洗后的数据通过同步机制实时或定时写入 OceanBase 分析库；并分为原始数据表、静态化处理表、日表/月表、报表中间表。

通过构建“源数据 → CRM 清洗 → OceanBase 分析库”的标准化数据链路，实现了多源异构数据的统一整合、复杂分析场景的高性能响应、业务数据的长期留存与高效利用。

会员精准筛选复杂场景，查询效率提升 25.7 倍

在重药集团会员服务平台的实际运营中，多维度组合筛选（见图7）是支撑精细化营销与客户管理的核心功能。对于数据库而言，该功能是典型的复杂查询场景，用户需同时基于多个维度进行精确匹配，查询通常涉及多表关联、大量过滤条件和聚合计算，非常考验数据库的执行效率。我们通过开启 OceanBase 的列存模式（Columnar Storage），将原本传统数据库MySQL 的响应时间从 18 秒缩短至 0.7 秒，性能提升达 25.7 倍，满足业务对“实时圈选、即时触达”的严苛需求，显著提升了系统整体吞吐量与用户体验。

图7 会员服务平台多维度组合筛选

数据存储空间省 60%，有效降低存储成本压力

OceanBase 将全量数据划分为两个部分进行管理：一是增量数据（Memtable），即实时写入内存中的热数据，支持快速读写；二是基线数据（静态数据），即经过合并与持久化后的冷数据，存储于磁盘。

对于静态数据，OceanBase 采用高效的压缩算法，对列式存储的数据进行深度压缩，显著减少磁盘 I/O 和存储开销。例如，当原始数据总量为 4TB 时，MySQL 需要完整保留所有数据，存储空间占用为 4TB；而 OceanBase 通过对静态数据进行高压缩处理，仅需 1.5TB 即可承载相同规模的数据。

在重药集团会员服务平台的实际部署中，OceanBase 通过其先进的列式存储引擎与高效压缩算法，显著降低了数据存储空间占用，在同等业务数据规模下实现了 60% 以上的存储空间节约，有效缓解了海量数据带来的存储成本压力。

面向未来，持续推进 OceanBase 的深度集成与价值释放

随着 OceanBase 在重药集团会员服务平台的成功落地，我们对其在更广泛业务领域和客户群体中的应用充满信心。面向 2026 年及未来，我们将围绕场景拓展、客户推广、技术融合与产品适配四大方向，持续推进 OceanBase 的深度集成与价值释放。

应用于更多业务场景与产品

当前，OceanBase 已稳定支撑重药集团会员管理平台的复杂分析型业务（如精准筛选、标签计算、报表生成）。订单处理中心和运营诊断产品也在生产环境开始使用OceanBase，下一步，我们将推动其全面融入日常运营服务场景，包括：实时会员服务、营销活动执行、AI 智能推荐等业务场景。

另外，我们将逐步将 OceanBase 适配至更多内部产品，包括商品主数据管理、患者健康管理平台、智能补货与供应链协同系统，构建以 OceanBase 为核心的统一、弹性、智能的企业级数据基础设施。

向业内客户推荐

在国家信创政策与企业降本增效双重驱动下，我们已将 OceanBase 作为高并发、大数据量、强一致性要求场景下的首选数据库，并向行业客户积极推广。截至目前，已在以下大型医药企业成功落地：扬子江药业集团、鹭燕医学、重药集团、上海医药、国大药房。未来，我们将继续优先推荐 OceanBase 作为会员服务、订单中心等关键系统的数据库底座，助力更多企业完成安全、高效、低成本的国产化替代。

交流开发，沉淀运维经验

为持续提升团队与客户的 OceanBase 应用能力，我们计划定期组织专题培训、参与社区技术沙龙、共建问题解决机制、定期组织数据库培训及实战分享会议，探讨并解决遇到的问题，争取打造一支“懂业务、精技术、能落地”的复合型数据库应用团队。

未来，我们将携手更多合作伙伴，共同探索“数据库 + AI + 行业场景”的创新路径，为医药健康行业的高质量发展注入新动能。