摘要

MySQL 是支付系统的核心事务存储，但面对海量交易数据、多条件组合查询、模糊检索与多维统计场景时存在明显瓶颈。因此主流支付平台都会搭配 Elasticsearch 承担检索、报表、日志分析等能力。本文结合支付真实业务场景，讲解 MySQL 与 Elasticsearch 的分工、MySQL 的性能短板，重点介绍基于阿里云 DTS 实现两者数据一致性，并深入说明：支付在线检索场景，为什么首选 ES，而不是 StarRocks。

前言

在支付、交易、金融类系统中，MySQL 是当之无愧的核心存储，订单、支付流水、账户资金、对账数据等核心业务数据全部落盘在 MySQL。但随着业务规模增长，订单与流水数据量持续膨胀，单纯依靠 MySQL 已无法满足运营查询、客服检索、风控分析、数据报表等需求。

Elasticsearch（简称 ES）凭借强大的全文检索、多维聚合、海量数据查询能力，成为支付系统标配的辅助检索引擎。很多开发者会疑惑：MySQL 本身支持查询与分页，为何还要额外引入 ES？两套存储如何保证数据一致？现在 StarRocks 这么火，支付为什么不用 StarRocks，非要用 ES？

本文将围绕以上问题展开，并基于阿里云 DTS 讲解生产环境下的数据同步与一致性方案，最后讲清 ES 与 StarRocks 在支付场景的本质区别。

一、MySQL 在支付系统中的核心定位

首先明确核心原则：ES 不会替代 MySQL，二者各司其职。MySQL 是支付系统的唯一权威数据源，承担着不可替代的核心职责：

1. 强事务保障 支付涉及资金扣减、订单状态变更、退款记账等核心操作，依赖 MySQL 原生 ACID 事务，严格保证数据一致性，从根源避免资金损失、脏数据等问题。

2. 数据约束与唯一性 通过主键、唯一索引、字段约束等能力，保障支付单号、订单号、流水号全局唯一，杜绝重复支付、重复记账等业务风险。

3. 支撑核心主链路读写 下单、支付、退款、第三方回调等高频核心流程，全部基于 MySQL 完成，要求低延迟、高可用、高可靠。

简单总结：MySQL 承载真实业务与资金数据，是整个支付系统的基石；ES 作为专用检索引擎，弥补 MySQL 在复杂查询场景下的能力短板。

二、支付场景下 MySQL 的四大核心瓶颈

当订单、流水单表数据达到千万、亿级规模后，MySQL 的短板会被持续放大，单纯依赖 MySQL 会出现查询超时、接口卡顿、数据库压力过高等问题，这也是引入 ES 的核心原因。

1. 海量数据下复杂多条件查询性能低下

运营、客服、财务、风控人员日常查询，往往会组合时间范围、支付状态、支付渠道、交易金额、商户 ID、用户 ID、回调结果等十几个字段进行筛选。

• 数据量较小时，通过建立联合索引可勉强支撑；

• 数据量破千万、上亿后，灵活多变的组合条件很难全部适配索引，极易触发全表扫描，查询耗时从毫秒拉长至数秒甚至数十秒，直接导致页面卡死、接口超时。

同时 MySQL 联合索引遵循最左匹配原则，无法为每一种查询场景单独建索引；索引过多又会大幅降低数据写入、更新性能，陷入两难困境。

2. 模糊检索、全文搜索能力薄弱

支付场景中经常需要根据手机号、交易备注、外部商户单号等信息模糊定位订单。MySQL 中 like %关键词% 前后模糊匹配无法走索引，海量数据下基本不可用；其原生全文索引功能简陋，对中文分词支持较差，完全无法满足业务检索需求。

而 ES 基于倒排索引架构设计，天生擅长全文检索、分词匹配、模糊查询，是该类场景的最优解。

3. 深度分页查询性能灾难

运营导出报表、批量查看历史流水时，常会出现 limit 100000,20 这类深度分页场景。MySQL 执行深度分页时，会先扫描并丢弃前面大量数据，仅返回目标结果，造成严重的 IO、CPU 消耗，高并发场景下极易拖垮整个数据库。

