降低資料壓力的幾種解決方案
在現代的軟體系統中，幾乎所有的系統都使用到了資料庫，不論是關係型資料，例如MySql、SQLite、Oracle、SQLServer等，還是非關係性資料，例如mongoDB、redis等。本文已web系統為例來闡述為什麼要降低資料庫的壓力，在提出具體方案之前先大致講解一下現在web系統的架構，要了解web系統的架構和演變過程具體可以參考大型網站架構演變和知識體系這片文章。
現代web系統的架構
現在的大型web系統多采用分散式的架構，分散式系統面臨的最大挑戰就是如何在複雜的、併發的情況下保證資料的一致性問題。通常為了避免由於保證資料一致性問題而帶來的困難，通常情況下都是採用多個例項，單個數據源的架構模式，簡化模式如圖。
在這個架構中，通過不斷的增加例項（webserver）可以降低應用伺服器的壓力，所以只要保證應用程式碼的質量、應用之間的低耦合性、可擴充套件性和可維護性等，應用伺服器的壓力就不再會成為整體架構中效能瓶頸，但是隨著業務量的不斷增加增長，或者時間的積累，沉澱下來的資料變得越來越來多，隨著而來的資料庫的壓力變得越來越大，慢慢的效能的瓶頸主要集中在資料庫上。
降低資料庫壓力的方法
1.合理增加索引
表索引可以加快對錶中資料的檢索速度，但是會降低表中資料的更新速度，所以增加表的索引一定控制在合理範圍內，過多的索引不但不會降低資料庫的壓力，反而可能增大資料庫的壓力，表索引的建立一般要從具體業務場景出發，對於讀多寫少的場景，可以通過適當的增加索引來提高效率，對錶的那些列建立索引？建立單獨索引還是建立複合索引？要根據具體的業務場景來決定，建立索引之後可以針對索引對業務邏輯中使用的SQL進行優化，建立索引是最基礎的手段，這裡不錯過多的介紹。
2.資料截轉
一般情況下，業務中所處理的資料的都具有一定的時間間隔，所以可以通過對業務進行梳理，將當前時間間隔之外的資料進行截轉，截轉到歷史資料庫中，通過對業務進行拆分，當需要歷史資料時，可以轉到歷史資料庫中進行查詢，或者修改，通過減少當前資料庫的資料量，來減輕當前業務資料的壓力。資料截轉一般情況下是按照時間來進行，所以在業務員資料庫設計的時候就要考慮到時間這個因素。
資料截轉可以進行間隔一段時間做一次手工的資料截轉，也可以啟動一個定時器，每個一段時間進行一次資料截轉，推薦的方式是準實時截轉，及每天在業務量較小的時間，啟動任務實時截轉。
資料截轉需要注意的幾個問題：（1）外來鍵關聯關係（特別是有主鍵ID的關聯的）注意在截轉的歷史資料庫中的關聯關係是否正確。(2)保證生產庫和歷史庫的業務關聯關係，從而避免歷史庫的資料需要關聯生產庫中的資料。
3.增加快取
快取是降低資料壓力一個強有力的手段，基本是所有系統大型web系統中都會使用到，所以現代的大型web系統的架構一般如圖。
請求1到達webserver之後，首先執行2訪問快取，如果hit則返回，miss則執行3訪問資料庫，在執行4同步到快取中，再返回。但是不是快取並不是萬能的，快取也有其使用的業務場景，一般在讀多寫少，資料重複查詢比較集中的場景下，快取可以大大提高效能，快取操作順序非常重要，不合理的操作順序，在併發場景下常常會導致資料的不一致，快取的具體操作可以參考快取架構設計細節二三事這邊文章。
4.生成寬表，冗餘資料
有些業務例如報表、資料彙總等需要資料量較多，此時可能需要進行多表聯合查詢，聯合查詢操作非常消耗資料庫的效能，所以在這種業務場景下為了避免過大的效能消耗，往往需要將查詢時的多個表按照關聯條件進行關聯，生成一張含有冗餘資訊的包含所有表的多個欄位的大寬表，這樣在進行查詢時，只在一張表中進行查詢，效能明顯得到提升。大寬表的生成是在業務流程中生成還是通過非同步化任務來生成，根據具體的業務邏輯來定。
5.修改關係型資料庫為非關係性資料庫
非關係型資料庫，也就是我們通常說的NoSQL資料，最常見就是key/value型別的資料庫，這類資料庫不強調錶的關係，但是查詢速度非常快，所在某些具體場景下，我們應該優先選擇NoSQL資料庫，例如字典資訊表的查詢。
6.讀寫分離
如果採用單點資料資料庫，就算對資料進行上述的相關優化，但是由於其本身的單點性，所以隨著流量的激增，資料庫仍然會成為系統的瓶頸，如何對資料進行拆分來解決這個問題了，讀寫分離就是最常用的方法，讀寫分離的原理如下圖。
讀寫分離技術現在已經應用的很成熟，通過將資料拆分為兩個例項，讀寫分離操作改善了資料單點的瓶頸，分攤了資料庫壓力，而且當主資料庫宕機之後可以迅速的切換到從庫，而不會導致業務不可用，同時也起到資料備份的作用，由於存在兩個資料例項，所以資料怎麼由主庫同步到從庫、主從之間延遲引發的資料不一致問題，以及怎麼來分離業務中讀和寫操作成為要解決的問題成為要解決的問題。主從同步可以參考Mysql主從架構的複製原理及配置這篇文章，從主資料一致可以參考DB主從一致性的幾種解決方法這篇文章。
7.資料庫拆分
採用讀寫分離之後，資料庫已經變為兩份例項，資料庫的壓力已經得到分攤，如果資料庫的壓力還是過大時，這是就要從業務方面著手，將具體業務細分，將業務對應的表分拆到不同的資料庫當中，如下圖。
業務變動較大，同時要對系統內部之間的相互呼叫提供介面，呼叫方式可以選用RPC、Restful、JMQ訊息等方式。一般情況下，資料庫垂直拆分做的足夠細分的話，加上讀寫分離技術，加上適當的資料截轉就可以滿足一般的大型業務系統對效能的需求。
8.表的垂直拆分
資料庫可以進行垂直拆分，當然也可以對資料庫中的表進行垂直拆分，對錶進行拆分就是對資料拆分的再拆分，如圖。種解決方法只適用於一些特定的場景，例如對錶進行垂直拆分，通過非同步化呼叫將所有任務非同步化，前提是總的任務可以進行分佈的非同步化操作，在實際應用比較少，因為設計的表只要複合三正規化的要求，一般是很難在進行拆分的，應用較多是對錶進行水平拆分。
9.表的水平拆分
如果已經做了資料庫拆分，並且進行了讀寫分離，資料壓力還是過大，主要原因就是資料庫表中的記錄太多，或者對資料進行了截轉，但是對歷史資料的操作還是比較頻繁的，且隨著截轉的歷史資料越來越多，歷史資料庫的壓力也邊的也變的越來越大，這時有兩種解決方案：第一種方案就是對資料庫中的表進行垂直拆分，從而不用在截轉資料，通過不斷對錶進行水平拆分，保證資料資料庫中單表的記錄數保持在一個高效能合理的範圍之類，通過擴容將不同分配到不同的資料中（分庫分表）來保證資料庫的壓力，應用在訪問時，通過分庫分表的條件進行路由，就可以取到資料。第二種就是仍舊對資料進行截轉，當歷史資料資訊過多從而導致資料庫壓力過大時，採用搜尋引擎的方式來解決。相比於第一種操作第二種方案適用於讀操作上，對與寫操作，具有一定的侷限性，第一種方案具有一定的通用性。對錶進行水平拆分的過程如圖所示。
在進行進行具體水平拆分之前，我們需要考慮這樣幾個問題
- 制定什麼樣的路由規則
- 如何儘量避免跨庫或者跨表操作
- 如何儘可能的避免全庫全表掃描
- 如何保證每個庫的負載處於基本儘可能均衡的狀態
- 如何實時跨庫訪問事物
- 如何實時聚合操作
- 如何保證擴容的方便性