高並發下MySQL架構性能升級

業務發展的初期，資料庫採用單點或者簡單的讀寫分離的方式進行部署維護，業務的快速發展，流量的增長，複雜的業務場景可能導致整個資料庫的性能逐漸下降，這樣的情況之下，資料庫系統架構如何升級、擴展滿足現有以及未來一段時間的的業務需要，以下內容為工作中遇到的問題和總結。

資料庫上面臨的問題

業務問題

1、報表類業務，業務上快速發展離不開業務指標的各種數據維度的分析，定期的分析過去一段時間內的業務數據情況，轉化為報表輸出。這些指標數據是對某些業務上的聚合、歸併、統計等分析。

2、客戶查詢歷史訂單信息，資料庫數據已經被物理刪除，沒有辦法查詢。

技術問題

1、大批量的寫入或者讀取資料庫，影響到整體拖垮資料庫。

2、資料庫查詢性能越來越慢。

3、定時任務實時處理數據。

4、技術維度設計的表按照業務維度分析數據。

分析和解決思路

以上問題簡單舉例，還有可能很多業務場景出現，主要從兩個方面的問題，數據量的快速增長帶來的各種性能問題，這樣的情況下如何在MySQL中存儲業務的全部數據，並滿足業務上的各種查詢需要，主要從以下幾個方面考慮。

操作特性上可以分為讀、寫操作，也就是將資料庫進行讀寫分離，這樣的操作一般用於讀流量較高，寫操作較少的場景，同時也可以做多個從庫用於承接讀的流量。這種情況下同時也會帶來一定的業務問題，比如經常倒大批量的數據等，性能上也會存在一定的問題，如何解決呢？

操作特性上分析，抽象歸為兩類操作，對應的特點：

針對高頻操作的服務，在周期內提高單次處理的響應時間，對應的資源要求相對苛刻，低頻操作的服務，對延遲性要求沒有那麼嚴格，資源上可以相對少分配一些，為了滿足兩組場景的需要，需要將資源上分別部署，可以將資料庫拆分為以下幾個應用場景：

• 主庫：可以支持快速的插入數據操作，庫結構上可以不支持查詢類操作，不建立索引等，這樣寫入的性能很高。

* 從庫：可以建立供業務上的查詢操作，為了提高查詢性能，可以建立索引，提高查詢效率，聚合類的操作類型儘可能少，如果有，可以做多從業務上拆分開.

* 離線庫：主要應用於大批量實時倒數據的應用場景，離線分線數據使用，性能相對一般。

* 備份庫：用於冗災恢復的情況，不承接流量使用，業務上不對外開放使用。

* Hive：用戶搭建數據倉庫，大量分析數據指標的業務處理，同時也可以作為數據歸檔處理。

通過將資料庫的職責進行劃分，將不同的業務場景調用不同的資料庫，從而性能滿足各種業務上需要。

數據特性上分析，可以將數據分為業務數據和基礎屬性數據，某些基礎屬性為另外一部分業務數據服務，相對於整體上而言，兩部分的數據操作特性相差還是比較大，可以將業務相關和不相關的業務進行垂直和水平拆分。

垂直拆分就是要把表按模塊劃分到不同資料庫表中，說得簡單就是要把原來強耦合的系統拆分成多個弱耦合的服務，這樣既可以保證業務上的數據快速增長，又可以保障基礎核心服務數據的穩定性。

水平切分就是要把一個表按照某種規則把數據劃分到不同表或資料庫里，簡單理解就是水平拆分行，將不同的數據按照某種規則拆分到不同表中。

垂直與水平結合使用，橫向和縱向分析業務數據。垂直拆分主要解決數據表讀取的資源競爭關係，水平拆分主要解決單個數據表的讀寫的壓力。

從查詢場景上分析，可以將業務上分為複雜查詢和簡單查詢。

複雜查詢場景，常用的方式我們可以添加索引方式，再就是搭建搜索系統解決，也是目前常用的方式解決問題，類似常用的搜索系統的數據量級別，查詢場景相當的複雜，就是基於搜索系統維護（開源的框架有Elasticsearch、Lucene，感興趣的可以了解一下）。

簡單查詢場景，為了降低磁碟IO的性能問題，可以將數據內存化管理，也就是我們常說的NoSQL，將數據K-V化存儲到內存中，這樣的性能會質的變化。

總結

經過以上幾部分的優化，資料庫上已經有質的飛躍的改進和優化。針對性能上優化的思路，單個資源的處理能力是有限的，可以將數據橫向、縱向分布到多資源處理，也就是分散式系統。同時也會帶來CAP的問題，可以從業務上分析一下，優先解決的問題是哪個。

資料庫技術上的優化可以很大程度上解決性能上的問題，提升業務上用戶體驗，但有時候靜下心來想一想是不是業務上或者架構設計上的不合理導致的，可以從架構、業務的角度多方位思考一下問題，多方向攻擊性能，效果又有可能是另外一種質的飛躍。