项目经验_之_海量冷热数据分离
前言
Github：https://github.com/HealerJean
来自字节：https://mp.weixin.qq.com/s/ZKRkZP6rLHuTE1wvnqmAPQ
1、为什么要冷热分离
历史订单信息访问频率低并占用了大量数据库存储空间，期望将历史数据跟生产最新交易数据进行分离，当前数据库保留最近一段时间的数据作为热库，历史交易存入另一个数据库压缩存储作为冷库(
rocksdb)，即数据库冷热分离。此举将会极大的节省数据库设备成本，减少因在线存储空间不足扩容导致停服不可用的时长，以下基于财经支付的统一交易系统现状做的相关案例分析仅供大家参考。
2、方案
2.1、方案分析
因业务场景比较复杂，如果按照业务场景梳理工作量将几何倍的增长，换种维度，数据库相关的操作无非就是查询、插入、更新，只要能在数据库交互层实现保证查询、插入、更新这些数据库基本操作在增加冷热分离后功能不受影响即可。
因此对数据库操作全部收敛封装至数据库交互层，不扩容的情况下，热库预计保留最近 X 天（时间可调）数据， X 天前的数据归档到冷库。
2.1.1、方案一：
2.1.1.1、方案特点
不新增热库归档表，读冷库依赖教高，能够彻底解决冷热存储压力问题
2.1.1.2、插入改动量（幂等）
插入数据前检查，根据唯一键查冷库，冷库不存在走原有插入热裤逻辑，冷库存在则返回记录已存在走后续幂等逻辑
⬤ 临界问题：先查冷库数据不存在，然后发生归档。冷库新增，同时删除热库数据，再
insert热库订单，此时幂等失效。订单重复⬤ 解决方案：热库数据延迟删除，在数据写入冷库后延迟，
Xmin时间才删除热库数据（即使临界，热库也是有数据的，说明不能插入了，走幂等逻辑）
2.1.1.3、更新改动量
更新前检查，查询热库记录是否存在，不存在则查询冷库，冷库存在则写回到热库中，在热库中进行更新
2.1.1.4、查询改动量
单笔查询：先查热库，热库不存在再查冷库
批量查询：热库冷库都查询，数据合并，优先保存热库
forupdate查询： 先查热库，热库不存在查询冷库，回写到热热库中，再查询热库（和更新有点像，是吧）
2.1.1.5、定时任务删除热库接口改动量
⬤ 归档任务
⬤ 热库删除接口
2.1.1.6、优势和劣势
优势：
1、侵入业务少
2、能彻底解决热库存储压力问题
缺点：
1、对冷库依赖较高
2、对冷库性能要求很高，与热库基本一致
2.1.2、方案2：
2.1.2.1、方案特点
新增热库归档表，归档表数据不会被归档，降低对冷库的依赖，能够延缓数据库存储压力
2.1.2.2、插入改动量（幂等）
插入前检查：根据唯一键查询热库归档记录表，归档不存在走原有插入逻辑，归档记录存在则返回记录已存在，走后续幂等逻辑
⬤ 临界问题：先查询归档记录表数据不存在，然后发生归档删除热库数据，再
insert订单，此时幂等失效，有订单重复风险⬤ 解决方案：热库数据延迟删除，在数据写入冷库库，并且归档表新增记录后，延迟
Xmin才删除热库数据，更新归档状态
2.1.2.3、更新改动量
更新前检查：查询热库归档表状态，根据归档状态判断
⬤ 热库，流程继续，更新热库流程
⬤ 冷库：回写到热库，在热库中进行更新
⬤ 处理中，更新归档表状态为热库，流程继续更新
2.1.2.4、查询改动量
单笔查询：先查热库，热库不存在再查询冷库（请求量大可以根据归档表过滤下）
批量查询：热库冷库都查询，数据合并，有限保存热库
forupdate查询：先查热库，热库不存在查询冷库，回写到热库，再查询热库（和更新有点像）
2.1.2.5、定时任务删除热库改动量
⬤ 归档任务
⬤ 热库删除接口
⬤ 归档兜底任务
2.1.2.6、优势和劣势
优势：
1、侵入业务少
2、对冷库依赖少
3、能够延缓热库存储压力问题
4、冷库性能要求不高
劣势：
1、新增热库归档表
2、新新增的热库归档表记录全量数据，没有彻底解决热库存储压力
3、插入、更新、查询依赖查询热库归档，热库压力增加
2.1.3、方案三
2.1.3.1、方案特点
按业务场景分类，针对不会变更的终态历史数据进行归档，能够延缓数据库存储压力
2.1.3.2、插入改动量
要根据时间场景查询，不会再重入数据做归档，也就是说要要归档的数据肯定是不会再有重复插入的操作了，所以不需要考虑边界
2.1.3.2、更新改动量
要根据时间场景查询，不会再重入数据做归档，也就是说要要归档的数据肯定是不会再有重复插入的操作了，所以不需要考虑边界
2.1.3.3、查询改动量
单笔查询：先差热库，热库不存在，再查询冷库
批量查询：冷库热刻苦都查询，数据合并，优先保存热库
forupdate：查询要实际场景查询， 不会再重入数据做归档（和更新和插入有点像）
2.1.3.4、定时任务删除热库改动量
⬤ 归档并删除热库任务
2.1.3.5、优势和劣势
优势：
1、能够延缓数据库存储压力
2、对冷库依赖较小
3、对冷库性能要求不高
劣势：
1、归档不彻底，没有彻底解决热库存储压力
2、后续维护成本高，需要一直维护新增场景和场景变更确认是否需要归档
3、对业务侵入多，各种订单关联关系设计复杂开发
2.2、方案对比
⬤ 方案一：能够彻底数据库存储压力的解决方案，但是对冷库性能要求太高，如果涉及的插入、更新、查询能够根据单号过滤时间，降低对冷库的依赖。
⬤ 方案二：适用于冷库性能较低，涉及的插入、更新、查询大部分无法根据单号过滤时间时，需要热库归档表中转过滤。
⬤ 方案三：如果系统涉及的场景比较简单，历史订单后续也无变更，可以按场景进行归档。
2.3、方案选择
2.3.1、交易
交易：交易表负责记录商户订单与财经支付内部订单的映射、交易金额、买方和卖方等重要信息，最重要的功能是防止重复交易。但是冷库相比热库性能较低，商户订单号无固定规则，无法根据单号判断时间过滤减少冷库压力，而热库 cpu 使用率很低，热库数据库计算不是瓶颈，因此交易选用方案二。交易归档表主要意义在于减少在线交易对冷库的依赖。
2.3.2、支付
支付：支付表负责保存交易单用了什么支付方式、该支付方式需要扣多少钱、从哪里扣、扣到哪里去等信息，涉及的订单查询、更新、插入都可以根据交易单号或者支付单号进行判断时间减少对冷库的查询，因此支付选择方案一。
2.4、基本原则
为了充分的保证 0 事故，0 资损，方案设计时，提出了以下基本原则，在研发、测试、代码评审时均参考以下基本原则进行层层把控，可以有效的避免生产事故的发生。
2.4.1、数据插入唯一性：
⬤ 热库归档表的所有唯一键必须跟要归档的热库表保持一致。
⬤ 热库归档记录已存在的订单，冷库必须有相应数据，
冷库插入: 先
insert冷库成功后 再insert热库归档表冷库更新：更新冷库数据，使用同一个事务 先
delete再insert冷库数据（回）热库删除：删除热库数据时使用冷库数据当
where条件，所有热库字段（包含ID）条件都满足后才能删除成功。
2.4.2、数据更新一致性：
⬤ 冷库无
update操作，所有的更新操作必须在热库进行，如果数据需要更新并且仅在冷库存在，需同步到热库后，再在热库完成更新。⬤ 冷库热库数据同时存在时，以热库数据为准。冷库的数据来源只有热库数据同步到冷库。
⬤ 数据从冷库同步到热库时，操作归档表和交易表需保证在同一个是事务内完成，涉及到的查询必须使用写库。
2.4.3、数据查询准确性：
单笔查询：查询热库数据不存在时，不存在再次查询冷库（如果单号中可以判断订单日期，可再增加一层日期过滤，减少冷库查询）
批量查询：冷库热库数据都存在时优先返回热库数据。合并冷热库数据后，需看原先查询的接口顺序是否有要求，如果对顺序有要求合并后还需排序
减少冷库压力：冷库性能较低，线上实时交易尽可能减少对冷库的查询和依赖（可通过交易单号中的日期或者归档表进行过滤）。
限制天数控制：数据库交互 层天数控制 为
n，归档任务控制的天数为m，要求m>n。例如，mode层 有些判断订单超过n天的才会查询冷库，归档任务只归档m天前的历史数据，分开控制可以防止因调整归档天数导致数据查不到情况。
2.5、具体细节
2.5.1、归档表结构
2.5.2、归档表状态流转
2.5.3、一致性删除
使用冷库记录的所有字段当作删除热库的
where条件（包含自增 id）,删除热库和更新热库归档状态为冷库需在一个事物，任一失败则回滚。
2.6、交易及支付任务（数据归档、删除、兜底）
2.6.1、归档任务
查询热库订单表
X（时间可调）天前的订单，同步热库订单到冷库，插入热库归档表，归档状态为处理中，放入延迟删除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 结束事务）
一致性删除热库失败，同步热库数据到冷库，数据一致性删除
}
2.6.2、归档删除 TASK
常驻服务
TASK消费删除mq消息，rpc调用交易支付提供的删除接口，支持本地限流能力。
2.6.3、兜底任务：
主要功能：查询热库归档表中处理中修改时间超过规定时间的订单强制执行删除操作。主要用来防止
mq异常或者日常丢失消息时，使用兜底任务可以补偿消化处理中的归档记录。
兜底补偿任务（每30分钟启动一次）
{
查询归档记录表中状态为PROCESSING，修改时间为X +Y min前的记录 limit 1000
if 不存在 {
break
}
for 对于每条记录
查询冷库
数据一致性删除（开启事务 条件删除热库数据，更新归档记录表状态为COLD 结束事务）
一致性删除热库失败，同步热库数据到冷库，数据一致性删除
}
}
2.6.4、归档任务查询时间滚动机制：
时间范围第一次起始时间为固定日期（财经支付订单最早点日期），结束时间为指定日期，下次开始时间等于上次结束时间，结束时间为上次结束时间加上指定时间范围）。每次查询下一个时间窗口时
redis保存信息，指定日期，当天任务的时间范围，分页数。
2.6.5、归档任务并发处理：
需支持多任务分片并发处理
2.6.6、提升全天归档订单量
为了不影响在线交易，全天 24 小时 区分 交易高峰、低峰、日常 三个不同时间段，归档速度不同。
2.7、交易-有归档表（查询、新增、更新）
2.7.1、特点
特点: 唯一键有外部单号，订单规则随机无法根据单号判断时间，因此必须有归档表。
2.7.2、查询
存在以下部分情况可做特殊处理减少数据库冷库依赖。
单笔查询：
⬤ 根据外部单号查询，如果查询的
qps较高，可以查询冷库前使用归档表进行过滤判断。⬤ 根据交易单号查询，如果可以根据单号判断时间，查询冷库前使用单号进行时间范围过滤。
批量查询
批量查询：部分功能管理后台功能分页查询
1、数据查询范围要求较高的增加冷库查询逻辑时，可以增加传入的查询时间范围的开始时间过滤是否需要查询冷库
2、针对冷库热库都存在情况时优先保留热库数据（只过滤同一分页内的相同单号数据），如果对结果有异议可使用单号单独再次查询返回最新再次确认。
3、跟产品和运营确认能不支持的就仅查询热库。
2.7.3、更新
逻辑在数据库交互层统一实现处理
2.7.4、插入
2.8、支付-无归档表（查询、新增、更新）
2.8.1、特点
唯一键都为内部单号，现有主要查询可以根据单号判断时间，不需要归档表，可以彻底解决热库数据库存储问题。
2.8.2、查询
逻辑在数据库交互层统一实现处理
存在以下部分情况可做特殊处理减少数据库冷库依赖。
单笔查询：
⬤ 根据支付单号查询，如果可以根据单号判断时间，查询冷库前使用单号进行时间范围过滤。。
批量查询
批量查询：部分功能管理后台功能分页查询
1、数据查询范围要求较高的增加冷库查询逻辑时，可以增加传入的查询时间范围的开始时间过滤是否需要查询冷库
2、针对冷库热库都存在情况时优先保留热库数据（只过滤同一分页内的相同单号数据），如果对结果有异议可使用单号单独再次查询返回最新再次确认。
3、跟产品和运营确认能不支持的就仅查询热库。
2.8.3、更新
2.8.4、插入
3、总结
3.1、支付和交易
1、支付因没有归档表彻底解决了数据库存储压力问题，大大的节省了数据库存储资源。
2、交易因新增了归档表，大大延缓了热库数据库存储压力，为交易数据库又额外提供了缓冲扩容时间，为后续再次优化彻底交易解决数据库存储问题提供了充足的时间。
3.2、成果
1、彻底解决了支付数据库存储压力问题，有效的缓解了交易数据库热库的存储压力。
2、数据库热库保留天数可灵活调控，可以根据后续订单量进行合理调整存储可用天数
3.3、缺点
1、交易采用方案二新增了归档表，并且归档表里的存储的全量数据，仅能减缓交易和支付数据库的存储空间紧张情况，无法彻底解决数据库存储问题。
3、交易表释放的
datafree存储空间无法提供给归档表使用，仅能交易表使用，需要不定期释放交易表的datafree空间。
