【开发笔记241025】她趣介意时效超5分钟的付款交易。简单一招，应对！

她趣介意时效超5分钟的付款交易。简单一招，应对！

我们平台近期入网一个新客户是她趣。她趣这个企业比较关注下发时效，他们那边系统做了告警，当存在超5分钟时效的交易，就会发告警。然后，那边的人就来质问。并声称，现在只是放了3%的量，就总出现下发慢的交易，如果10月份剩下的这5天里依然存在，就不打算用我们这个通道了。

销售经理询问有什么办法，连销售老大老董都亲自来找我们技术老大了。近期系统交易量大，而且有客户走批量付款，动辄上万笔，导致系统处理能力下降，签约、付款的消息队列出现积压排队。但，我们跟她趣那边这样解释的话，显然苍白无力。那该怎么满足她趣的时效要求呢？这事比燃眉急。

下午2点，我提了一个简单而且相当奏效的主意（午休时想到的）。 签约、下发这2个链路所需要编写的代码量又少，相当可控。几个同学认同后，三下五除二，当晚发版。搞定。————这个优化，不光对她趣，对其他着急的客户同样适用。

 

福无双至祸不单行，当天发生了一件几年来没有发生的事情。系统出现状态不一致的付款交易，

而且，状态不一致的情况，竟然是 bosskg/trans是付款失败，而channel/服务商是付款成功。这是相当可怕的，因为这可能发生重复出款（商户那边发现付款失败，就可能会重发）。客服到技术，都紧绷脑袋仁。

紧急修复系统。万幸的是，最终客户侧没有重复调我们出款。

毋庸置疑，这已经触碰红线了。

 

遥想上一次，还是22年3月初，我们那位曾多年做支付系统的老tian， 同步请求通过异常时，他将单子置为了FAIL。碰巧，那天，平安银行接口慢。结果，上千单被置为了FAIL态。那天上午，一向嘻嘻哈哈活泼洒脱的他，眼里闪出了泪花~~吓坏了，要知道，请求银行的付款交易，通常都不是几十到几百的小钱，可不像请求微信/支付宝。（同月底，老tian离职了）

所以，做什么不是看年份，而是看沉淀、看真本事。就像JD简历上的”5年经验“、”10年经验“，未必行。

---

the end.