背景
随着财经支付业务的快速发展，考虑到未来订单量持续增长，在线存储遇到更大的挑战，需提前做好规划。目前财经支付主要业务都是使用 mysql（InnoDB）作为数据存储，因历史订单信息访问频率低并占用了大量数据库存储空间，期望将历史数据跟生产最新交易数据进行分离，当前数据库保留最近一段时间的数据作为热库，历史交易存入另一个数据库压缩存储作为冷库(rocksdb)，即数据库冷热分离。此举将会极大的节省数据库设备成本，减少因在线存储空间不足扩容导致停服不可用的时长，以下基于财经支付的统一交易系统现状做的相关案例分析仅供大家参考。
方案
技术选型
架构图
方案分析
因业务场景比较复杂，如果按照业务场景梳理工作量将几何倍的增长，换种维度，数据库相关的操作无非就是查询、插入、更新，只要能在数据库交互层实现保证查询、插入、更新这些数据库基本操作在增加冷热分离后功能不受影响即可。财经支付代码有统一的分层规范，对数据库操作全部收敛封装至数据库交互层，因此比较好改造，不扩容的情况下，热库预计保留最近 X 天（时间可调）数据， X 天前的数据归档到冷库。
方案对比
方案一：能够彻底数据库存储压力的解决方案，但是对冷库性能要求太高，如果涉及的插入、更新、查询能够根据单号过滤时间，降低对冷库的依赖。
方案二：适用于冷库性能较低，涉及的插入、更新、查询大部分无法根据单号过滤时间时，需要热库归档表中转过滤。
方案三：如果系统涉及的场景比较简单，历史订单后续也无变更，可以按场景进行归档。
方案选择
交易：交易表负责记录商户订单与财经支付内部订单的映射、交易金额、买方和卖方等重要信息，最重要的功能是防止重复交易。但是冷库相比热库性能较低，商户订单号无固定规则，无法根据单号判断时间过滤减少冷库压力，而热库 cpu 使用率很低，热库数据库计算不是瓶颈，因此交易选用方案二。交易归档表主要意义在于减少在线交易对冷库的依赖。
支付：支付表负责保存交易单用了什么支付方式、该支付方式需要扣多少钱、从哪里扣、扣到哪里去等信息，涉及的订单查询、更新、插入都可以根据交易单号或者支付单号进行判断时间减少对冷库的查询，因此支付选择方案一。
基本原则
为了充分的保证 0 事故，0 资损，方案设计时，提出了以下基本原则，在研发、测试、代码评审时均参考以下基本原则进行层层把控，可以有效的避免生产事故的发生。
数据插入唯一性：
- 热库归档表的所有唯一键必须跟要归档的热库表保持一致。
- 热库归档记录已存在的订单，冷库必须有相应数据，
- 冷库插入: 先 insert 冷库成功后 再 insert 热库归档表
- 冷库更新：更新冷库数据，使用同一个事务 先 delete 再 insert 冷库数据
- 热库删除：删除热库数据时使用冷库数据当 where 条件，所有热库字段（包含 ID）条件都满足后才能删除成功。
数据更新一致性：
- 冷库无 update 操作，所有的更新操作必须在热库进行，如果数据需要更新并且仅在冷库存在，需同步到热库后，再在热库完成更新。
- 冷库热库数据同时存在时，以热库数据为准。冷库的数据来源只有热库数据同步到冷库。
- 数据从冷库同步到热库时，操作归档表和交易表需保证在同一个是事务内完成，涉及到的查询必须使用写库。
数据查询准确性：
- 单笔查询：查询热库数据不存在时，不存在再次查询冷库（如果单号中可以判断订单日期，可再增加一层日期过滤，减少冷库查询）
- 批量查询：冷库热库数据都存在时优先返回热库数据。
- 批量查询：合并冷热库数据后，需看原先查询的接口顺序是否有要求，如果对顺序有要求合并后还需排序。
- 减少冷库压力：冷库性能较低，线上实时交易尽可能减少对冷库的查询和依赖（可通过交易单号中的日期或者归档表进行过滤）。
- 限制天数控制：数据库交互 层天数控制 为 n，归档任务控制的天数为 m，要求 m>n。例如，mode 层 有些判断订单超过 n 天的才会查询冷库，归档任务只归档 m 天前的历史数据，分开控制可以防止因调整归档天数导致数据查不到情况。
具体细节
归档表结构
归档表状态流转
一致性删除
使用冷库记录的所有字段当作删除热库的 where 条件（包含自增 id）,删除热库和更新热库归档状态为冷库需在一个事物，任一失败则回滚。
交易及支付任务（数据归档、删除、兜底）
归档任务
查询热库订单表 X （时间可调）天前的订单，同步热库订单到冷库，插入热库归档表，归档状态为处理中，放入延迟删除 mq 消息。
归档删除 TASK
常驻服务 TASK 消费删除 mq 消息，rpc 调用交易支付提供的删除接口，支持本地限流能力。
兜底任务：
主要功能：查询热库归档表中处理中修改时间超过规定时间的订单强制执行删除操作。主要用来防止 mq 异常或者日常丢失消息时，使用兜底任务可以补偿消化处理中的归档记录。
执行逻辑
数据归档任务（每天启动一次）
for {
初始化查询时间范围和分页
for{
查询 X 天前交易单 limit 1000(索引排序，滚动时间查询)
if 记录存在 并且 条数=1000 {
for 对于每条记录 {
// 启用x个协程处理
交易单幂等写入冷库（不保证最新，只保证冷库数据存在性）
幂等写归档记录表（type: PROCESSING，热库数据删除时再更新为COLD，归档记录已存在HOT状态更新为PROCESSING ）
发MQ延迟消息，X min（可配置）后删除热库数据
}
}
if 条数=1000 {
continue
}
时间范围往下推进
//记录不存在
if 结束时间超过规定时间{
break (跳出循环，任务结束)
}
redis记录当前查询条件，方便后续任务重跑恢复继续
}
}
删除热库数据，消费MQ
消费MQ记录 {
查询冷库
数据一致性删除（开启事务 条件删除热库数据，更新归档记录表状态为COLD 结束事务）
一致性删除热库失败，同步热库数据到冷库，数据一致性删除
}
兜底补偿任务（每30分钟启动一次）
{
查询归档记录表中状态为PROCESSING，修改时间为X +Y min前的记录 limit 1000
if 不存在 {
break
}
for 对于每条记录
查询冷库
数据一致性删除（开启事务 条件删除热库数据，更新归档记录表状态为COLD 结束事务）
一致性删除热库失败，同步热库数据到冷库，数据一致性删除
}
}
归档任务查询时间滚动机制：时间范围第一次起始时间为固定日期（财经支付订单最早点日期），结束时间为指定日期，下次开始时间等于上次结束时间，结束时间为上次结束时间加上指定时间范围）。每次查询下一个时间窗口时 redis 保存信息，指定日期，当天任务的时间范围，分页数。
归档任务并发处理：需支持多任务分片并发处理
提升全天归档订单量：为了不影响在线交易，全天 24 小时 区分 交易高峰、低峰、日常 三个不同时间段，归档速度不同。
交易-有归档表（查询、新增、更新）
特点: 唯一键有外部单号，订单规则随机无法根据单号判断时间，因此必须有归档表。
查询
逻辑在数据库交互层统一实现处理
存在以下部分情况可做特殊处理减少数据库冷库依赖。
- 单笔查询：
- 根据外部单号查询，如果查询的 qps 较高，可以查询冷库前使用归档表进行过滤判断。
- 根据交易单号查询，如果可以根据单号判断时间，查询冷库前使用单号进行时间范围过滤。
- 批量查询：部分功能管理后台功能分页查询，对数据查询范围要求较高的增加冷库查询逻辑时，可以增加传入的查询时间范围的开始时间过滤是否需要查询冷库，针对冷库热库都存在情况时优先保留热库数据（只过滤同一分页内的相同单号数据），如果对结果有异议可使用单号单独再次查询返回最新再次确认。跟产品和运营确认能不支持的就仅查询热库。
更新
逻辑在数据库交互层统一实现处理
插入
逻辑在数据库交互层统一实现处
支付-无归档表（查询、新增、更新）
特点: 唯一键都为内部单号，现有主要查询可以根据单号判断时间，不需要归档表，可以彻底解决热库数据库存储问题。
查询
逻辑在数据库交互层统一实现处理
存在以下部分情况可做特殊处理减少数据库冷库依赖。
单笔查询：
- 根据支付单号查询，如果可以根据单号判断时间，查询冷库前使用单号进行时间范围过滤。
批量查询：
- 根据交易单号查询，如果可以根据单号判断时间，查询冷库前使用单号进行时间范围过滤。
- 部分功能管理后台功能分页查询，对数据查询范围要求较高的增加冷库查询逻辑时，可以增加传入的查询时间范围的开始时间过滤是否需要查询冷库，针对冷库热库都存在情况时优先保留热库数据（只过滤同一分页内的相同单号数据），如果对结果有异议可使用单号单独再次查询返回最新再次确认。跟产品和运营确认能不支持的就仅查询热库。
更新
逻辑在数据库交互层统一实现处理
插入
逻辑在数据库交互层统一实现处
总结
- 支付因没有归档表彻底解决了数据库存储压力问题，大大的节省了数据库存储资源。
- 交易因新增了归档表，大大延缓了热库数据库存储压力，为交易数据库又额外提供了缓冲扩容时间，为后续再次优化彻底交易解决数据库存储问题提供了充足的时间。
成果
- 彻底解决了支付数据库存储压力问题，有效的缓解了交易数据库热库的存储压力。
- 数据库热库保留天数可灵活调控，可以根据后续订单量进行合理调整存储可用天数。
缺点
- 交易采用方案二新增了归档表，并且归档表里的存储的全量数据，仅能减缓交易和支付数据库的存储空间紧张情况，无法彻底解决数据库存储问题。
- 交易表释放的 datafree 存储空间无法提供给归档表使用，仅能交易表使用，需要不定期释放交易表的 datafree 空间。
