作者：13
GitHub：https://github.com/ZHENFENG13
版權聲明：本文為原創文章，未經允許不得轉載。
文章簡介
工作這幾年，技術棧在不斷更新，項目管理心得也增加了不少，寫代碼的速度也在提升，感覺很欣慰，畢竟是在一直進步，但是過程中也有許許多多的曲折，也踩過了數不盡的坑坑窪窪，從一個連百度都不知道用的萌新到一個悠哉悠哉的老油子也不容易，很多人應該都有類似的經歷和感受，因此博客中也會整理一些曾經碰到過的事故和問題給自己提個醒。
由於接下來要在perfect-ssm項目中引入緩存模塊，恰好在翻看日記時看到了這次事故的記錄，因此整理了這篇文章，根據事件發生時的日記來回顧一下這次事件，通過這次數據庫事故的真實案例及后續的事故處理作為引子來講講緩存，為什么要這么做呢，因為我覺得網上關於緩存使用的重要性和必要性的文章已經很多了，一個又一個的原因及使用緩存的益處都寫的很清晰，我再去寫一遍有些多余，不如通過這種親身經歷的案例來得好。
雖然當時也知道緩存的重要性，也想去在項目中使用，但是由於當時太菜了也不知道怎么去在項目中整合緩存，所以使用緩存的事情就一拖再拖，而這次事件及后續的處理也是我第一次在項目開發中使用緩存，這也是為什么我選擇使用這篇日記來寫這篇文章並作為緩存接入的引子，其實還有很多日記，不過這篇就顯得比較特殊了，剛好要在perfect-ssm里用到，因此結合這篇日記整理了一篇文章。
項目介紹
前面寫了三個段落，不能再繼續寫了，主角該出場了，先來簡單的介紹一下發生這次事故的項目，當時所在的公司是一家小型的電商公司，公司主要的線上產品也就是一個商城項目，上線運行了一段時間，還處於繼續開發和優化的階段，用戶界面就是很雷同的一些電商屬性：商品、購物車、訂單、支付，后台則是一些運營數據，倉庫系統(商品的入庫和出庫)，訂單管理等，用戶量和訂單量還算不錯吧，比上不足比下有余，馬馬虎虎可以讓公司正常運轉，OK，基礎信息介紹完畢。
第一次崩潰
這次事故發生的時間點是在某天的上午(額...又是發生在上午)，事發比較突然，客服陸陸續續接到幾個用戶的反饋電話，起初並沒有在意，以為只是某些用戶的誤操或者某些商品在倉庫里沒貨了，這些都經常遇到也就沒放在心上(處於萌新階段的自己最大的優點應該就是心比較大，什么事情都覺得無所謂，哈哈哈哈)，但是接下來的投訴越來越多，老大就讓我趕緊去看看是怎么回事，我這時候才打開網站開始查問題(心大不大?或者說楞不楞?)。
詭異的事情也發生了，網站打開一切正常，網站首頁好好的，搜索功能也正常，商品詳情頁也可以用，當時心里一緊，這是發生了什么事情啊？服務器卡了？tomcat集群掛了其中的一台？趕緊去看服務器，結果所有實例的運行一切正常，看到這個結果心里的緊張又多了幾分，和平時的劇情不太一樣，這個時候不應該是服務器掛掉然后重啟的橋段嗎？答案是no...
又去找客服，到底是什么事情，客服說基本上都是說無法下單，我又趕緊去下單，走一下訂單流程，果然，卡在頁面上一動也不動了
無法生成訂單，陸陸續續點了其他頁面，發現都是正常的，訂單列表和訂單刪除都能用，只有訂單生成不行，趕緊去查日志，也沒有報錯(這個我有點記不清了，到底報沒報錯以及報了什么錯，只是記得查了日志也沒查出什么問題)，我趕緊去找老大，報！服務器沒問題！日志也沒問題！數據庫也可以正常的查詢！訂單表也正常！就是無法生成訂單，可能是訂單接口有問題！（可以腦補一下當時的愣頭青場景），這個時候我也懵了，到底是什么情況呢？什么都正常怎么會出現這種情況，以我當時的水平只能在旁邊喊666，然后就把事情推到了老大身上(美滋滋...)，沒辦法，我真的不會，也想不明白是什么問題。
老大當時也按照我的思路去查了(可能覺得我中間有偷懶以致於沒查出來)，當然他也什么都沒查出來，然后就開始去看數據庫，查了也挺久的，我記得這個過程中我是很煎熬的，也幫不上什么忙，還要聽客服那邊催，中間也僥幸的覺得是不是哪里抽風了過會兒就好了，就去下了幾次單，結果都不行，最后只能坐在老大旁邊看他敲代碼，最氣的是，很多sql命令和linux腳本也看不懂...
代碼沒問題，日志沒問題，集群也好好的，基本也就可以猜到問題應該在數據庫了，不過我沒有查看和操作的權限，所以具體是不是，當時我也不知道。
老大一直在查，我就只能呆呆的等着，過了一會兒老大說是有兩張表鎖住了(我的內心OS:表鎖住了？什么意思？怎么會鎖住？等等...數據庫鎖是什么東西)，試着去解決但是沒有成功，一時也想不出好的辦法，客服那邊同事催的也緊，氣氛有點僵，然后我就說出了我的"高見"，老大，要不咱們重啟數據庫吧，話一說完，老大看了我一眼，我猜眼神里應該滿是贊善，然后對着我笑了笑，他可能覺得這是個很好的方案吧，他怎么就沒想到呢？(ps：也可能是在心里罵我，這個愣頭青，一出問題就知道重啟，tomcat重啟，nginx重啟，服務器重啟....現在又要mysql重啟)當然，由於比較混亂，我說了這個方案后，他也就有些妥協了，然后就去殺了一些進程，並重啟了mysql服務，大概也就花了兩三分鍾左右的時間，雖然是線上環境，影響肯定是有一些的，但是也絕對不會太大，畢竟業務剛起步，系統也是在開發和完善中。重啟后，果然就有了效果，可以正常下單了，我們也松了一口氣。又觀察了一段時間，發現系統一切正常，剛好也到了中午，也就去外面吃飯了，回來之后，繼續檢查並觀察了數據庫的情況，發現一切正常，於是就將這件事當做是一個偶然事件，沒有特別注意了，由於公司人員緊張(初創公司的技術部，算是什么部門......)，每個人的事情都很多，老大也就去忙其他事情去了，給的建議是讓我去查一下sql，是不是用了太多的聯查，或者創建的索引不合適之類的問題導致了死鎖，由於沒有帶來特別大的影響，也就當成一個普通的偶然事件了，老大也說了，下個版本要加上緩存功能，不然隨着業務的增長數據庫可能會有些撐不住。
又崩潰了
可能有些朋友心里會有一些疑惑，事情就這么結束了？怎么這么快？
肯定沒有！事情肯定不會就這么完了的，不然我也不會單獨整理這么一篇文章了，在下午的四點鍾之后，又出現了同樣的問題，不過這次就嚴重的多了。
依然跟上午的情況類似，在工位上開發的時候陸陸續續又收到了客服的信息，與上午同樣的用戶反饋，這下就不像上午似的手忙腳亂了，驗證了網站應用后發現問題和上午一樣，於是老大直接去查了數據庫，再接着就是重啟了數據庫，網站又可以正常運行了，但是這個時候，傻子都能意識到網站出問題了，絕對不是偶然事件，雖然選擇了無奈的重啟數據庫服務，但也不能每次都這么做，必須把問題找到並解決，但是我了解到的信息就是數據庫幾張表被鎖住了，關鍵是我也不知道怎么做，去百度也百度不出個鳥兒來，當然，問題肯定是出在數據庫這里，老大給我的建議也是去找下單邏輯的問題以及相關聯的sql是不是有問題......(肯定沒有找到問題啊，因為這次的事件根源並不在此)
在大家檢查代碼檢查sql和在網上找解決方案的期間，同樣的問題又再次發生了，不過這次比前兩次更嚴重，不僅僅是下單流程，其他的功能也不能用了，接口大部分也掛掉了，數據庫的問題更嚴重了，下午這兩次事件發生的時間基本沒有隔太久，就是說剛重啟沒多久，數據庫又崩了(這感覺像不像是被攻擊了？嘿嘿嘿)，真的是爆炸，問題也沒定位到，當所有人都覺得我們是被人攻擊了甚至感到了絕望氣息的時候，巧了巧了，倉管那邊也過來反饋，說無法錄入商品進行上架操作，還說上午也碰到了類似的情況，這個時候我們幾個開發才反應過來，倉庫后台是最近更新的，可能問題和這個有關，於是趕緊詳細地問了一下倉管，上架了多少商品，有幾個人在上架，得到的答案也很滿意，上午也入庫了，不過打電話之前入庫的比較多，是叫了幾個兼職一起做的，這個時候好像有點兒眉目了，想了一下更新的功能以及新的入庫代碼我們才恍然大悟，也漸漸地清楚了問題的根由！有問題的sql語句在這里！於是我們與倉庫主管溝通，由於倉管系統剛更新，有些不穩定導致了一些問題，先暫停一下入庫，我們趕緊把問題修復掉。
原來攻擊我們網站的是自己人!
乖乖隆叮咚，原來"攻擊"我們網站的是自己人！
具體的經過忘記了，總之是記得當天網站出現過三次事情，現在總結起來也就清晰了很多，基本上每次事情發生的時候，倉管都在做入庫操作，最后入庫的量比較大，根據倉管負責人的描述也就大致能夠對應起來了。第一次第二次還好，只是表鎖住了，但是第三次就比較嚴重了，數據庫服務資源耗盡了，根本連不上，只有部分請求是正常的。當然根據倉管的說法再聯想一下大致也就清楚了，由於前兩次入庫的商品並不多也不密集，因此雖然存在鎖表的情況以及下單失靈的問題，但是依然有部分下單請求是可以正常執行的，大部分接口也是可以正常運行的，但是第三次由於入庫的商品數量較大以及速度較頻繁，不僅僅導致了鎖表，也導致了數據庫連接被耗盡，進而導致大部分接口也掛掉了。
看到這里肯定有很多朋友會問，你們網站是怎么做的，一入庫就會崩潰，那還玩什么啊？先別激動，我們當時也是被搞得措手不及，以前也做過很多次的入庫操作，一切都是正常的，根本沒有過這種把數據庫拖垮的情況，所以發生這件事的時候，作為當事人的我們也都挺驚訝的，由於以前根本沒有過類似這種事件的發生，我們也想當然的忽略了，沒往倉管方面去考慮，而且下午兩次事件的發生時間又特別近，根本來不及排查問題。而這次事故的發生就是這么巧合，因為倉管后台剛做了改版不久，加了一些功能，原來比較穩定的功能被要求修改，主要原因在於這次更新后的頁面設計以及對應的sql語句問題，與數據庫的配置沒有特別大的聯系，當然，數據庫配置高的話可能這個事故的發生會晚一些，但遲早還是會發生。
崩潰的部分結束了
不知不覺已經碼了這么多的文字，粗略的估算了一下，大概有六千多字了，看來對那時候的自己以及當時經歷的事情還是有很多的感慨和想法的，有些場景依然歷歷在目，而當時自己的一些想法和反應現在還是有一些印象的，真的覺得當時的自己好傻好呆。
本來想將后續的原因分析和事件處理過程也一起寫進來的，但是如果加進來的話文章的篇幅確實有些太長了，這篇文章就已經回憶了這么多事情，所以具體原因和后續的解決過程還是再整理整理放在后面一篇文章里講吧，如果寫在一起真的就太長了，估計很多人要一拉到底了，哈哈哈哈。
結語
關於本次崩潰事故的記錄到這里就告一段落了，糟糕的系統設計和拖垮系統的sql語句會在下一篇文章中再詳細介紹。
首發於我的個人博客，新的項目演示地址：perfect-ssm,登錄賬號：admin,密碼：123456
如果有問題或者有一些好的創意，歡迎給我留言，也感謝向我指出項目中存在問題的朋友，本篇主要講述一次Mysql崩潰的事件。
如果你想繼續了解該項目可以查看整個系列文章Spring+SpringMVC+MyBatis+easyUI整合系列文章,也可以到我的GitHub倉庫或者開源中國代碼倉庫中查看源碼及項目文檔。