# 故事

这是一个真实事件，三年前老猫负责公司的支付资产业务。为了响应上级号召，加强国央企之间的合作，公司新谈了一个支付对接的渠道（当然这个支付渠道其实很冷门的，也是为了对接而对接，具体哪个渠道也不方便透露），由于原始支付系统的第三方支付可拓展性设计得还不错的，所以老猫对接的也是比较快的，熟悉对方的对接文档之后对着编码就好了，差不多花了三天的时间就完成联调了。一切看似很顺利地上线了。

时隔几天，收到了一个快递包裹，是一袋价值53块钱的“原皮腰果”，当时诧异，翻看了各大消费平台，都没有之前的下单记录，后来和媳妇确认了一下，她也没有下单。“难道是某个崇拜哥的小姑娘送的？不能吧”当时心里美滋滋地yy着。

不过之后的一个客诉问题，引起了老猫的重视，老猫排查下来发现一个很重大的问题，钱款的扣除和实际的订单状态对不上。说白了就是订单完结了，但是账户资产并没有完成扣除。我瞬间明白了之前那个“原皮腰果”是怎么回事儿了，当时在生产测试渠道的时候，在公司内部商城提交了订单，但是并没有付款，然而订单却成功了。

再三确认之后，确实存在这一问题。一瞬间整个人心态崩了，头皮发麻，口干舌燥，心脏“突突突”。怎么办？怎么办？生产还不知道涉及多少单子，没办法，兜不住了，先把这件事情往上抛吧（向上级领导汇报）。

具体原因是什么呢？我们来看一下对接第三方支付的大概时序流程。

# 背景

小猫维护现有的系统也有一段时间了，踩坑也不少，事故不少。感兴趣的小伙伴可以了解一下，往期的小猫踩坑记合集。

这天，小猫找到了商城系统的第一任开发老A开始聊天。

“你们这系统是真坑，我都吃过好多次亏了，太烂了...”小猫开玩笑地吐槽道。

“我们当时其实还是花了很长的一段时间去做设计以及评审的，每一步都是有严格把控的，当时系统总体骨架还是相当清晰的，也没有那么多新的概念，你说现在系统不行了，可不能怪我们啊。一会我给你原始设计文档看看。后面经过了很多研发的手了，甚至运营和产品都换了好几拨了，每任运营可能对当前系统的要求都不一样吧,大家理解可能都不同......”老A侃侃而言着。

小猫抿了口刚倒的茶，意味深长地看着老A...

# 故事

春天，办公室外的世界总是让人神往的，小猫带着耳机，托着腮帮，望着外面美好的春光神游着...

一声不和谐的座机电话声打破这份本该属于小猫的宁静，“hi，小猫，线上有个客户想购买A产品规格的商品，投诉说下单总是失败，帮忙看一下啥原因。”客服部小姐姐甜美的声音从电话那头传来。“哦哦，好，我看一下，把商品编号发一下吧......”

由于前一段时间的系统熟悉，小猫对现在的数据表模型已经了然于胸，当下就直接定位到了商品规格信息表，发现数据库中客户想购买的规格已经被下架了，但是前端的缓存好像并没有被刷新。

小猫在系统中找到了之前开发人员留的后门接口，直接curl语句重新刷新了一下接口，缓存问题搞定了。

关于商品缓存和数据库不一致的情况，其实小猫一周会遇到好几个这样的客诉，他深受DB以及缓存不一致的苦，于是他下定决心想要从根本上解决问题，而不是curl调用后门接口......

# 背景

当前形势不佳，在这种情况下。小猫更是雪上加霜，他被裁了。投了个把月简历，终于约到一个面试。 面试官翻了一下简历：“看你简历上写了支付和账户相关项目，那能否聊一下热点账户问题你们是咋处理的吧”。

小猫懵逼了一会，“额？什么是热点账户？我们好像模型里面就一个资产账户，然后充值的时候和消费的时候更新一下该账户，并且记录一下操作明细，然后结束了。”

面试官：“哦。回去等通知吧。”

出来之后，小猫整个人都还是懵逼的。

# 前言

相信很多在中小型企业或者TO B企业的小伙伴们都未曾接触过限流。举个例子，小伙伴们就会发现，原来软件限流就在身边。相信很多小伙伴们都有12306买票回家的体验吧。如下图大家应该非常熟悉。