系統上線那點事續

話說距離週五上線後第一天的數據庫故障已經好幾天了，上次的緊急恢復過程當中也沒來得及復現現場問題，用戶微信入口的代碼邏輯並不複雜，也沒有什麼明顯漏洞。

海創園的辦公場地已經跟夏日的游泳池同樣了，全部的邊邊角角都放滿了桌子和人。各個部門負責安排新人座位的人確定已經頭很大了，要在如此緊張的空間中再挖掘出來能坐人的地方簡直就是門藝術~ 不堪重負下終於開始啓用新辦公地點，週一部門從「鄉下」搬到西溪路的「城裏」，轉身作了城裏人。

週一開了第二個屏幕專門盯了一天系統監控，流量和負載都較平穩，到下班也沒發現什麼異常，能夠愉快的回家了。

週二也盯了半天，一切正常，活動將在週四晚間結束。看看沒什麼大問題，因爲以前太累，週三開始調休。但，墨菲定律又生效了，這東西是看星際穿越從諾蘭那學的，用在這裏正合適。

週三4點多合做方又通知5點鐘計劃另外一個公衆號要推圖文引入用戶進入遊戲，雖然在家休着但閒着無事打開監控系統看着有啥問題沒。到了時間，應用服務器cpu和數據庫負載確實有所上升，但看起來問題不大，因而打開愛奇藝準備欣賞道士出山，後面證實這是個悲劇，跟林志玲的道士下山沒半點關係。

看了沒幾分鐘，運維同窗打電話來，說「上次你說想要的現場來了，鏈接數又上來了」，立刻登上數據庫機器查看，cpu usage, load average值跟上次故障一模一樣；但此次有所不一樣，一是已經有了上次的經驗，二是運維同窗此次沒在高速的半路上，能夠一塊兒及時處理。

數據庫的配置是8核虛機，上次已經知道負載大是tomcat應用嘗試創建更多的jdbc鏈接，而數據庫的最大鏈接已經配成了3000，但操做系統文件句柄沒放開，因此仍只能開到1024個鏈接。

階段一：降級應用

既然是14個tomcat應用嘗試開更多鏈接，那首先要下降數據庫壓力就從關tomcat開始，關了一半tomcat機器，觀察數據庫鏈接仍然是1024，考慮到TCP的close wait可能須要部分時間，因此又等了一會，確認沒有下降後決定繼續關tomcat。作這個動做時有個疑問，上次單個tomcat鏈接數據庫的參數應該已經調成了60，數據庫端的鏈接數最大應該只有840，爲什麼此次又到了1000多？

tomcat關到只剩兩個時，數據庫鏈接數開始降下來了，到了300，此時系統負載雖然CPU仍然是99%，但load average已經從500降到了基本安全的1點幾。這個機的生產庫雖然有些配置問題致使數據庫的sql query log沒有輸出，但根據上次另外一臺機的經驗，慢查詢都在查單條用戶表數據上，這個操做是在每一個用戶進入頁面時，若是session中不存在此用戶信息時作的操做。

階段二：加數據庫

此時的現象彷佛單個數據庫不能承受這個業務邏輯上進行的查詢，因此此時作的第二個動做就是開始準備用多個數據庫給前端業務分流。在運維同窗給我準備數據庫的時候，抽空查了一下鏈接池配置，發現設置的最大鏈接數量不是以前設想的60，而是150，多是因爲上次問題時臨時改的，因此以前應用鏈接到1000+到正常的。

此時兩個數據庫已經準備好，將以前備份的主庫dump到新數據庫，從新修改war包的數據庫ip地址，啓動3個tomcat對應一個數據庫並從新發布；後又啓動3個tomcat對應另外一個數據庫。再看監控，分流數據庫訪問彷佛並不能緩解問題，起的數據庫都立刻CPU 99%，想讓用戶正常訪問頁面仍然困難。

階段三：遷移緩存

既然數據庫hold不住，只能臨時改程序將全部用戶數據放在redis緩存裏，因爲是集羣部署因此將原jedis鏈接池配置從1000改成100。改好上傳正要發佈時，電話那邊幾個哥們竟然喊着火了，剛搬去的新辦公室就着火了？我不在現場只能聽到電話免提裏的背景音，背景人聲裏彷佛有物業要讓他們斷電撤退，但聽到運維的哥們鎮定的說等等先別斷，讓我把這個程序先布上去。。。

這個着火算是個小插曲，過了一會這幾個哥們彷佛沒動地方，繼續在處理問題，估計不是要緊的大火，生命沒啥危險。此項更改先在一個單實例tomcat上測試，前端nginx已改成指向此單個tomcat。緩存上來須要預熱，用戶第一次進來仍是須要找下數據庫，後面就不須要了。確認功能沒問題後，開始將新的war包部署到全部tomcat並所有啓動。10幾分鐘過去後，緩存鏈接在最開始時有個峯值到了1000，以後穩定在了600，查看應用服務log開始正常了。

8點多應用基本正常後，電話那邊幾個哥們開始叫全家桶外賣了，咱也終於能把吃了一半的飯吃完。

遇到線上故障，首要的是開發本身要冷靜，頂住各方面的壓力。如你這裏正忙着嘗試恢復，那邊上級領導一個個的打電話來詢問狀況，這還不算完，還有合做方的人看到服務不可用了也來打電話找你，這時開發哪有精力理會這些，本身要知道輕重緩急，不能lost focus，集中精力作本身該作的事情。

上次參加杭州Oracle用戶組時一個DBA說過，作這行，要能承受很大壓力，由於天天接觸的都是業務方最核心的數據庫，一旦遇到數據庫崩潰，你在恢復的時候本身決不能慌，這時可能有不少人（領導，同事，焦急的客戶）圍在你身後看着你，這時你要打鍵盤手都要抖那可不行。這句話對處理線上故障的開發人員也是同樣，想必攜程的事故處理的當事人也會有同感。

最後送上百度百科裏墨菲定律的解釋，祝各位週末愉快。

---

「墨菲定律」（英文：Murphy's theorem）主要內容有四個方面：1、任何事都沒有表面看起來那麼簡單；2、全部的事都會比你預計的時間長；3、會出錯的事總會出錯；4、若是你擔憂某種狀況發生，那麼它就更有可能發生。

「墨菲定律」的根本內容是「凡是可能出錯的事有很大概率會出錯」，指的是任何一個事件，只要具備大於零的機率，就不可以假設它不會發生。

在科學和算法方面，它與英文所謂的「worst-case scenario（最劣情形）」同義，數學上用大O符號來表示。例如，對插入排序來講，最劣情形便是要排序的陣列徹底倒置，必須進行 n*(n-1) 次的置換才能完成排序。在實驗上，證實了最劣情形不會發生，並不表明比它輕微的情形就不可能，除非可以頗有信心的推論事件的機率分佈是線型的。

---

文章來自微信平臺「麥芽麪包」,微信號「darkjune_think」。轉載請註明。