五个9的可用度、秒级故障解决，探寻互联网金融应用之道

A5：做支付最重要的就是安全,所以针对订单状态我们都是保守处理策略,因此对于网络异常的订单我们都是设置处理中状态,然后最终通过主动查询或者被动接受通知来完成和银行或者三方的最终一致性.支付系统中,除了订单状态还有响应码问题,大家都知道银行或者三方都是通过响应码来响应的,响应码和订单状态的翻译也是一定要保守策略,确保不会出现资金多付少付等问题.总之这个点的总体思路是,资金安全第一,所有的策略都是白名单原则.

Q6: 刚才提到过,若某支付通道超时,路由策略会分发至另一通道,根据那个通道图可看出,都是不同的支付方式,比如支付宝或微信支付,那如果我只想通过微信支付,为啥不是重试,而要换到另一通道呢?还是通道本身意思是请求节点?

A6：首先针对超时不可以做重路由,因为socket? timeout是不能确定这笔交易是否发送到了三方,是否已经成功或者失败,如果是成功了,再重试一遍如果成功,针对付款就是多付,这种情况的资金损失对公司来说不可以的； 其次,针对路由功能,需要分业务类型,如果是单笔代收付交易,用户是不关心钱是哪个通道出去的,是可以路由的,如果是扫码通道,用户如果用微信扫码,肯定最终是走微信,但是我们有好多中间渠道,微信是通过中间渠道出去的,这里我们可以路由不同的中间渠道,这样最终对于用户来说还是微信支付.

Q7: 能否举例说下自动修复的过程?如何发现不稳定到重路由的细节?

A7: 自动修复也就是通过重路由做容错处理,这个问题非常好,如果发现不稳定然后去决策重路由.重路由一定是明确当前被重路由的交易没有成功才可以路由,否则就会造成多付多收的资金问题.我们系统目前重路由主要是通过事后和事中两种方式来决策的,针对事后比如5分钟之内通过实时预警系统发现某个通道不稳定,那么就会把当期之后的交易路由到别的通道；针对事中的,主要是通过分析每笔订单返回的失败响应码,响应码做状态梳理,明确可以重发的才做重路由.这里我指列举这两点,其他的业务点还非常多,鉴于篇幅原因,不做详述,但是总体思路是必须有一个内存实时分析系统,秒级决策,这个系统必须快,然后结合实时分析和离线分析做决策支撑,我们的实时秒级预警系统就做这个事情.

Q8: 商户促销有规律吗?促销时峰值与平时相比会有多少差别?有技术演练么?降级的优先级是怎样的?

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!