看运维如何拯救一个百亿互金平台

《看运维如何拯救一个百亿互金平台》要点：
本文介绍了看运维如何拯救一个百亿互金平台，希望对您有用。如果有疑问，可以联系我们。

多年前,又是周六客服打电话过来,平台官网不能访问,app完全无法打开,客户在QQ群和微信群中各种反馈,说平台是不是跑路了?客服的多条400热线完全被打爆,电话已经接不过来…

前言

一直以来总是想以什么方式去记录下自己在互联网金融行业的这段经历,趁着自己还记得清楚,还能找到一些资料原型,一方面可以分享出来供大家参考,但是更重要就是多年以后可以根据这些文章回忆起自己的那段激情岁月.

想了很久但一直没有实施,后来觉得应该从架构的角度来梳理一篇文章,就写了《从零到百亿互联网金融架构发展史》(http://t.cn/RMSnjub)这篇文章；

最后认为只有实战出来的东西和解决问题的过程,才是工作中最宝贵的经验,应该把它分享出来,在梳理的过程中觉得有三起事故比较有代表性就整理出了下面这三篇文章,本篇文章从整体来回忆一下一路走过来所经历过的救火故事.

• 一次生产事故的优化经历(http://t.cn/RJAsCIN)
• 一次DNS缓存引发的惨案(http://t.cn/RJ5xodh)
• 一个脚本引发的血案(http://t.cn/RJYcSpG)

作为一个互联网金融平台,涉及到用户资金,任何的服务(资金)差错用户都是不可容忍的,用户不懂什么是数据库,不管你什么网络不通,哪怕只是一小会儿,看不到钱在 App 里面展示都会觉得不安.

在已经有很多 P2P 公司跑路的前提下,用户个个都被锻炼成了福尔摩斯侦探,每天打开 App 查看收益,监控着平台的一切,甚至半夜升级断网十分钟,都会被用户察觉,直接就发到群里面,更有甚者直接在 QQ 群或者微信群中开骂：你们的技术行不行?

我们常说的互联网工作经验,一方面是开发经验,但其实更重要的是处理问题的能力.那么处理问题的能力怎么来呢?就是不断的去解决问题,不断的去总结经验,这其中处理生产环境中的问题获得的经验最多.

因为在处理生产环境的问题时,对个人的压力和临危应变的能力要求最高,你不但需要面临千万个用户的反馈,还要面对客服不时的催促,甚至旁边可能就站了 N 个领导在看着你,一副你不行就给我滚蛋的样子,要求立马解决问题!这个时候你的操作就要非常谨慎,稍有不慎便会引发二次生产事故.

说了这么多,只是想说明,生产事故对技术综合能力要求颇高,更是锻炼处理问题能力的最佳时机!

下面给大家介绍我们从零开始大家,到现在可以支持百亿交易量的平台所遇到的几次关键事故,有大也有小,挑出一些比较有代表性的事件跟大家分享.

1、并发满标

公司系统刚上线的时候,没有经历过大量用户并发的考验,结果公司做了一个大型推广,涌入一批用户来抢标,共1000万的标的,几乎在10秒之内就没了.

有上万用户同时去抢标,平均每秒就有几千的并发,满标控制这块因为没有经过大的并发测试,上来之后就被打垮了,导致得结果就是：1000万的标的,有可能到一千零几万满标,也有可能九百多万就满标了,也就是说要么多一些,要么少一些.

这就很尴尬,因为用户借款一千万整.如果多出来,就得给他退了,但是用户好不容易才抢上了,无端退了用户会投诉；如果少了,比如用户借款一千万,少了几十万那也不行.少了的还好说,可以想办法找一些有钱的客户直接给买了,但如果多了,就必须重新放出来让用户投资,非常影响士气,这个问题困扰了我们有一段时间.

下图是购买标的流程图,不知道大家是否能根据此图发现问题呢?

• 超募

为何会产生超募?在最早前的版本中没有使用乐观锁来控制,如果在最后购买的用户一单出现并发,就会出现超募,比如最后剩余30000份的购买份额.

因为并发量特别大,可能同时会有十几个用户拿到了剩余30000份余额的可购买额度,有的买1000份、有的买上3000份、有的买上20000份都会驱动满标,所以最后导致了超募.

针对这个问题,引入了?memcached 乐观锁的概念(底层主要是cas、gets两个命令),在发标的时候存入标的总份额,当用户购买的时候首先去锁定用户购买的份额.

因为乐观锁的原因,如果同时有两个用户拿到份额的时候保证只有一个最后可以更新成功(锁定份额),(锁定份额)失败直接返回,这样就保证了在入口的时候就直接屏蔽了部分并发的请求.

• 少募

为何产生少募?少募是可能1000万的标的突然到980万就给满标了,这是因为在超募情况下我们完善了代码,用户一进来首先就是锁定购买份额,只有锁定购买份额才能进行下面的流程.

如果锁定购买份额失败直接返回,这样虽然保证了在1000万份额在购买初期必须每一个用户只能锁定一份,但是在高并发的情况下,因为购买流程中有十几个分支,每一个分支失败就会退回锁定的份额,就会导致这样的现象,可能并发一上来,马上就满标了,过了一会进度又回退回来了.

少募主要是因为分支失败回退导致的,一方面我们分析了容易导致回退的热点,因为在用户抢标的时候会给用户实时的展示标的进度,在很早的版本中直接就是存入到一个标的进度表里面,并且采用了乐观锁.

如果并发一高就频繁的更新失败导致回退,因此优化了标的进度这块,直接去掉了标的进度表,实时根据查询来展示标的进度(可以有延迟,有缓存)；

另一方面在回退份额的时候再次判断试下 memcached 的份额和标的的状态,如果份额不为零并且标的状态是满标,马上自动更新状态保证后续用户可以立即购买再次驱动满标.

做了以上的两种优化后,我们还遇到了很多的小问题,但是在不断的优化过程中,终于稳定下来；在后期版本中将考虑使用 MQ 队列或者 Redis 队列来处理抢标,这样更合理,对用户也更公平一些.

2、黑客攻击

2015年应该是互联网金融行业受黑客攻击最多的一年吧,各互金公司都深受其害,当时我记得*贷之家有一段时间被黑客攻击的太厉害,连续几天网站都无法打开.

当然我们也未能幸免,DDoS 攻击、SQL 注入、漏洞渗透等等,几乎都经历过,有的黑客比较仁慈,应该是出于善意或者展示自己,将漏洞放到乌云上面或者漏洞盒子里面让厂商来修复.但更多的是一些黑产,完全就是威胁、敲诈、想捞一笔钱,先看看下面这位吧：

（编辑：核心网）

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