预下单机制带来的弊端
当初刚工作受到显示订单模块影响, 那时候默认流程是这样的:
- 客户端发起支付请求, 推送支付道具信息
- 服务端接受支付请求, 数据库创建状态 ‘已下单’ 的订单, 构建SDK支付请求链接返回客户端
- 客户端收到支付链接, 直接响应唤起支付端等待玩家支付
- 支付完成回调服务端, 调取订单记录将预下单记录修改完成并通知到账
包括现在关于支付的相关流程都是按照这样处理, 但是这样处理并非完全没错.
这要设计的系统确实能够很好保证整个支付的链路流程分析( 预下单机制代表用户有付费的想法, 在后续分析需求可以查看用户对其有想法道具但没有付款的 ).
这样看起来虽好, 但是在运转几年之后问题也就慢慢浮现, 那就是单表容量容易爆炸!
三年运行的订单表当时切换到其他云平台数据库, 导出导入都要花费将近一天时间才完成.
支付成功订单还好, 毕竟付费成功代表有收益; 但是 ‘已下单’ 状态的订单是 ‘支付完成’的十几倍, 这里面都是毫无收益的订单记录.
这里面有个收益比, 如果单条订单如果能够带来哪怕是 6 块钱的收入, 那么就允许数据库多他 6000 条无效记录, 毕竟在现在硬盘空间越来越不值钱了.
有必要预下单吗?
这也是我后来开始考虑的, 有必要请求的时候直接生产预下单的记录吗? 将写入数据库的步骤移到回调过程的时候, 客户端发起支付的时候只做本地日志记录而不做数据库记录.
这也是后续处理的方案, 把客户端请求做日志, 而第三方 SDK 都带有扩展字段, 这扩展字段当作唯一标识做记录验证然后回调验证完成写入数据库再推送.
在游戏SDK当中这种方式代表了能够进库的就是成功回调的订单,
压缩大量无效订单让后台运营做功能的时候也相对方便点( 单表10多G的对查询也是挺可怕的 ).
后续项目当中都采用请求支付做日志记录, 回调记录入库的请求确实能够缓解这问题.