之前在BAT里參與過一個公司級應(yīng)用（非市場級，投入的人力也不會那么大），上線2年后，總是被用戶投訴，原因是這個應(yīng)用使用MySql數(shù)據(jù)庫來做持久層，但是2年了，有一張非常重要的存儲歷史任務(wù)的表實在是太大了，導(dǎo)致通過頁面想要查詢歷史數(shù)據(jù)的速度變得非常非常慢，所以用戶很是不滿意。

分析下來，這不是用Redis能解決的緩存問題，而是歷史數(shù)據(jù)的查詢響應(yīng)速度問題。

我們最開始是希望能夠通過增加索引的方式解決，但是面對千萬級別的數(shù)據(jù)量，我們也不敢貿(mào)然加索引，因為一旦數(shù)據(jù)庫hang住，期間的所有數(shù)據(jù)庫寫入請求都會被放到等待隊列中，如果請求是通過http請求發(fā)過來的，很有可能導(dǎo)致服務(wù)發(fā)生分鐘級別的超時不響應(yīng)。

雖然經(jīng)常被用戶投訴反應(yīng)慢，也不能破罐破摔，直接超時不響應(yīng)了吧。

于是我們陷入了兩難的境地。

后來我們分了兩個部分來優(yōu)化持久層。

第一步就是配置MySQL的主從庫，通過將讀寫請求分離，來提高數(shù)據(jù)庫的響應(yīng)速度。

從上圖可知，來自同一臺服務(wù)器的請求，經(jīng)過MySQL-proxy被分流給了不同的MySQL節(jié)點，其中寫請求給了主節(jié)點，讀請求給了從節(jié)點。因此，我們首先通過分流的方式，減輕了單節(jié)點MySQL的響應(yīng)壓力，實現(xiàn)了優(yōu)化的第一步。

但是，只配置MySQL的主從是遠(yuǎn)遠(yuǎn)不夠的。

通過查閱論壇，相關(guān)資料，我們最終敲定在持久層引入ElasticSearch。

Elastic Search是一個輕量級的持久層工具，它支持動態(tài)多節(jié)點部署，自動備份，節(jié)點掉線后能夠自動切換主從，動態(tài)廣播發(fā)現(xiàn)新上線的節(jié)點，而這些優(yōu)點的應(yīng)用，無須修改任何server端配置。可以這樣理解，如果你部署了4個elastic search節(jié)點，其中2個掉了，服務(wù)器還是可以很好的繼續(xù)運行。

此外，它還有一個最重要的優(yōu)勢，那就是支持大數(shù)據(jù)快速查詢。一張幾千萬的表，如果用MySQL查詢，可能需要幾秒到幾十秒不等，但是如果用elastic search，只需要毫秒級別就能查詢到結(jié)果。完美的解決了我們當(dāng)前的問題，還順帶幫我們鞏固了持久層的穩(wěn)定性問題。

綜上，優(yōu)化Mysql的目的是為持久層服務(wù)，除了引入主從配置，當(dāng)MySQL自身局限性導(dǎo)致無法繼續(xù)優(yōu)化后，引入其他技術(shù)也是十分必要的。

如果你對這篇回答有任何問題，歡迎在下方點贊，留言。

我是蘇蘇思量，來自BAT的java開發(fā)工程師，頭像是本人，每天都會分享科技類見聞，歡迎關(guān)注我，與我共同進(jìn)步。