系統上線那點事續

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

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

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

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

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

看了沒幾分鐘，運維同窗打電話來，說「上次你說想要的現場來了。鏈接數又上來了」，當即登上數據庫機器查看。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」。

轉載請註明。