解決數據庫高併發訪問瓶頸問題

1、緩存式的Web應用程序架構：

　　在Web層和db層之間加一層cache層，主要目的：減小數據庫讀取負擔，提升數據讀取速度。cache存取的媒介是內存，能夠考慮採用分佈式的cache層，這樣更容易破除內存容量的限制，同時增長了靈活性。

 

2、業務拆分：

　　電商平臺，包含了用戶、商品、評價、訂單等幾大模塊，最簡單的作法就是在一個數據庫中分別建立users、shops、comment、order四張表。

　　可是，隨着業務規模的增大，訪問量的增大，咱們不得不對業務進行拆分。每個模塊都使用單獨的數據庫來進行存儲，不一樣的業務訪問不一樣的數據庫，將本來對一個數據庫的依賴拆分爲對4個數據庫的依賴，這樣的話就變成了4個數據庫同時承擔壓力，系統的吞吐量天然就提升了。

　　

 

3、MySQL主從複製，讀寫分離：

　　當數據庫的寫壓力增長，cache層（如Memcached）只能緩解數據庫的讀取壓力。讀寫集中在一個數據庫上讓數據庫不堪重負。使用主從複製技術（master-slave模式）來達到讀寫分離，以提升讀寫性能和讀庫的可擴展性。讀寫分離就是隻在主服務器上寫，只在從服務器上讀，基本原理是讓主數據庫處理事務性查詢，而從數據庫處理select查詢，數據庫複製被用於把事務性查詢（增刪改）致使的改變動新同步到集羣中的從數據庫。

MySQL讀寫分離提高系統性能：

　　一、主從只負責各自的讀和寫，極大程度緩解X鎖和S鎖爭用。

　　二、slave能夠配置MyISAM引擎，提高查詢性能以及節約系統開銷。

　　三、master直接寫是併發的，slave經過主庫發送來的binlog恢復數據是異步的。

　　四、slave能夠單獨設置一些參數來提高其讀的性能。

　　五、增長冗餘，提升可用性。

實現主從分離可使用MySQL中間件如：Atlas

 

　　MySQL主從複製的原理：數據複製的實際就是Slave從Master獲取Binary log文件，而後再本地鏡像的執行日誌中記錄的操做。因爲主從複製的過程是異步的，所以Slave和Master之間的數據有可能存在延遲的現象，此時只能保證數據最終的一致性。

 

4、分表分庫：

　　在cache層的高速緩存，MySQL的主從複製，讀寫分離的基礎上，這時MySQL主庫的寫壓力開始出現瓶頸，而數據量的持續猛增，因爲MyISAM使用表鎖，在高併發下會出現嚴重的鎖問題，大量的高併發MySQL應用開始使用InnoDB引擎代替MyISAM。採用Master-Slave複製模式的MySQL架構，只能對數據庫的讀進行擴展，而對數據的寫操做仍是集中在Master上。這時須要對數據庫的吞吐能力進一步地擴展，以知足高併發訪問與海量數據存儲的需求。

　　對於訪問極爲頻繁且數據量巨大的單表來講，首先要作的是減小單表的記錄條數，以便減小數據查詢所需的時間，提升數據庫的吞吐，這就是所謂的分表。在分表以前，首先須要選擇適當的分表策略，使得數據可以較爲均衡地分佈到多張表中，而且不影響正常的查詢。

　　分表可以解決單表數據量過大帶來的查詢效率降低的問題，可是卻沒法給數據庫的併發處理能力帶來質的提高。面對高併發的讀寫訪問，當數據庫master服務器沒法承載寫操做壓力時，無論如何擴展Slave服務器都是沒有意義的，對數據庫進行拆分，從而提升數據庫寫入能力，即分庫。

　　數據庫通過業務拆分及分庫分表，雖然查詢性能和併發處理能力提升了。可是本來跨表的事務上升爲分佈式事務；因爲記錄被切分到不一樣的庫和不一樣的表中，難以進行多表關聯查詢，而且不能不指定路由字段對數據進行查詢。且分庫分表後須要進一步對系統進行擴容（路由策略變動）將變得很是不方便，須要從新進行數據遷移。

 

分表策略：

　　使用用戶ID是最經常使用的分庫的路由策略。

　　當數據比較大的時候，對數據進行分表操做，首先要肯定須要將數據平均分配到多少張表中，也就是：表容量。

　　這裏假設有100張表進行存儲，則咱們在進行存儲數據的時候，首先對用戶ID進行取模操做，根據 user_id%100 獲取對應的表進行存儲查詢操做。

　　在實際的開發中，咱們的用戶ID更多的多是經過UUID生成的，這樣的話，咱們能夠首先將UUID進行hash獲取到整數值，而後在進行取模操做。

 

分庫策略：

 

　　數據庫分表可以解決單表數據量很大的時候數據查詢的效率問題，可是沒法給數據庫的併發操做帶來效率上的提升，由於分表的實質仍是在一個數據庫上進行的操做，很容易受數據庫IO性能的限制。

　　所以，如何將數據庫IO性能的問題平均分配出來，很顯然將數據進行分庫操做能夠很好地解決單臺數據庫的性能問題。

　　分庫策略與分表策略的實現很類似，最簡單的都是能夠經過取模的方式進行路由。

 

分庫與分表實現策略：

　　上述的配置中，數據庫分表能夠解決單表海量數據的查詢性能問題，分庫能夠解決單臺數據庫的併發訪問壓力問題。

　　有時候，咱們須要同時考慮這兩個問題，所以，咱們既須要對單表進行分表操做，還須要進行分庫操做，以便同時擴展系統的併發處理能力和提高單表的查詢性能，就是咱們使用到的分庫分表。

　　分庫分表的策略相對於前邊兩種複雜一些，一種常見的路由策略以下：

　　１、中間變量　＝ user_id%（庫數量*每一個庫的表數量）; 　　

　　２、庫序號　＝　取整（中間變量／每一個庫的表數量）; 　　

　　３、表序號　＝　中間變量％每一個庫的表數量;

 

參考：

　　https://blog.csdn.net/u010832551/article/details/77836681