ES 针对分页场景做了深度优化，提供 from/size、search_after、scroll 等多种分页方案，可稳定支撑海量数据下的大分页、批量导出需求。

4. 多维聚合统计能力不足

财务对账、运营大盘、风控监控等场景，需要按时间、渠道、商户、地区等维度，统计交易笔数、交易金额、成功率、异常订单占比等指标。 MySQL 可通过 group by、聚合函数完成简单统计，但在亿级数据下执行效率极低；频繁的统计查询还会抢占数据库资源，挤压支付主链路的性能空间，引发系统雪崩。

ES 内置强大的聚合分析能力，专门面向多维统计、实时数据可视化设计，查询压力与核心数据库完全隔离，保障主业务稳定运行。

补充：分库分表后的查询难题

中大型支付系统为应对数据体量，会对订单、流水表做分库分表。数据被拆分至数十、上百张子表后，跨表多条件查询、分页、统计的开发复杂度会急剧提升。

ES 可汇总全量数据，屏蔽分库分表细节，上层业务直接查询 ES 即可，大幅降低开发与维护成本。

三、Elasticsearch 在支付系统中的典型应用场景

结合 MySQL 的能力短板，ES 在支付体系中主要承担只读检索与数据分析工作，主流落地场景如下：

1. 运营后台 & 客服工单检索

这是 ES 在支付领域最核心的用法。将订单、支付流水、退款单数据同步至 ES，运营人员后台筛选、客服查询用户订单等操作全部走 ES，实现多条件组合检索、模糊查询秒级响应。 规范要求：数据修改、状态变更等写操作依旧走 MySQL，ES 仅做数据展示。

2. 全链路日志检索排查

支付网关、回调服务、第三方接口交互会产生海量运行日志。当出现支付失败、回调异常、掉单等线上问题时，借助 ES 搭配日志采集组件，可快速检索日志、定位故障链路，提升问题排查效率。

3. 数据报表与实时监控大屏

一方面支撑日对账、月结算、商户报表等离线统计需求；另一方面承载交易总额、交易笔数、渠道占比、异常率等实时监控大屏，为运营、风控提供数据支撑。

4. 风控数据筛查

风控系统需要快速识别大额交易、异地交易、高频交易等可疑行为，依托 ES 高效的检索与聚合能力，可快速筛选特征数据，辅助风控规则执行。

5. 历史冷数据归档查询

支付数据有严格的留存合规要求，一般需要保存 3~5 年。近 3 个月热数据 MySQL 与 ES 双存；超过 1 年的冷数据可从 MySQL 中下线，仅保留 ES 用于审计、溯源查询，释放数据库存储与性能压力。

四、基于阿里云 DTS 实现 MySQL 与 ES 数据一致性

两套存储共存，数据一致性是落地的核心难点。本文采用阿里云原生 DTS（数据传输服务） 实现 MySQL 到 ES 的数据同步，无需额外部署开源同步组件，云原生架构更适配阿里云环境，也是金融、支付行业主流方案。

4.1 DTS 同步基本原理

阿里云 DTS 底层基于 MySQL Binlog 实现数据同步，工作逻辑如下：

1. DTS 模拟 MySQL 从节点，实时订阅主库 Binlog 日志，捕获所有 insert、update、delete 数据变更操作；

2. 自动解析 Binlog 内容，完成字段映射、数据格式转换，批量组装为 ES 可识别的写入请求；

3. 批量将数据写入目标 ES 索引，正常链路下数据延迟维持在 100ms~500ms，实现准实时同步；

4. 整个过程完全不侵入业务代码，不会对支付核心主链路造成任何性能影响。

4.2 DTS 核心能力（适配支付场景）

1. 全量 + 增量双模式 首次同步可执行全量数据初始化，一次性将 MySQL 历史数据迁移至 ES；全量同步完成后自动切换为增量模式，持续同步实时数据变更，适配新老业务数据迁移场景。

2. 断点续传与自动重试 遇到网络波动、短暂服务异常时，DTS 会自动断点续传、重试同步，故障恢复后自动追平数据，避免数据中断、丢失。

3. 托管式高可用 DTS 为阿里云托管服务，自带集群高可用、故障自动切换能力，配套完善的监控、告警体系，满足金融级 SLA 要求。

