支付功能设计及实现思路
支付功能设计
主要包括：订单表，订单日志表，订单队列，定时任务。
主要考虑：事务性、幂等性、安全性。
表结构设计
- 订单表：
订单表，最主要的就是订单号、支付状态。
CREATE TABLE `t_order` (
`fid` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键,自增id',
`forder_id` varchar(35) NOT NULL COMMENT '订单号,唯一',
`fpay_status` varchar(15) DEFAULT '00' COMMENT '00：未支付,01：支付成功,10：订单关闭,02：支付失败,03：已下单,04：申请退款,05：退款成功,06：退款失败 ',
`fuser_id` int(11) DEFAULT NULL COMMENT '用户id',
`ftotal_price` decimal(25,2) NOT NULL COMMENT '总价',
`fcreate_time` datetime DEFAULT NULL COMMENT '购买时间',
PRIMARY KEY (`fid`),
UNIQUE KEY `idx_order` (`forder_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='订单表';
- 订单日志表：
订单日志表，最主要的就是订单号，支付状态，操作记录，支付渠道。
CREATE TABLE `t_order_log` (
`fid` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键,自增id',
`forder_id` varchar(35) NOT NULL COMMENT '订单号',
`fuser_id` int(11) DEFAULT NULL COMMENT '用户id',
`fcreate_time` datetime DEFAULT NULL COMMENT '操作时间',
`fpay_status` varchar(15) DEFAULT '00' COMMENT '00：未支付,01：支付成功,10：订单关闭,02：支付失败,03：已下单,04：申请退款,05：退款成功,06：退款失败 ',
`faction` tinyint(2) unsigned DEFAULT NULL COMMENT '操作记录：1,提交;2,关闭;3,第三方回调;4.前端轮询;5.后台查询第三方;6.定时任务查询',
`fresult` text COMMENT '订单的回调结果',
`ftotal_price` decimal(25,2) NOT NULL COMMENT '总价',
`fpay_channel` varchar(25) DEFAULT NULL COMMENT '支付渠道。1,微信支付;2,支付宝;3,银联支付;',
PRIMARY KEY (`fid`),
UNIQUE KEY `idx_order` (`forder_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='订单日志表';
此文主要涉及到订单表，以及订单日志表。
略去用户表，商品表，商品详情表，商品订单关系表。
支付流程及时序图
商品系统：指的是购物网站等系统。
如果要进行"去库存"的处理，可以在第10步中进行。
支付系统：指的是提供聚合支付服务的系统，同时提供微信支付，支付宝，银联等多种支付方式。
如果项目不需要这种聚合支付系统，也可以直接对接微信支付等。
第1步，用户点击"购买";
第2步，"商品系统"展示商品信息，生成订单id;
第3步，用户选择商品信息，提交订单。
订单入Redis队列，方便定时任务主动去取订单进行支付结果查询;
第4步，访问"支付系统"，并提供appId,订单id，支付回调url等;
第5步，"支付系统"返回支付的url;
第6步，"商品系统"展示支付页面，提供多种支付方式;
第7步，用户选择支付方式，进行支付;
第8步，"支付系统"通知支付结果;
第9步，"支付系统"调用支付回调url，告知支付结果详情。
支付回调，每隔一段时间就会不断地回调，比如 1/1/4/8/16/32/.... 直到接收到回复为止。
这个其实就是一种重试机制。通过延时队列实现，一次回调不成功，就再次回调，直到成功为止。
第10步，根据支付状态，决定是否执行商品业务逻辑。
第11步，通知支付结果。
支付回调
第9步和第10步是整个支付模块中最重要的部分。
支付回调的接口，需要保证幂等性、事务性、安全性。
幂等性
- Q:怎么保证订单接口的幂等性？
使用UUID生成32位数字字母组成的唯一订单号，放入缓存中。
Redis实现的方式就是将订单id作为Key，支付状态作为value，并设置一个 key 的过期时间。
如果发现缓存中已经有了同样的订单id，就视为重复，不会进行支付请求，就直接返回。
如果支付成功，则删除缓存中对应的订单id。
并发插入
- Q:假设Redis挂掉了，怎么避免并发插入导致订单id重复？
由于订单表中的订单id加了唯一索引，所以即使并发查询后并发插入，也不会出现订单id重复的情况。
并发更新
- Q: 支付回调并发更新怎么处理？
- Q: 怎么保证支付回调接口的幂等性？
- Q: 支付系统会对发票系统进行回调，当没有支付成功时， 就会每隔一段时间进行继续回调，如何保证多次回调，只成功一次？
数据库排它锁。Select for update。性能太差，应付不了并发。
乐观锁的版本机制。添加version字段。在这种场景下太过冗余。
对于乐观锁和悲观锁的理解，详情见：https://blog.csdn.net/puhaiyang/article/details/72284702
支付场景下，更好的做法是：使用状态机制，直接利用订单表已有的支付状态。
当回调结果为支付成功，而且数据库的支付状态不是支付成功时，才将支付状态改为支付成功，并执行业务功能。
UPDATE的时候，会有行锁。
通过状态机制和唯一id去更新，UPDATE SET status='A' WHERE status='B'，是一种乐观锁。并发更新时，能保证线程安全。
如下：
UPDATE t_order SET fpay_status='01' WHERE forder_id='xxxxx' AND fpay_status!='01'
事务性
- Q: 怎么保证用户付款后（支付状态改变），相应的业务逻辑会执行，并且只执行一次？不多执行，也不少执行？
执行业务功能和修改支付状态，要做事务处理，保证事务性。
如果支付成功，但是后续的业务功能执行失败，就会回滚。
安全性
- Q：如何保证支付的安全性？
数据要加密，包括商户号等信息。
支付回调接口，一定要校验商品信息/商品价格是否正确，防止薅羊毛。
订单日志表，记录下所有的操作，包括生成订单，提交订单，支付回调，支付状态，操作记录(是第三方回调，还是前端轮询，还是定时任务)等。
订单日志表，还能分析订单的整个流程，从订单的开始到结束。
万一出现订单丢失，可以通过订单日志表的记录恢复订单。
定时任务
- Q:为什么要引入定时任务？
定时任务：为了避免支付回调不成功，出现用户付款成功，却没有执行功能服务的情况。
可以使用定时任务，主动去"支付系统"中查询订单的支付状态，这是一种补偿机制。
引入定时任务后，会有很多值得思考又有趣的问题。
- Q: 支付失败怎么办？
支付失败，订单会重新入Redis队列，进行重试。
当重试次数达到限度，给用户支付失败的提醒，并将订单出列。
当订单过期时，给用户提示订单已经过期，并将订单出列。
- Q: 怎么保证定时任务和第三方回调接口，同时发生时，用户付一次钱，只执行一次业务功能？
同上"怎么保证支付回调接口的幂等性"
多个事务，同时执行更新，具体的分析见：
https://www.cnblogs.com/expiator/p/12084882.html
- Q：大量的订单未支付怎么办？
假如有很多笔订单，进入Redis队列后，又一直都没有支付，那就可能会变成脏数据。
可以用另一个新的Redis队列，当失败达到一次的次数后，就用新队列来存放这些未支付或者支付失败的订单。
- Q：如果Redis队列中，存在100万条订单，怎么处理？
开多线程往Redis队列里面取数据。
