7 回答

TA贡献1831条经验 获得超9个赞
这个问题你换种角度考虑其实无非就是个负载均衡
的问题,不同的是,这里的因素比较随机,并不能直观的去获得负载情况,这种情况下只能自己去设置rank机制了。
机制如下,假设保存最近100次的下单成功队列
其中A的可用性为53%,B的可用性为30%,C的可用性为17%。那么就以A>B>C的优先级来依次轮询。假如此次A失败了,而B成功了。则可用性变为52%,31%,17%。
直至B的可用性超越A,则优先B,此方法可实现自动rank机制,自动平衡使用情况来调整最优策略。

TA贡献1840条经验 获得超5个赞
题主也知道不管用什么方法都没法避免调用失败的问题,从大部分的回答里面也能看到,如果要在最少的调用次数下调用成功的话,就需要根据以往的调用结果对A B C分配优先级,在调用时采用策略。上面回答的也挺多的,我再提点思路,题主可以人为的分析一下接口调用失败是呈什么分布,比如对于某个接口而言是不是失败一次之后会连续失败,还是只是偶尔呈点状失败,又比如是不是你对某个调用太频繁的时候才容易出现失败。根据这些再做出来合理的策略估计效果会更接近你所希望的。

TA贡献1951条经验 获得超3个赞
如果客户对下单的响应有非常高的要求的话,你就按照第一种方法,但是可以三个同时下单,只要有一个成功了,另外两个就相应取消,不过这种方法对第三方接口有要求,而且第三方接口的各种问题可能影响你也业务服务,比如接口没响应的话会导致你的业务服务处理能力指数级下降。
如果客户对下单响应的时间不是非常敏感的话,可以用MQ来做,把下单任务丢给MQ,MQ的消费者可以去下单,成功后将结果回调业务服务。

TA贡献1789条经验 获得超8个赞
楼主你除了第二种那个方案,其他的方案做要出问题啊,用户绝对要被重复扣款,比如说你调用A渠道,这个时候A渠道如果出现超时等错误,但是这个情况有可能用户已经被扣款了,俗称掉单,(有时你冲正都退不了款,只能发起退货请求),你只能通过补单查询看看用户是否付款成功,有一定的延迟,你这个时候再把用户分发到B渠道,用户又被扣款一次了,这在三方支付中经常出现的问题,我们的做法是对下游的渠道做个统计,优先选择渠道质量好的进行分发,想楼主这样设计很容易出问题
ps:楼上的回答大部分都没做过三方支付,不可能像楼主这样设计,三方支付不可能像分布式服务那样调用接口做的,涉及到钱的问题很敏感,一不小心公司账户上面就会出现短款,白白损失钱
添加回答
举报