4. 生态适配完善 完美兼容阿里云 RDS MySQL、PolarDB、PolarDB-X 等主流数据库，同时支持阿里云 ES 集群、Serverless ES，云原生打通无需额外配置网络。

4.3 分层一致性保障方案（支付生产标准）

支付场景对数据一致性要求极高，单一同步组件无法覆盖所有极端故障，行业通用方案为：DTS 实时同步 + 定时任务校对兜底，构建双层保障体系。

第一层：DTS 实时同步（保障准实时一致性）

作为主同步链路，负责日常数据流转：

• 数据源：MySQL 订单表、支付流水表、退款记录表等核心业务表；

• 目标端：对应业务 ES 索引；

• 同步范围：全量历史数据 + 增量 Binlog 变更；

• 效果：正常运行时，MySQL 与 ES 数据毫秒级对齐，满足检索、查询的实时性要求。

第二层：定时校对任务（保障最终一致性，强制兜底）

无论 DTS 稳定性多高，都无法规避极端场景：DTS 任务异常、ES 写入阻塞、长时间网络中断等，因此定时校对是支付系统必不可少的最后一道防线。

执行逻辑

1. 任务频率：建议每 5 分钟执行一次；

2. 数据范围：选取近 10 分钟内 MySQL 发生变更的增量数据（依据更新时间筛选）；

3. 数据比对：根据订单号、流水号等唯一主键，分别查询 MySQL 与 ES 数据进行对比；

4. 异常修复：若发现 ES 数据缺失、内容不一致、状态错误，以 MySQL 数据为准，自动覆盖修复 ES；

5. 告警机制：同一数据连续多次修复失败，立即触发钉钉、企业微信告警，通知运维人工介入排查。

核心作用

修复 DTS 短暂延迟、同步中断、ES 写入失败等问题，保证两套存储最终数据一致，彻底杜绝因数据不同步引发的业务问题。

4.4 数据读写规范（一致性红线）

为从业务层面规避数据错乱，必须严格遵守以下规范：

1. 唯一权威源：MySQL 是唯一真实数据源，所有资金核对、业务校验、数据对账，均以 MySQL 数据为准；

2. 读写分离：所有新增、修改、删除等写操作，仅操作 MySQL；运营查询、客服检索、报表统计等读操作，统一走 ES；

3. 禁止直写 ES：业务代码严禁直接修改 ES 数据，所有数据变更必须经由 MySQL + DTS 同步流转。

五、支付为什么不用 StarRocks，非要用 ES？

StarRocks 是新一代 MPP 列式 OLAP，多维聚合、报表、大屏性能极强；但支付在线检索（客服 / 运营 / 风控）场景，ES 不可替代，StarRocks 不适合。下面从支付核心诉求逐条对比，讲清楚本质差异。

5.1 核心定位完全不同

• ES：搜索引擎（倒排索引） → 主打全文检索、模糊匹配、任意字段组合过滤、高并发在线查询

• StarRocks：OLAP 数仓（列式存储 + MPP） → 主打多维分析、报表、聚合、Join、离线 / 实时大屏

支付客服 / 运营场景：不是做报表，是做 “找人、找订单、模糊搜、任意组合筛选”—— 这是搜索引擎的活，不是数仓的活。

5.2 模糊检索、全文搜索：StarRocks 完全不行

支付高频：

• 手机号、姓名、备注、商户单号、用户昵称 模糊搜索（% xxx%）

• 中文分词、关键词高亮、部分匹配

• ES：天生支持，毫秒级，倒排索引直接命中

• StarRocks：无全文索引、无分词、like 模糊走全表扫描，亿级数据下秒级甚至分钟级，客服完全不可用

5.3 高并发在线查询：ES 更稳，StarRocks 压力大

支付运营 / 客服是7×24 高并发 QPS（几十到几百）：

• ES：分布式、倒排索引、内存缓存、高并发友好，金融级稳定

• StarRocks：MPP 架构，查询重、CPU 高、并发上去易抖动，更适合低并发、大查询、报表大屏

5.4 动态 Schema、半结构化：ES 适配支付灵活字段

支付订单 / 流水经常加字段、扩字段、JSON 扩展：

