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

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

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

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

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

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

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

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

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

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

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

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

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

如果你對(duì)這篇回答有任何問題，歡迎在下方點(diǎn)贊，留言。

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