喜歡我的文章，請點擊關注！
多年前，又是週六客服打電話過來，平臺官網不能訪問，app完全無法打開，客戶在QQ羣和微信羣中各種反饋，說平臺是不是跑路了？客服的多條400熱線完全被打爆，電話已經接不過來...
前言
一直以來總是想以什麼方式去記錄下自己在互金行業的這段經歷，趁着自己還記得清楚，還能找到一些資料原型，一方面可以分享出來供大家參考，但是更重要就是多年以後我可以根據這些文章回憶起來自己的那段激情歲月。
想了很久但一直沒有實施，後來覺得應該從架構的角度來梳理一篇文章，就寫了《從零到百億互聯網金融架構發展史》這篇文章；最後認爲只有實戰出來的東西以及解決問題的過程，纔是工作中最寶貴的經驗，應該把它分享出來，在梳理的過程中有三起事故和******事件比較有代表性，就整理出了下面這四篇文章，本篇文章從整體來回憶一下一路走過來所經歷過的救火故事。
作爲一個互聯網金融平臺，涉及到用戶資金，任何的服務（資金）差錯用戶都是不可容忍的，用戶不懂什麼是數據庫，不知道什麼網絡不通，就是一會看不到錢在app裏面展示都會覺得不安。在已經有很多P2P公司跑路的前提下，用戶個個已經被鍛鍊成爲福爾摩斯偵探，每天打開app查看收益，監控着平臺一切，甚至半夜升級斷網十分鐘，也會被用戶察覺，直接就發到羣裏面，更有甚者直接在QQ羣或者微信羣中說你們的技術行不行!
我們常說的互聯網工作經驗，一方面是開發經驗，但其實更重要的是處理問題的能力。那麼處理問題的能力怎麼來呢，就是不斷的去解決問題，不斷的去總結經驗，其中處理生產環境中問題的經驗更甚，因爲在處理生產環境中對個人的壓力和臨危應變的能力要求最高，你不但需要面臨千萬個用戶反饋，客服不時得催促而且旁邊可能就站了N個領導在看着你，一副你行不行的樣子要求立刻馬上解決問題！這個時候你的操作就非常重要，稍有不慎便會引發二次生產事故。
說了這麼多，只是想說明，生產事故對技術綜合能力要求頗高，更是鍛鍊處理問題能力最佳時機！下面給大家介紹我們從零開發到現在百億交易量所遇到的幾次關鍵事故，有大有小挑出一些比較有代表性的事件來分享。
併發滿標
公司系統剛上線的時候，其實沒有經歷過什麼大量用戶併發的考驗，結果公司做了一個大的推廣，涌入了一批用戶來搶標，共1000萬的標的幾乎都在10秒之內搞定，大概會有上萬左右的用戶會同時去搶標，平均每秒大概有千人左右的併發，滿標控制這塊沒有經過大的併發測試，上來之後就被打垮了，導致得結果是什麼呢，1000萬的標的，有可能到一千零幾萬滿標，也有可能會九百多萬就滿標，也就說要不就是多了一些，要不就是少了一些，就滿標了。
這就會很尷尬，因爲借款用戶就借款一千萬整，那麼多出來的錢不能給用戶回退，因爲用戶好不容易纔搶上了，無端退了用戶也鬧；少了也是問題，用戶借款一千萬，少了幾十萬也不行，如果缺的少了可以想辦法找一些有錢的客戶直接給買了，多了就必須重新放出來讓用戶投資，非常影響士氣，這個問題困擾了我們有一段時間。
購買標的流程圖，不知道大家是否能根據此圖發現問題呢？
超募
爲何會產生超募？在最早前的版本中沒有使用樂觀鎖來控制，如果在最後購買的用戶一單出現併發，就會出現超募，比如最後剩餘30000份的購買份額，因爲併發量特別大，可能同時會有十幾個用戶拿到了剩餘30000份餘額的可購買額度，有的買1000份、有的買上3000份、有的買上20000份都會驅動滿標，所以最後導致了超募。
針對這個問題，主要是引入了memcached樂觀鎖的概念（底層主要是cas、gets兩個命令），在發標的時候存入標的總份額，當用戶購買的時候首先去鎖定用戶購買的份額，因爲樂觀鎖的原因，如果同時有兩個用戶拿到份額的時候保證只有一個最後可以更新成功（鎖定份額），（鎖定份額）失敗直接返回，這樣就保證了在入口的時候就直接屏蔽了部分併發的請求。
少募
爲何產生少募？少募是可能1000萬的標的突然到980萬就給滿標了，這是因爲在超募情況下我們完善了代碼，用戶一進來首先就是鎖定購買份額，只有鎖定購買份額才能進行下面的流程，如果鎖定購買份額失敗直接返回，這樣雖然保證了在1000萬份額在購買初期必須每一個用戶只能鎖定一份，但是在高併發的情況下，因爲購買流程中有十幾個分支，每一個分支失敗就會退回鎖定的份額，這樣就會導致這樣的現象，就是可能是併發一上來，馬上就滿標了，過了一會進度又回退回來了。
少募主要是因爲分支失敗回退導致的，一方面我們分析了容易導致回退熱點，因爲在用戶搶標的時候會給用戶實時的展示標的進度，在很早的版本中直接就是存入到一個標的進度表裏面，並且採用了樂觀鎖，如果併發一高就頻繁的更新失敗導致回退，因此優化了標的進度這塊，直接去掉了標的進度表，實時根據查詢來展示標的進度（可以有延遲，有緩存）；另一方面在回退份額的時候在次判斷試下memcached的份額和標的的狀態，如果份額不爲零並且標的狀態是滿標，馬上自動更新狀態保證後續用戶可以立即購買再次驅動滿標。
做了以上的兩種優化後，我們還遇到了其它的一些小問題，在不斷的優化過程中，終於穩定下來；在後期版本中將考慮使用MQ隊列或者redis隊列來處理搶標更合理對用戶也更公平一些。
重複派息
15年的某一天看到一個新聞說是陸金所的一個用戶發現自己銀行裏面突然多了很多錢，沒過多久又被扣走了，然後收到陸金所那邊的解釋，說是給用戶還本派息的時候程序出現了問題導致還本派息兩次，當他們程序員發現了此問題後緊急進行了處理，用戶當然鬧了呀，就上了新聞，當然陸金所通道能力確實比較強可以直接從用戶卡里面扣，當大家都興致勃勃的談論這個話題的時候，我卻有一股淡淡的憂傷，爲什麼呢？因爲這個錯誤我們也犯過，具體說就是我搞的，大家可不知道當時的心裏壓力有多大！
事情是這樣子的，我們使用的第三方支付的扣款接口不是特別的穩定，於是我們前期就對接了兩種不通的扣款接口，平時前端投資的時候走一個接口，後端派息或者還本的時候走另外的一個接口，在初期的時候扣款接口不穩定，因此在給用戶跑批的時候經常會有個別用戶失敗，需要手動給失敗的用戶二次派息。做爲一個有志向的程序員當然覺得這種方式是低效的，於是將程序改造了一下，在後端派息的時候當第一種扣款失敗的時候，自動再次調用第二種扣款接口進行扣款，當時想着這種方式挺好的，各個環境測試也沒有問題，上線之後監控過一段時間也運行穩定。
當我感覺一切都很美妙的時候，事故就來了，突然有一天客服反饋說有的用戶說自己收到的利息感覺不對，好像是多了（真的是太感謝這個用戶了），我登錄後臺看了一下派息的流水複覈了一遍，果然利息被重複派了，一股冷水從頭而下，把當天所有的用戶派息記錄和到期記錄都進行了檢查，影響了70多個用戶，導致多派息了6萬多元，幸虧只是派息出了問題，如果是到期的話金額會翻N倍，其中70多個人裏面有幾個進行了體現、幾個進行了再次投資，絕大部分用戶在我們發現的時候還不知情，金額也沒有動。
怎麼處理呢，當然不能直接就動用戶的錢了，給每個重複派息的用戶打電話，說明原因贈送小禮物，請求諒解後我們把重複派過的利息再次調回來。大部分用戶進行了覈對之後都還是比較配合的，但是肯定有一些用戶不幹了，當然也不能怪客戶，都是我的原因，有的客戶需要上門賠禮道歉，有的客戶需要公司出具證明材料，我們的老闆親自給客戶打了N個電話被客戶罵了N遍，我心裏壓力可想而知，其中有一個客戶特別難纏，各種威脅說既然到了我的賬戶裏面肯定是我的，你們的失誤不應該讓他來承擔，折騰了很久，還是不能怪客戶。可能會說有的互聯網公司經常出現這種問題後就送給客戶了，哎，我們是小公司呀！這個噱頭玩不起。
到底是什麼原因呢，事後進行了覆盤也給領導做了彙報，平時都是首先進行派息的定時任務，過一個小時之後進行到期的定時任務，當天的派息標的比較多，跑了一個半小時，就導致了派息和到期的兩個定時任務同時進行，轉賬有了併發，第三方支付的接口不穩定給我們返回的失敗，其實有的是成功的，就導致了我們進行了二次的扣款嘗試引發了此問題。這個事情給我帶來了非常大的教訓，對於金融扣款的這種事情一定需要謹慎，那怕付款引發報警之後再人工處理，也不能盲目重試可能引發雪崩效應。
雜七雜八
還有就是其它一些零碎的問題了，記的有一次對用戶的登錄過程進行優化，導致有一塊判斷少了一個括號結果用戶在那兩個小時內，只要輸入賬戶，任意密碼就可以登錄了，幸好及時發現這個問題，正是這個問題才導致了我們正式確立了規範的上線流程，爲以後的上線制度建定了基礎。
還有一次我們在模擬用戶投資一種標的時候，留了一個入口通過http就可以調用，測試也沒有問題，有一天正好給領導演示呢，就在次用http請求的方式在瀏覽器執行了一下，前端就會看到自動投標的過程，因爲生產的數據有點多，投標的過程有點長，我們爲了加快進度，找了好幾個人同時來執行這http請求，導致最後出現了問題，最後發現寫測試腳本的這個同事根本就沒有考慮併發的情況，才導致出現了問題。
也做了很多的活動，記得做一個網貸之家的一個活動的時候，活動上線比較緊張，我們團隊曾經連續工作超過30個小時（一天一夜再一天），當天晚上我2點左右寫完程序，測試從2兩點測試到早上9點，最終確認沒有任何問題，才進行投產。半夜公司沒有暖氣，我們實在凍的不行了，就在辦公室跑步，從這頭跑到那頭，第二天上線之後，又害怕出現問題，監控了一天，確認沒有任何問題，纔到下午正常下班回家，那時候真是激情滿滿呀。
說到做活動肯定少不了羊毛黨，說哪一家互金公司沒有遇到過羊毛黨那很少見，而且現在的羊毛黨規模簡直逆天了，我們用戶裏面就有一個羊毛黨在兩三天之內邀請了六七千位用戶，如果說邀請一個用戶送1元，那這個用戶就可以搞幾千塊一次，而且有很多專業的網站、QQ羣、微信公共賬號都是他們的聚集地，哪天哪個平臺有活動門清，他們寫的淘羊毛操作手冊有時候比我們官網的幫助文檔還清晰，所以做活動的時候要考慮特別周全，各種限制，有封頂、有預案、講誠信，只要是符合我們活動規則的堅決按照流程走。
還有一個有趣的事情，app推送，一次我在公交車上就看到xx盒子app彈出hhhhh的推送，這個事情我們也搞過，因爲在調試的時候生產和測試就差了一個參數，有時候開發人員不注意就把生產參數部署到uat環境了，測試一發送就跑到生產了，這方面只能嚴格按照流程管理來防止。
其實還很多問題：mongodb集羣和mysql的同步出現的一些狀況、後臺大量數據查詢下的sql優化、golang使用mapreduce碰到的問題... 限於篇幅這裏就不一一清晰的描述了。
其實每次的出現問題都是對團隊一次非常好的鍛鍊機會，通過發現問題，定位問題，解決問題，再次回過頭來反思這些問題；重新梳理整個環節，
舉一反三避免下次再次出現類似的問題。正是因爲經歷這些種種的困難、考驗才讓團隊變的更強大更穩定，也更體現了流程的重要性，更是避免再次發生類似問題。
總結
古人有云，胸有驚雷而面如平湖者,可拜上將軍。在互聯網行業對大牛的要求也同如此，特別是技術的負責人，在面對生產事故的時候，一定首先是安撫同事，靜下心來找到問題本質再去解決，而不是不斷去施加壓力催促解決，重壓之下很多心裏承受能力稍弱的隊友，更加慌亂而不利於解決問題或者引發二次事故。
在看淘寶雙十一視頻中，有一段特別受到感觸，在雙十一初期，雖然技術團隊做了很多的準備，但是在零點過後流量瞬間涌入，服務被打垮，部分用戶投訴刷新不出網頁，緊接着隔壁同事也都反饋網站打不開，在大家都在慌亂中，xx一拍桌子大喊一聲，大家都別動，三分鐘之後再說，過了幾分鐘之後服務慢慢部分恢復了正常。後來回憶說，當時雖然服務癱瘓，但是監控還是有部分得業務成功，說明系統並沒有被壓垮，而此時的任何操作都有可能引發更大的問題，從此之後此人一戰成名，成爲阿里大將。
互聯網平臺發展大抵都會經歷三個階段：
-
1、上線初期，此階段問題最爲繁多，生產事故不斷，系統快速迭代優化。有人說爲什麼不測試到完全沒有問題再投產嗎？說實話在互聯網行業這個很難，小公司很難做到生產環境和測試環境一致，成本太高；時間緊迫，一般都是很短的時間內要求上線，上線之後在快速迭代。另外互聯網本就是一個快速試錯的行業，錯過半年時間可能風口早過；
-
2、發展期，此階段主要業務模式已經得到驗證，系統出現問題的頻繁度較少，低級錯誤減少，但此時是用戶量和交易量不斷爆發的時候，對系統性能、高併發的要求又上來了，所以此時出現的問題大多都是性能的問題；
- 3、成熟期，發展期過後系統相對比較平穩，用戶量和交易量都已經慢慢穩定下來，生產問題越來越少，出現問題幾乎都是細小的bug，這個階段也是公司最忽略技術的階段，恰好我們公司就處於這個階段，在這個階段就需要靜下心來，組織架構升級，補齊在初期和發展期所欠的技術債務，做好公司在升下一個量級的技術準備。
所有的這些問題幾乎都集中在14年底到15年初的這個階段，15年後半年開始到現在平臺慢慢穩定了下來，到現在幾乎沒有再出現過類似的問題，也因爲幾乎都是兩年前的事情，有很多記的不是特別清楚了，寫的比較粗糙望見諒。
作者：純潔的微笑
出處：http://www.ityouknow.com/
版權歸作者所有，轉載請註明出處