• ES：动态 Mapping，自动识别字段，不用改表、不用重导

• StarRocks：强 Schema、列式固定，加字段要改表、重写数据、影响在线

5.5 深度分页、滚动导出：ES 成熟，StarRocks 短板

运营导出订单流水：limit 100000,20、scroll 批量拉取

• ES：search_after/scroll 成熟，深度分页不崩

• StarRocks：深度分页性能差，扫描代价高，不适合在线导出

5.6 运维成熟度、云生态：ES 更适配支付

• ES：阿里云 ES 托管、DTS 原生支持、监控告警完善、金融支付大规模落地（微信支付、支付宝）

• StarRocks：偏数仓 / 报表侧，阿里云支持弱、DTS 不原生同步、支付在线检索案例少

5.7 一句话总结选型

• 客服 / 运营 / 风控在线检索、模糊搜、任意过滤、高并发 → ES

• 财务报表、多维统计、实时大屏、离线分析 → StarRocks（或 Doris/ClickHouse）

支付系统标准组合：MySQL（事务）+ DTS（同步）+ ES（在线检索）+ StarRocks（报表大屏）—— 各司其职，不要混用。

六、阿里云环境支付系统标准架构（DTS 版）

结合前文内容，整理出完整的分层架构流程：

1. 业务写入：下单、支付、退款、状态变更等操作，通过事务写入 MySQL；

2. 实时同步：DTS 订阅 MySQL Binlog，实时将数据同步至 ES；

3. 业务查询：运营后台、客服系统、风控平台、数据大屏等，全部查询 ES；

4. 兜底校验：定时任务定期比对 MySQL 与 ES 数据，自动修复不一致数据并异常告警；

5. 数据归档：冷数据从 MySQL 下线，仅保留 ES 满足审计、查询需求。

七、常见误区澄清

误区 1：部署了 DTS，就可以完全不用数据校对

错误。任何中间件都存在故障概率，DTS 断点、ES 集群异常、网络故障都可能造成短暂数据不一致。定时校对 + 告警是支付系统的强制要求，是规避资损风险的底线。

误区 2：ES 可以替代 MySQL 存储核心交易数据

错误。ES 不支持强事务、不适合高频数据更新，无法承担资金、订单这类核心业务的存储工作，仅能作为检索辅助引擎。

误区 3：ES 数据可用于资金对账、清结算

错误。对账、结算、资金核算等核心财务操作，必须基于 MySQL 原始数据执行，ES 仅做展示与辅助查询。

误区 4：StarRocks 比 ES 快，应该替代 ES

错误。StarRocks 快在聚合报表；ES 快在模糊检索、高并发过滤、分页。场景不同，不能替代。

八、总结

1. 分工定位 MySQL 是支付系统的核心事务存储，保障资金与订单数据安全可靠；ES 是专业检索与分析引擎，解决海量数据下复杂查询、模糊检索、多维统计的性能问题；StarRocks 是数仓引擎，适合报表大屏，不适合支付在线检索。三者互补，而非互相替代。

2. 引入 ES 的核心价值 并非 MySQL 无法使用，而是面对亿级交易数据、多样化查询场景时，MySQL 存在天然的性能与功能瓶颈，ES 可以分担查询压力、优化使用体验、隔离业务风险。

3. 数据一致性方案（阿里云专属）

• 实时同步：采用阿里云 DTS 订阅 MySQL Binlog，实现毫秒级准实时数据同步，无业务侵入、运维简单；

• 最终兜底：搭配定时数据校对任务，自动修复异常数据并告警，构建双层一致性保障；

• 执行原则：坚守 MySQL 权威数据源身份，规范读写行为，从架构与业务双维度保障数据准确。

ES vs StarRocks 最终结论

• ES：支付在线检索（客服 / 运营 / 风控）首选，不可替代

• StarRocks：报表、大屏、多维分析首选

• 阿里云生态下，MySQL + DTS + ES 是中大型支付平台成熟、稳定、易运维的技术组合，兼顾性能、成本与安全性，也是目前行业主流的落地架构。

我的新书《金融支付架构实战指南：技术、安全与合规》已在京东，淘宝，拼多多，当当上架，对支付感兴趣的可以看看。