海量数据冷热分离方案与实践
发布时间：2022-08-02 14:51:35 所属栏目：云计算 来源：互联网
导读：背景 随着财经支付业务的快速发展，考虑到未来订单量持续增长，在线存储遇到更大的挑战，需提前做好规划。目前财经支付主要业务都是使用 mysql（InnoDB）作为数据存储，因历史订单信息访问频率低并占用了大量数据库存储空间，期望将历史数据跟生产最新交易数
|
背景 随着财经支付业务的快速发展，考虑到未来订单量持续增长，在线存储遇到更大的挑战，需提前做好规划。目前财经支付主要业务都是使用 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 异常或者日常丢失消息时，使用兜底任务可以补偿消化处理中的归档记录。 （编辑：柳州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
