百亿互金平台救火故事.docxVIP

百亿互金平台救火故事 一直以来总是想以什么方式去记录下本人在互金行业的这段经受，趁着本人还记得清楚，还能找到一些材料原型，一方面可以共享出来供大家参考，但是更重要就是多年以后我可以依据这些文章回忆起来本人的那段激情岁月。 想了很久但一直没有实施，后来觉得应当从架构的角度来梳理一篇文章，就写了从零到百亿互联网金融架构进展史这篇文章；最终认为只要实战出来的东西以及处理问题的过程，才是工作中最贵重的阅历，应当把它共享出来，在梳理的过程中觉得有三起事故比较有代表性就整理出了下面这三篇文章，本篇文章从全体来回忆一下一路走过来所经受过的救火故事。? 一次生产事故的优化经受 一次dns缓存引发的惨案 一个脚本引发的血案 作为一个互联网金融平台，涉及到用户资金，任何的服务（资金）差错用户都是不行容忍的，用户不懂什么是数据库，不晓得什么网络不通，就是一会看不到钱在app里面呈现都会觉得担忧。在已经有很多P2P公司跑路的前提下，用户个个已经被熬炼成为福尔摩斯侦探，每天打开app查看收益，监控着平台一切，甚至半夜升级断网格外钟，也会被用户察觉，直接就发到群里面，更有甚者直接在QQ群或者微信群中你们的技术行不行! 我们常说的互联网工作阅历，一方面是开发阅历，但其实更重要的是处理问题的力量。那么处理问题的力量怎样来呢，就是不断的去处理问题，不断的去总结阅历，其中处理生产环境中问题的阅历更甚,由于在处理生产环境中对个人的压力和临危应变的力量要求最高，你不但需要面临千万个用户反馈，客服不时得督促而且旁边可能就站了N个领导在看着你，一副你行不行的样子要求马上马上处理问题！这个时候你的操作就格外重要，稍有不慎便会引发二次生产事故。 说了这么多，只是想说明，生产事故对技术综合力量要求颇高，更是熬炼处理问题力量最佳时机！下面给大家引见我们从零开发到现在百亿买卖量所遇到的几次关键事故，有大有小挑出一些比较有代表性的大事来共享。 并发满标 公司系统刚上线的时候，其实没有经受过什么大量用户并发的考验，结果公司做了一个大的推广，涌入了一批用户来抢标，共1000万的标的几乎都在10秒之内搞定，或许会有上万左右的用户会同时去抢标，平均每秒或许有千人左右的并发，满标把握这块没有经过大的并发测试，上来之后就被打垮了，导致得结果是什么呢，1000万的标的，有可能到一千零几万满标，也有可能会九百多万就满标，也就说要不就是多了一些，要不就是少了一些，就满标了。 这就会很尴尬，由于借款用户就借款一千万整，那么多出来的钱既不能给用户退回了，由于用户好不简约才抢上了，无故退了用户也闹；少了也是问题，用户借款一千万，少了几十万也不行，假如短得少了可以想方法找一些有钱的客户直接给买了，多了就必需重新放出来让用户投资，格外影响士气，这个问题困扰了我们有一段时间。 购买标的流程图，不晓得大家能否能依据此图发觉问题呢？ 超募 为何会产生超募？在最早前的版本中没有使用乐观锁来把握，假如在最终购买的用户一单消灭并发，就会消灭超募，比如最终剩余30000份的购买份额，由于并发量特殊大，可能同时会有十几个用户拿到了剩余30000份余额的可购买额度，有的买1000份、有的买上3000份、有的买上20000份都会驱动满标，所以最终导致了超募。 针对这个问题，次要是引入了memcached乐观锁的概念（底层次要是cas、gets两个命令），在发标的时候存入标的总份额，当用户购买的时候首先去锁定用户购买的份额，由于乐观锁的缘由，假犹如时有两个用户拿到份额的时候保证只要一个最终可以更新成功（锁定份额），（锁定份额）失败直接前往，这样就保证了在入口的时候就直接屏蔽了部分并发的恳求。 少募?为何产生少募？少募是可能1000万的标的突然到980万就给满标了，这是由于在超募情况下我们完善了代码，用户一进来首先就是锁定购买份额，只要锁定购买份额才能进行下面的流程，假如锁定购买份额失败直接前往，这样虽然保证了在1000万份额在购买初期必需每一个用户只能锁定一份，但是在高并发的情况下，由于购买流程中有十几个分支，每一个分支失败就会退回锁定的份额，这样就会导致这样的现象，就是可能是并发一上来，马上就满标了，过了一会进度就回退回来了。 少募次要是由于分支失败回退导致的，一方面我们分析了简约导致回退热点，由于在用户抢标的时候会给用户实时的呈现标的进度，在很早的版本中直接就是存入到一个标的进度表里面，并且接受了乐观锁，假如并发一高就频繁的更新失败导致回退，因而优化了标的进度这块，直接去掉了标的进度表，实时依据查询来呈现标的进度（可以有延迟，有缓存）；另一方面在回退份额的时候在次推断试下memcached的份额和标的的形态，假如份额不为零并且标的形态是满标，马上自动更新形态保证后续用户可以马上购买再次驱动满标。 做了以上的两种优化后，我们还