一、执行摘要
当前困境: 我们与客户DBA陈兴隆在成本数据上无法达成共识。我方选9-11月平均值，他不认；他要选24年12月/25年1月，我们也不认。双方都觉得对方的时间点不公平。
问题的本质（经过四场会议深入分析）
成本下降的真正原因被掩盖
不是 OB 替换带来的节省，而是内存化撮合引擎上线后业务架构变化，以及购买 RI 后成本自然下降
对比基准本身就不对
24年底/25年初 RI 覆盖率不到两成；撮合引擎内存化后 Aurora 角色完全变了；拿高配撮合的成本对比只做记录的成本不公平
OB 成本计算不完整
只算了 AWS 基础设施，没算 License、备份、运维成本
核心结论
3%
成本差异
实际差异仅约$600/月，不是30%。OB成本不含License。
2.5x
性能优势
Aurora QPS 2.5倍、延迟低2.7倍、完全零抖动。
2.8s
切换时间
JDBC Wrapper 实测，连接不中断。OB缩容QPS跌0。
我们的建议： 迁移风险大、收益小。为3%的成本差异承担迁移风险不值得。建议维持现状。
二、项目背景与关键人物
客户情况
| 客户名称 | Hashkey |
| 行业定位 | 香港合规加密货币交易所（即将上市） |
| 当前风险 | 计划将 Aurora 迁移至 OceanBase |
| 窗口期 | 农历新年后约2周 |
| 决策人 | CTO Steven |
| 执行层阻力 | DBA 陈兴隆（明确 defence OB） |
CTO Steven 决策优先级
根据饭局反馈，Steven 的决策优先级为：
稳定性
›
弹性扩缩容
›
成本优化
关键洞察: Steven 不是成本驱动，而是弹性扩缩容驱动。他想用最小成本运作，峰值来了快速弹起。
关键人物分析
S
Steven
Hashkey CTO | 决策人
在 Web3 创过业，对 AWS 认识挺深，整体印象积极。关注稳定性 > 弹性 > 成本。
✓ 利好
陈
陈兴隆
Hashkey DBA | 执行层
明确 defence OB。只怕老板，小弟在会更嚣张，老板在态度会收敛。
! 阻力
Urgan 的观察: "如果只有他的 team 在，他就会仗势欺人。他只怕老板。"
齐
齐俊
Hashkey 运维总监
态度中肯，愿意摊开来谈。建议综合评估而非单纯数字对比。关键讨论应在其在场时进行。
≈ 中立
三、成本问题全面剖析
核心问题: 这是客户最不认账的部分。我们必须把每一个细节都理清楚，让数据呈现"渐变"过程，做到"心服口服"。
问题一：时间点分歧的具体表现
我方立场（Weichi）
- 选择 2025年9-11月平均值
- Aurora 平均成本约 $20.3K/月
- OB 优化后成本约 $18.7K/月
- 差异约10个百分点
客户立场（陈兴隆）
"这里面有两个本质性的错误：分界点不是12月20多号，我们最早开始迁移是24年12月。五六月份之前非交易集群已经迁完了。Aurora 成本应该选到25年2月份左右的平均值，因为那时候还没降配。"
问题本质：为什么他的时间点不合理
24年底/25年初是 Aurora 成本的最高峰时期，用这个时期对比优化后的 OB 成本，显然不公平。
Urgan 补充的关键信息（这个在与客户会议中没有说）：
"在25年3月之前，新农的 RDS RI 不到两成。直到4月之后才会看到不断地下降，那个不断下降主要很大部分是买了 RI 之后慢慢往下降。"
这意味着：24年底/25年初 Aurora 成本高，是因为 RI 覆盖率低。后来成本下降，很大一部分是因为买了 RI，不是因为 OB 替换带来的"节省"。
问题二：成本为什么高？为什么低？
内部会议关键对话
Neo（内部讨论）
"你的 Aurora 成本在25年1月那么高，为什么到25年12月这么低？他难道没降配他直接自己神什么？什么情况他降下来了？
25年12月切换的时候忽然就少了那么多，少了400刀一天，这400刀少在哪里？谁能给我解释清楚？老板问的时候怎么答？"
25年12月切换的时候忽然就少了那么多，少了400刀一天，这400刀少在哪里？谁能给我解释清楚？老板问的时候怎么答？"
成本变化详细时间线
2024年12月初
开始迁移部分 workload → Aurora 成本开始波动
2025年3月前
RI 覆盖率不到两成 → Aurora 成本偏高（这是关键！）
2025年3月12日
上线 OMS → 架构开始变化
2025年4月后
开始购买 RI → Aurora 成本开始下降
2025年 Q2-Q3
内存化撮合引擎上线 → Aurora 用量大幅下降
2025年6月
国际站交易量下滑 → 做了缩容
2025年12月24日
OB 降配 EBS → OB 成本降至 $18.7K
Neo 的解决方案
"从25年的1月到25年的12月，每个月 Aurora 的用量以及本身配置变化——比如降配了、加 RI 了——你把这些标记清楚。因为我相信它一定是有个梯度的，一直到25年的12月。
你给他的东西让他心服口服，这个东西应该是个渐变的，渐变怎么变的？我觉得这才有说服力。"
你给他的东西让他心服口服，这个东西应该是个渐变的，渐变怎么变的？我觉得这才有说服力。"
具体要求：
- 每个月什么配置（实例类型、数量、RI 覆盖率）
- 每个集群做什么 workload
- 哪里加了 RI、哪里降了配
- 具体数字，不是一句话
问题三：OB 成本计算不完整
成本构成对比
| 成本项 | OceanBase | Aurora |
|---|---|---|
| EC2 实例 | ✓ 包含 | ✓ 包含 |
| 存储 | ✓ 包含（EBS） | ✓ 包含（IO Optimize） |
| 数据传输 | ✓ 包含 | ✓ 包含 |
| License 费用 | ✗ 未计算 | ✓ 已包含 |
| 备份存储 | ✗ 未计算 | ✓ 已包含 |
| 运维人力 | ✗ 未计算 | ✓ 托管服务 |
成本对比的真实数据
OB 调优前月费用（AWS Infra）
$20,964
Aurora 月费用（9-11月平均）
$20,294
差异
$670 (~3%)
关键结论: 在调优前，OB 和 Aurora 的成本差异仅约 3%（约$670/月）。
但这个对比有两个问题：
1. Aurora 用的是9-11月数据（RI 已加满），如果用24年底/25年初数据 Aurora 会更高——但那时候 RI 覆盖率不到两成，不公平
2. OB 成本只算了 AWS 基础设施，没算 License、备份、运维
1. Aurora 用的是9-11月数据（RI 已加满），如果用24年底/25年初数据 Aurora 会更高——但那时候 RI 覆盖率不到两成，不公平
2. OB 成本只算了 AWS 基础设施，没算 License、备份、运维
我们需要客户补齐的信息
信息清单
- 25年1-12月每月 Aurora 配置变化
- 实例类型、数量
- RI 覆盖率
- 存储配置
- 每个月哪些 workload 被迁移到 OB
- 具体业务类型
- 迁移时间点
- RI 购买时间和覆盖范围
- 撮合引擎内存化的确切上线时间
教训：历史配置问题不要再提
会议中的教训: Urgan 提到12月底为降低成本使用了 IO Optimized 配置导致读写不对称问题。陈兴隆回应："你在给自己挖坑。我觉得你们尽量不要聊这个事情了，聊这个会给自己带来更多的麻烦。"
这段历史问题反而暴露了 Aurora 在特定配置下的劣势，被客户利用作为反驳论据。
与 CTO 沟通策略: 不要提及历史配置问题，聚焦于当前和未来的能力。
与CTO的成本沟通策略
完整话术（8分钟）
AWS
步骤1: 抛出结论
"Steven，首先关于成本。您内部反馈说优化了三成，但我们核算下来，实际差异只有3%左右，也就是每月约600美金。"
AWS
步骤2: 解释为什么差距这么大
"这个差距主要来自三个地方。
第一，时间点选择。我们看了一下数据，24年底25年初那会儿，我们的 RI 覆盖率还不到两成，成本自然偏高。后来4月份补上 RI 之后，成本就下来了。如果拿那个时候的高点来对比优化后的 OB 成本，这个基准本身就不对。
第二，业务架构变化。我们了解到您的撮合引擎在 Q2-Q3 已经内存化了。这意味着 Aurora 从以前承担撮合读写，变成了现在只做记录。用量下降是架构变化带来的，不是 OB 替换省下来的。
第三，成本计算口径。OB 那边的成本只算了 AWS 基础设施——EC2、EBS、数据传输。没算 License，没算运维成本。Aurora 作为托管服务，这些都已经包含在价格里了。"
第一，时间点选择。我们看了一下数据，24年底25年初那会儿，我们的 RI 覆盖率还不到两成，成本自然偏高。后来4月份补上 RI 之后，成本就下来了。如果拿那个时候的高点来对比优化后的 OB 成本，这个基准本身就不对。
第二，业务架构变化。我们了解到您的撮合引擎在 Q2-Q3 已经内存化了。这意味着 Aurora 从以前承担撮合读写，变成了现在只做记录。用量下降是架构变化带来的，不是 OB 替换省下来的。
第三，成本计算口径。OB 那边的成本只算了 AWS 基础设施——EC2、EBS、数据传输。没算 License，没算运维成本。Aurora 作为托管服务，这些都已经包含在价格里了。"
AWS
步骤3: 给出结论
"所以从成本角度看，两边其实差不多。为了3%的差异去承担迁移风险，我们觉得不太值得。"
四、关键突破：内存化撮合引擎
关键发现! 2025年Q2-Q3 内存化撮合引擎已上线。Aurora 用量下降是业务架构变化导致，不是 OceanBase 替换。这是我们最重要的论据！
发现过程
1月14日晚 Neo + Urgan 双人会议
Urgan（Slack消息）
"从青云那边所得知的内存化撮合引擎是不是在 June/July 这个时间上线的？如果是，那就会完全符合 Aurora 需求量会下降，只留下写入 transaction 用的 Aurora。"
Urgan（会议中回忆）
"我跟你那个时候带 Weichi 去上海的时候，其实青云跟我们在小房间讲的就是他已经上线的，只不过我们那一天在聊的事情就是他们未来有可能在11月、12月会把东京跟日本站、香港跟日本站的撮合引擎合并。
所以我们那时候会觉得说他的那个 Aurora 的下降其实是符合预期，因为真的用不到。就不用那个同步操作，因为当前的合约国际站改造完了。"
所以我们那时候会觉得说他的那个 Aurora 的下降其实是符合预期，因为真的用不到。就不用那个同步操作，因为当前的合约国际站改造完了。"
齐俊的确认（后续补充）
2025年3月12日
上线 OMS
2025年 Q2~Q3
完成上线新撮合引擎（内存化）
"切换到内存化后 RDS 也没有做缩减。6月是因为国际站交易量大量下滑做的缩容。"
这意味着什么
架构变化前（24年底/25年初）
- Aurora 承担撮合引擎的读写负载
- 需要高性能、高可用配置
- 成本较高是合理的
架构变化后（25年Q2-Q3）
- 撮合引擎内存化，不再依赖数据库
- Aurora 只用于记录交易结果
- 对性能要求大幅降低
- 成本自然下降
关键结论
- Aurora 用量下降是业务架构变化导致的
- 不是 OceanBase 替换带来的"节省"
- 用24年底/25年初的数据做对比没有意义
- 那时候的配置和业务场景已经完全不同了
内部讨论的关键论断
Urgan
"讲这个意思，回去看那一段没有意义。我们就只针对现在 RDS 的用途是在记录所有撮合的记录的话，那我们只看后面的这样的使用就好，我们干嘛去看之前这件事情？没有必要。"
Neo（认同）
"我觉得这个点挺好的，把这个点突破了，本身这个东西都撮合改造完了，还要个屁的 Aurora 还要这么高性能的要求吗？没意义。"
与CTO的沟通话术
推荐话术
AWS
开场
"Steven，关于成本对比还有一个重要的背景需要说明。"
AWS
揭示真相
"我们了解到，贵司在今年 Q2-Q3 已经完成了撮合引擎的内存化改造。这意味着 Aurora 的角色发生了根本变化——从以前承担撮合读写负载，变成了现在只记录交易结果。"
AWS
说明影响
"所以 Aurora 用量下降，其实是业务架构变化带来的，不是迁移到 OB 省下来的。用24年底那会儿的数据做对比，相当于拿一个高配撮合引擎的成本，去对比一个只做记录的成本，这个对比基准本身就不对。"
AWS
结论
"我们建议聚焦在当前的实际使用场景来做评估，而不是纠结历史数据。"
五、性能对比深度分析
核心结论
2.5x
QPS 优势
108K vs 44K
2.7x
延迟优势
12ms vs 33ms
0%
Aurora 抖动
完全无抖动
1.45%
OB 抖动
30分钟测试
测试背景说明
客户（陈兴隆团队）之前做过 Aurora vs OB 的性能测试，结果显示 OB 性能更好。但我们对测试方法有疑问。
"客户的报告里只有最终的一个结果，他的测试的命令跟所选用的版本、数据库的版本跟相关的机型是没有这块信息的，他只有一个 size。"
我们的测试环境
| 配置项 | Aurora | OceanBase |
|---|---|---|
| 版本 | 3.10.2 (LTS) | 4.3.53 |
| 机型 | r8g.4xl | r7i.2xl × 3 |
| CPU/内存 | 16c/128GB | 租户 16c/128GB |
| 存储 | IO Optimize | IO2 |
| 测试客户端 | r6g.2xl | r6a.2xl |
| 测试表 | 16张 × 100万行 | 16张 × 100万行 |
| 测试模式 | 读写混合 | 读写混合 |
测试结果详细对比
10分钟测试结果
| 数据库 | 平均QPS | 平均95%延迟 | 抖动占比 |
|---|---|---|---|
| Aurora MySQL 8g | 107,960 | 12.11 ms | 0% |
| OceanBase-7i | 44,579 | 33.09 ms | 0.95% |
| OceanBase-6i | 39,040 | 37.54 ms | 0.82% |
30分钟测试结果
| 数据库 | 平均QPS | 平均95%延迟 | 抖动占比 |
|---|---|---|---|
| Aurora MySQL 8g | 108,941 | 11.94 ms | 0% |
| OceanBase-7i | 42,338 | 35.78 ms | 1.45% |
| OceanBase-6i | 39,121 | 38.64 ms | 1.20% |
趋势: 30分钟测试的抖动（1.45%）比10分钟测试（0.95%）更严重，证明时间越长，OB 抖动越明显。
可视化性能对比
QPS (万/秒)
延迟 (ms)
抖动占比
为什么客户测试结果与我们不同
客户测试 vs 我们测试
| 配置项 | 客户测试 Aurora | 我们测试 Aurora | 差异说明 |
|---|---|---|---|
| 版本 | 可能是旧版本 | 3.10.2 (LTS) | 新版性能优化 |
| 机型 | 可能是旧机型 | r8g.4xl | R8G 性能更好 |
| QPS (16c128g) | 20,783 | 188,531 | 9倍差距 |
| 99th延迟 | 59.99ms | 16.12ms | 3.7倍差距 |
"客户差可能是几方面：数据库的版本——最新的3.10.2版本性能本身就有优化；机型——R8G 的性能比英特尔包括前几代酷睿都要好很多。"
OB 为什么会有抖动
技术原理
"OB 的规律是时间越长，发生抖动的概率越大，因为写的时间越长，它做 merge 的动作发生的概率就越高。发生 merge 的话，整个性能就会变差。"
技术原因：
- OceanBase 使用 LSM-Tree 存储引擎
- 写入时会触发 Mini Merge（转储）和 Major Compaction（合并）
- Merge 过程中会产生大量写 IO，导致 tx committing wait 和 db file compact write 等待事件
- 时间越长，发生 Merge 的概率越大，抖动越明显
对交易所的影响: 假设每天处理100万笔交易，1.5%的抖动意味着有1.5万笔可能受到影响。在高频交易场景下，这种不确定性是很危险的。
GP3 vs IO2：封死客户退路
背景: 客户可能考虑用 GP3 替代 IO2 来降成本。
Urgan 的判断: "客户如果要把业务转成 GP3，那他准备等死。把他的退路直接封死。"
Urgan 的判断: "客户如果要把业务转成 GP3，那他准备等死。把他的退路直接封死。"
| 指标 | IO2 | GP3 | GP3 相对劣势 |
|---|---|---|---|
| 平均响应时间 | 基准 | 约 3 倍 | 延迟高3倍 |
| 2倍延迟抖动占比 | 0% | 5.6% | 抖动严重 |
| 3倍延迟抖动占比 | 0% | 11% | 严重抖动 |
| 抖动发生概率 | 基准 | 20倍以上 | 极不稳定 |
"IO2 在平均延迟时间的2到3倍这个区间，是没有发生响应时间恶化的。GP3 抖动发生的概率是 IO2 的，少说是20倍以上。"
与CTO的性能沟通话术
完整话术（5分钟）
AWS
开场
"关于性能，我们做了严格的对比测试，用的是最新的 Aurora 3.10.2 版本和 R8G 机型。结果是这样的——"
AWS
数据呈现
"吞吐量是 OB 的2.5倍，每秒能处理10万8千次查询，OB 只有4万4。
延迟只有 OB 的三分之一，12毫秒 vs 33毫秒。
最重要的是，Aurora 完全没有性能抖动，而 OB 有接近1.5%的时间会出现延迟突增。"
延迟只有 OB 的三分之一，12毫秒 vs 33毫秒。
最重要的是，Aurora 完全没有性能抖动，而 OB 有接近1.5%的时间会出现延迟突增。"
AWS
业务影响
"对于交易所来说，1.5%的抖动意味着什么？假设每天处理100万笔交易，就有1.5万笔可能受到影响。在高频交易场景下，这种不确定性是很危险的。"
AWS
解释测试差异
"我理解之前的测试结果可能不太一样，这主要是因为版本和机型的差异。3.10.2 版本有很多性能优化，R8G 比之前的机型性能提升也很明显。"
AWS
结论
"所以从稳定性角度看，Aurora 是更适合交易所场景的选择。"
六、易用性对比深度分析（扩缩容）
关键背景: 客户选择 OB 的核心原因是扩缩容痛点。传统 Aurora 切换接近分钟级，对合规交易所不可接受。OB 宣传可以"无中断"扩缩容。
Aurora 切换能力的演进
| 方案 | 切换时间 | 连接状态 | 说明 |
|---|---|---|---|
| 传统方式 | ~1分钟 | 中断 | 需要应用重连 |
| JDBC Wrapper | 2.8秒 | 不中断 | OKX 客户实测 |
| Blue-Green | 27ms | 不中断 | 实验室验证 |
JDBC Wrapper 方案详解
技术原理
- AWS Advanced JDBC Wrapper 是一个驱动层插件
- 包含
bg(Blue-Green)、failover2、efm2等插件 - 能够感知集群状态变化，自动切换连接
- 连接被 Wrapper hold 住，应用层无感知
- 重试机制：5次尝试，500ms 退避
实际效果
| 切换时间 | 2.8秒 |
| 连接状态 | 不中断 |
| 应用改造 | 仅需修改 JDBC URL |
| 客户案例 | OKX（TOP3 交易所） |
Blue-Green 部署方案
27ms
最快停机时间
实验室验证
100%
成功率
自动重试
0
永久失败事务
零失败
55%
Worker受影响率
自动恢复
OB 扩缩容的真实情况
OB 官方宣传: "无中断扩缩容"
我们测试发现: 宣传是片面的，只有扩容时成立，缩容时有严重问题。
我们测试发现: 宣传是片面的，只有扩容时成立，缩容时有严重问题。
| 场景 | OB 实际表现 | 问题严重程度 |
|---|---|---|
| 租户扩容 | 无中断，无性能波动 | ✅ 正常 |
| 集群扩容 | 最高 10倍+性能下降，持续40秒 | ⚠️ 有问题 |
| 租户缩容 | QPS 跌到0，约4秒 | ❌ 严重 |
| 集群缩容 | 连接中断，需重连 | ❌ 严重 |
SSO 专家的发现
Jichun（SSO）
"他租户缩容和扩容现象差异大。缩容有性能波动、QPS 跌到0、连接中断等问题。他们可能一味强调扩容对服务没有影响，强调的是片面在扩容方面的，在缩容方面如果别人不特别清楚不去挑战他的话，他可能就不说了。"
Neo 在与客户会议中的提问
Neo（向陈兴隆提问）
"我了解到 OceanBase 在扩容的时候，连接虽然没有中断，但实际上QPS 会降为零。还有缩容的话也会有一些影响，不像之前了解的完全无中断。"
陈兴隆（回应）
"今天时间不够了，后面我们再约个时间，看一下我们的问题。"
注：陈兴隆没有否认这个问题，只是回避了讨论。
香港 R8G 机型问题
当前问题
"目前香港区有一个不好的点，就是香港的 R8G 迟迟还没有整个落地。"
"我从 Q3 听到 Q1 了，要很久了，要不到。"
重要性：
"未来客户会把所有的 workload 全部回到香港，东京只是一个中场，作为切换演练测试。最后所有 work 都回到香港，所以香港如果有 R8G 这样的实力才能支持到他们当前的业务。"
R6/R7/R8 性能对比
| 对比 | 性能差异 |
|---|---|
| R6 → R7 | 差距不明显 |
| R6 → R8 | 绝对性的差距 |
应对策略: 坦诚说 Q1 推进中，强调 R7 也有明显优势。如果需要可以 escalate。
与CTO的易用性沟通话术
完整话术（5分钟）
AWS
开场
"Steven，您之前提到扩缩容是选择 OB 的一个重要原因。这一点我们完全理解——传统的 Aurora 切换确实接近分钟级，对交易所来说不可接受。但我们现在有了新的解决方案。"
AWS
展示改进
"通过 JDBC Wrapper，我们在 TOP3 交易所客户那边实测，切换时间只要 2.8秒，而且连接完全不中断。应用层不需要改代码，只需要换一下数据库驱动。
我们还有 Blue-Green 部署方案，可以做到 27毫秒切换，这是我们在实验室验证的结果。"
我们还有 Blue-Green 部署方案，可以做到 27毫秒切换，这是我们在实验室验证的结果。"
AWS
揭示OB问题
"另外，关于 OB 的扩缩容，我们做了测试发现一些情况。他们宣传的'无中断'只是扩容时成立。
缩容的时候，租户缩容会导致 QPS 跌到0，集群缩容会导致连接中断。这个信息可能您的团队没有提到。"
缩容的时候，租户缩容会导致 QPS 跌到0，集群缩容会导致连接中断。这个信息可能您的团队没有提到。"
AWS
结论
"所以从弹性扩缩容这个角度，我们现在的方案已经可以做到秒级切换、连接不中断，比 OB 的缩容表现要好。"
七、与CTO沟通完整指南
沟通目标
主要目标
- 纠正成本认知偏差：30% → 实际3%
- 解释成本为什么高/低：RI、架构变化、计算口径
- 展示技术能力升级：切换从分钟级降到秒级
- 揭示OB的真实问题：缩容时QPS跌0、连接中断
- 给CTO一个"不动"的台阶：迁移风险大、收益小
核心策略
不要打技术口水仗，要站在CEO视角讲业务价值。
Steven 关心的是：稳定性 > 弹性 > 成本
我们的故事线要对应这个优先级：
- 稳定性：性能2.5倍，完全无抖动
- 弹性：JDBC Wrapper 2.8秒切换
- 成本：差异只有3%，不值得冒险
完整沟通流程（总时长约23分钟）
1
开场（2分钟）
"Steven，感谢您抽时间。我们知道您的团队在评估数据库方案，今天想跟您分享一些最新的数据和我们的技术能力更新。有几个点可能跟您之前了解的不太一样。"
2
成本澄清（8分钟）
- 抛出结论：差异只有3%，不是30%
- 解释三个原因：时间点、架构变化、计算口径
- 强调：RI 覆盖率、内存化撮合、License 未计算
3
性能展示（5分钟）
- 数据呈现：QPS 2.5倍、延迟低3倍、零抖动
- 业务影响：1.5万笔交易可能受影响
- 解释测试差异：版本和机型
4
弹性能力（5分钟）
- 展示改进：JDBC Wrapper 2.8秒切换
- 揭示OB问题：缩容QPS跌0、连接中断
- 强调：TOP3 客户已验证
5
建议方案（3分钟）
"基于以上这些，我们的建议是维持现状。Aurora 不仅能满足当前需求，还能支撑您上市后的业务扩展——合约、CaaS、全球共享流动性。迁移有风险——学习曲线、潜在问题、运维负担。而收益呢？只有3%的成本差异。我们觉得不太值得。"
完整话术逐字稿
第一部分：开场（2分钟）
AWS
"Steven，感谢您抽时间。我们知道您的团队在评估数据库方案，今天想跟您分享一些最新的数据和我们的技术能力更新。有几个点可能跟您之前了解的不太一样。"
第二部分：成本澄清（8分钟）
AWS
2.1 抛出结论
"首先关于成本。您内部反馈说优化了三成，但我们核算下来，实际差异只有3%左右，也就是每月约600美金。"
AWS
2.2 解释为什么差距这么大
"这个差距主要来自三个地方。
第一，时间点选择。我们看了一下数据，24年底25年初那会儿，我们的 RI 覆盖率还不到两成，成本自然偏高。后来4月份补上 RI 之后，成本就下来了。如果拿那个时候的高点来对比优化后的 OB 成本，这个基准本身就不对。
第二，业务架构变化。我们了解到您的撮合引擎在 Q2-Q3 已经内存化了。这意味着 Aurora 从以前承担撮合读写，变成了现在只做记录。用量下降是架构变化带来的，不是 OB 替换省下来的。
第三，成本计算口径。OB 那边的成本只算了 AWS 基础设施——EC2、EBS、数据传输。没算 License，没算运维成本。Aurora 作为托管服务，这些都已经包含在价格里了。"
第一，时间点选择。我们看了一下数据，24年底25年初那会儿，我们的 RI 覆盖率还不到两成，成本自然偏高。后来4月份补上 RI 之后，成本就下来了。如果拿那个时候的高点来对比优化后的 OB 成本，这个基准本身就不对。
第二，业务架构变化。我们了解到您的撮合引擎在 Q2-Q3 已经内存化了。这意味着 Aurora 从以前承担撮合读写，变成了现在只做记录。用量下降是架构变化带来的，不是 OB 替换省下来的。
第三，成本计算口径。OB 那边的成本只算了 AWS 基础设施——EC2、EBS、数据传输。没算 License，没算运维成本。Aurora 作为托管服务，这些都已经包含在价格里了。"
AWS
2.3 给出结论
"所以从成本角度看，两边其实差不多。为了3%的差异去承担迁移风险，我们觉得不太值得。"
第三部分：性能展示（5分钟）
AWS
3.1 开场
"关于性能，我们做了严格的对比测试，用的是最新的 Aurora 3.10.2 版本和 R8G 机型。结果是这样的——"
AWS
3.2 数据呈现
"吞吐量是 OB 的2.5倍，每秒能处理10万8千次查询，OB 只有4万4。
延迟只有 OB 的三分之一，12毫秒 vs 33毫秒。
最重要的是，Aurora 完全没有性能抖动，而 OB 有接近1.5%的时间会出现延迟突增。"
延迟只有 OB 的三分之一，12毫秒 vs 33毫秒。
最重要的是，Aurora 完全没有性能抖动，而 OB 有接近1.5%的时间会出现延迟突增。"
AWS
3.3 业务影响
"对于交易所来说，1.5%的抖动意味着什么？假设每天处理100万笔交易，就有1.5万笔可能受到影响。在高频交易场景下，这种不确定性是很危险的。"
AWS
3.4 解释测试差异
"我理解之前的测试结果可能不太一样，这主要是因为版本和机型的差异。3.10.2 版本有很多性能优化，R8G 比之前的机型性能提升也很明显。"
AWS
3.5 结论
"所以从稳定性角度看，Aurora 是更适合交易所场景的选择。"
第四部分：弹性能力（5分钟）
AWS
4.1 开场
"您之前提到扩缩容是选择 OB 的一个重要原因。这一点我们完全理解——传统的 Aurora 切换确实接近分钟级，对交易所来说不可接受。但我们现在有了新的解决方案。"
AWS
4.2 展示改进
"通过 JDBC Wrapper，我们在 TOP3 交易所客户那边实测，切换时间只要 2.8秒，而且连接完全不中断。应用层不需要改代码，只需要换一下数据库驱动。
我们还有 Blue-Green 部署方案，可以做到 27毫秒切换。"
我们还有 Blue-Green 部署方案，可以做到 27毫秒切换。"
AWS
4.3 揭示OB问题
"另外，关于 OB 的扩缩容，我们做了测试发现一些情况。他们宣传的'无中断'只是扩容时成立。缩容的时候，租户缩容会导致 QPS 跌到0，集群缩容会导致连接中断。这个信息可能您的团队没有提到。"
AWS
4.4 结论
"所以从弹性扩缩容这个角度，我们现在的方案已经可以做到秒级切换、连接不中断，比 OB 的缩容表现要好。"
第五部分：建议方案（3分钟）
AWS
"基于以上这些，我们的建议是维持现状。
Aurora 不仅能满足当前需求，还能支撑您上市后的业务扩展——合约、CaaS、全球共享流动性这些，我们都能支持。
迁移有风险——学习曲线、潜在问题、运维负担。而收益呢？只有3%的成本差异。我们觉得不太值得。
当然，如果您觉得还有什么需要我们证明或者深入聊的，我们随时配合。"
Aurora 不仅能满足当前需求，还能支撑您上市后的业务扩展——合约、CaaS、全球共享流动性这些，我们都能支持。
迁移有风险——学习曲线、潜在问题、运维负担。而收益呢？只有3%的成本差异。我们觉得不太值得。
当然，如果您觉得还有什么需要我们证明或者深入聊的，我们随时配合。"
关键话术速查卡
💰 成本
"实际差异只有3%，不是30%。24年底 RI 覆盖率不到两成，成本自然高。OB 的成本还没算 License。"
🔄 架构变化
"撮合引擎内存化后，Aurora 只做记录。用量下降是架构变化带来的，不是 OB 替换省的。"
⚡ 性能
"性能2.5倍，延迟低3倍，完全无抖动。"
🔀 弹性
"JDBC Wrapper 2.8秒切换，连接不断。OB 缩容会导致 QPS 跌0。"
八、风险与应对策略
风险1: 陈兴隆当场反驳
可能的反驳: "你们的数据不对，我们测过 OB 性能更好。"
应对话术: "测试结果的差异主要来自版本和机型。我们用的是最新的3.10.2版本和R8G机型。如果需要，我们可以安排一次联合测试，用相同的环境和参数对比。"
关键策略: 保持冷静，数据说话。不要陷入技术口水仗。把问题抛回给 Steven："这些都是技术细节，我们可以安排专门的技术会议详细讨论。关键是从业务角度看，迁移的风险和收益是否匹配。"
应对话术: "测试结果的差异主要来自版本和机型。我们用的是最新的3.10.2版本和R8G机型。如果需要，我们可以安排一次联合测试，用相同的环境和参数对比。"
关键策略: 保持冷静，数据说话。不要陷入技术口水仗。把问题抛回给 Steven："这些都是技术细节，我们可以安排专门的技术会议详细讨论。关键是从业务角度看，迁移的风险和收益是否匹配。"
风险2: 客户坚持用24年数据对比
可能的坚持: "24年底才是迁移前的真实成本，你们后来的优化不算数。"
应对话术: "我理解这个想法。但有两个问题：1. 24年底那会儿 RI 覆盖率不到两成，成本自然偏高。如果当时就买了 RI，成本会低很多。2. 更重要的是，撮合引擎内存化之后，Aurora 的角色完全变了。用高配撮合的成本对比只做记录的成本，这个基准本身就不对。我们建议聚焦在当前的实际使用场景来评估。"
应对话术: "我理解这个想法。但有两个问题：1. 24年底那会儿 RI 覆盖率不到两成，成本自然偏高。如果当时就买了 RI，成本会低很多。2. 更重要的是，撮合引擎内存化之后，Aurora 的角色完全变了。用高配撮合的成本对比只做记录的成本，这个基准本身就不对。我们建议聚焦在当前的实际使用场景来评估。"
风险3: 被问香港 R8G
可能的问题: "你们说 R8G 性能好，但香港没有 R8G 啊。"
应对话术: "R8G 在香港的落地我们正在推进，预计 Q1 完成。不过即使用现在的 R7 机型，性能也比之前有明显提升。而且您现在的业务主要在日本区，等迁回香港的时候，R8G 应该已经就绪了。"
应对话术: "R8G 在香港的落地我们正在推进，预计 Q1 完成。不过即使用现在的 R7 机型，性能也比之前有明显提升。而且您现在的业务主要在日本区，等迁回香港的时候，R8G 应该已经就绪了。"
风险4: Steven 已决定迁移
可能的态度: "我们已经决定了，OB 有很多优势。"
应对话术: "理解您的决定。不过在正式执行前，我们建议再评估一下迁移风险：1. 学习曲线——团队需要时间适应新系统。2. 潜在问题——OB 缩容时的 QPS 跌0 问题在生产环境可能更严重。3. 运维负担——自建数据库的运维成本。如果收益只有3%的成本差异，这个风险收益比值得再考虑一下。"
应对话术: "理解您的决定。不过在正式执行前，我们建议再评估一下迁移风险：1. 学习曲线——团队需要时间适应新系统。2. 潜在问题——OB 缩容时的 QPS 跌0 问题在生产环境可能更严重。3. 运维负担——自建数据库的运维成本。如果收益只有3%的成本差异，这个风险收益比值得再考虑一下。"
风险5: 被问全球架构能力
可能的问题: "你们说能支撑全球共享流动性，具体怎么实现？"
应对话术: "全球架构这块，Aurora Global Database 可以支持跨区域复制，延迟通常小于1秒。具体的方案设计，我们可以安排专门的架构讨论。您上市后的业务扩展需求——合约、CaaS、全球共享流动性——我们都能支持。"
应对话术: "全球架构这块，Aurora Global Database 可以支持跨区域复制，延迟通常小于1秒。具体的方案设计，我们可以安排专门的架构讨论。您上市后的业务扩展需求——合约、CaaS、全球共享流动性——我们都能支持。"
九、后续行动项
紧急 Rehearsal 前完成（01/15 上午11点前）
1
与郭嘉/齐俊确认内存化撮合引擎上线时间点
2
准备成本渐变数据报表（25年1-12月每月配置变化）
3
获取 JDBC Wrapper 效果资料（含 OKX 客户案例）
4
整理 SSO 测试资料（完整测试报告 + 对比表格）
高优先级 与 CTO 会面时分工
A
主讲技术优势（性能、扩缩容、JDBC Wrapper）
B
数据支撑（成本分析、渐变数据、RI 覆盖率）
C
关系维护（开场、收尾、商务沟通）
需要客户补齐的信息
- 25年1-12月每月 Aurora 配置变化
- 实例类型、数量
- RI 覆盖率
- 存储配置
- 每个月哪些 workload 被迁移到 OB
- 具体业务类型
- 迁移时间点
- RI 购买时间和覆盖范围
- 撮合引擎内存化的确切上线时间
结语
核心信息四句话
💰
成本差异只有3%，不是30%
24年底 RI 覆盖率不到两成；OB 不含 License
⚡
性能我们是2.5倍，完全无抖动
QPS 108K vs 44K；延迟 12ms vs 33ms
🔀
切换2.8秒不断连，OB缩容QPS跌0
JDBC Wrapper 已在 TOP3 客户验证
🎯
迁移风险大、收益小，建议维持现状
为3%承担迁移风险不值得
有了这份报告，我们可以自信地与任何人沟通——无论是内部 rehearsal、与 CTO 的正式会面，还是后续的技术深潜。
准备就绪，可以开始了。
准备就绪，可以开始了。
十、附录：详细技术数据
附录A：10分钟测试详细数据
| 并发 | Aurora QPS | Aurora 95%延迟 | OB-7i QPS | OB-7i 95%延迟 |
|---|---|---|---|---|
| 8 | 21,719 | 6.79ms | 8,348 | 18.61ms |
| 16 | 39,314 | 7.84ms | 18,911 | 15.83ms |
| 32 | 71,220 | 8.58ms | 35,428 | 17.32ms |
| 64 | 124,479 | 9.56ms | 53,656 | 26.20ms |
| 128 | 189,862 | 13.70ms | 65,547 | 47.47ms |
| 256 | 201,172 | 26.20ms | 85,582 | 73.13ms |
附录B：30分钟测试详细数据
| 并发 | Aurora QPS | Aurora 95%延迟 | OB-7i QPS | OB-7i 95%延迟 |
|---|---|---|---|---|
| 8 | 22,267 | 6.55ms | 8,811 | 17.95ms |
| 16 | 40,010 | 7.84ms | 17,060 | 17.63ms |
| 32 | 70,730 | 8.74ms | 34,441 | 17.95ms |
| 64 | 124,273 | 9.56ms | 52,432 | 27.66ms |
| 128 | 187,928 | 13.70ms | 65,297 | 47.47ms |
| 256 | 208,443 | 25.28ms | 75,983 | 86.00ms |
关键趋势: 30分钟测试的抖动（1.45%）比10分钟测试（0.95%）更严重，证明时间越长，OB 抖动越明显。
附录C：扩缩容对比详细数据
| 扩缩容类型 | 数据库 | 方式 | 服务中断 | 服务影响 |
|---|---|---|---|---|
| 垂直扩容 | OB | 租户扩容 | 0 | 无影响 |
| OB | 集群扩容 | 0 | 最高10倍+性能下降，40s | |
| 垂直缩容 | OB | 租户缩容 | 0 | QPS 跌0，4s |
| OB | 集群缩容 | <1s | 连接中断 | |
| 垂直扩/缩容 | Aurora | 预置Failover | <4s | 需重试机制 |
| 垂直扩/缩容 | Aurora | JDBC Wrapper | 2.8s | 连接不中断 |
| 版本升级 | Aurora | Blue-Green | 27ms | 连接不中断 |
附录D：GP3 vs IO2 对比数据
| 指标 | IO2 | GP3 | GP3 相对劣势 |
|---|---|---|---|
| 平均响应时间 | 基准 | 约 3 倍 | 延迟高3倍 |
| 2倍延迟抖动占比 | 0% | 5.6% | 抖动严重 |
| 3倍延迟抖动占比 | 0% | 11% | 严重抖动 |
| 抖动发生概率 | 基准 | 20倍以上 | 极不稳定 |
Urgan 的策略: "客户如果要把业务转成 GP3，那他准备等死。把他的退路直接封死。"
附录E：Blue-Green 部署详细数据
| 指标 | 结果 |
|---|---|
| 最快停机时间 | 27ms |
| 成功率 | 100% |
| 永久失败事务 | 0 |
| Worker 受影响率 | 约55%，由重试机制自动恢复 |
| 重试机制 | 5次尝试，500ms 退避 |
| 应用改造 | 仅需修改 JDBC URL |
附录F：关键时间线
| 时间 | 事件 | 对成本/架构的影响 |
|---|---|---|
| 2024年12月初 | 开始迁移部分 workload 到 OB | Aurora 成本开始波动 |
| 2025年3月前 | Aurora RI 覆盖率不到两成 | Aurora 成本较高（关键！） |
| 2025年3月12日 | 上线 OMS | 架构开始变化 |
| 2025年4月后 | 开始购买 RI | Aurora 成本开始下降 |
| 2025年 Q2-Q3 | 内存化撮合引擎上线 | Aurora 角色变化，用量大幅下降 |
| 2025年6月 | 国际站交易量下滑 | 做了缩容 |
| 2025年12月24日 | OB 降配 EBS | OB 成本降至 $18.7K |
附录G：会议原始对话精选
会议一：与客户DBA的关键对话
陈兴隆（关于时间点）
"这里面有两个本质性的错误：分界点不是12月20多号，我们最早开始迁移是24年12月。五六月份之前非交易集群已经迁完了。Aurora 成本应该选到25年2月份左右的平均值，因为那时候还没降配。"
陈兴隆（关于 OB 优化空间）
"我们用的机器本身是比那个 R6G 要贵10%，用的是 R6A。然后那个非交易集群的 IOPS 我们还没改，这两个加起来的话可能还会省个百分之十几的比例。"
Urgan（历史配置问题）
"12月底切换前 workload 在 Aurora 上，部分配置为降低 EBS 费用使用了 IO Optimized 配置，但这会造成读写不对称的问题。我们好几天晚上都在 debug 那个问题。"
陈兴隆（反驳）
"你在给自己挖坑。我觉得你们尽量不要聊这个事情了，聊这个会给自己带来更多的麻烦。"
齐俊（建设性意见）
"我觉得反而就是应该要全部都写进去。我建议我们拿两个时间点，列清楚配置、IO花费、流量花费，这是一个综合评估的数字。"
会议二：内部讨论的关键对话
Neo（关于历史对比）
"你不能比较24年的 Aurora，你现在的 OceanBase 对比24年 Aurora，我觉得这是扯淡的。"
Urgan（关键信息）
"在25年3月之前，新农的 RDS RI 不到两成。直到4月之后才会看到不断地下降，那个不断下降主要很大部分是买了 RI 之后慢慢往下降。"
Neo（追问成本下降原因）
"你的 Aurora 成本在25年1月那么高，为什么到25年12月这么低？少了400刀一天，这400刀少在哪里？谁能给我解释清楚？老板问的时候怎么答？"
Neo（关于数据呈现）
"你给他的东西让他心服口服，这个东西应该是个渐变的，渐变怎么变的？我觉得这才有说服力。"
Urgan（关于陈兴隆态度）
"他的态度有没有老板在现场是一个决定的。他只怕老板。如果只有他的 team 在，他就会仗势欺人。以前有齐俊在现场，他讲完话之后就说'都给他老板决定'，很客气。但你跟他单独催的时候不是这个样子。"
会议三：Neo + Urgan 关键发现
Urgan（关键发现）
"从青云那边所得知的内存化撮合引擎是不是在 June/July 这个时间上线的？如果是，那就会完全符合 Aurora 需求量会下降，只留下写入 transaction 用的 Aurora。"
Urgan（回忆上海会议）
"我跟你那个时候带 Weichi 去上海的时候，其实青云跟我们在小房间讲的就是他已经上线的。所以我们那时候会觉得说他的那个 Aurora 的下降其实是符合预期，因为真的用不到。"
Urgan（核心论断）
"讲这个意思，回去看那一段没有意义。我们就只针对现在 RDS 的用途是在记录所有撮合的记录的话，那我们只看后面的这样的使用就好，我们干嘛去看之前这件事情？没有必要。"
Neo（认同）
"我觉得这个点挺好的，把这个点突破了，本身这个东西都撮合改造完了，还要个屁的 Aurora 还要这么高性能的要求吗？没意义。"
会议四：SSO 专家的发现
Jichun（关于测试差异）
"客户差可能是几方面：数据库的版本——最新的3.10.2版本性能本身就有优化；机型——R8G 的性能比英特尔包括前几代酷睿都要好很多。"
Jichun（关于 OB 抖动）
"OB 的规律是时间越长，发生抖动的概率越大，因为写的时间越长，做 merge 的动作发生的概率就越高。发生 merge 的话，整个性能就会变差。"
Jichun（关于 OB 缩容）
"他们可能一味强调扩容对服务没有影响，强调的是片面在扩容方面的，在缩容方面如果别人不特别清楚不去挑战他的话，他可能就不说了。"
Urgan（关于 GP3）
"客户如果要把业务转成 GP3，那他准备等死。把他的退路直接封死。"