數據庫高併發解決方案（二）部署優化

一個項目剛開始的時候是爲了實現基本功能，隨着版本和功能的迭代，大數據和高併發成了軟件設計必須考慮的問題!

本質很簡單，一個是慢，一個是等。

二者是相互關聯的，由於慢，因此要等，由於等，因此慢，解決了慢，也就解決了等，解決了等，也就解決了慢。

關鍵是如何解決慢和等，

核心 一個是短，一個是少，一個是分流,最後一個是集羣/橫向擴張/讀寫分離/創建主從

短

頁面靜態化- 用戶能夠直接獲取頁面，不用走那麼多流程，比較適用於頁面不頻繁更新。
使用緩存- 第一次獲取數據從數據庫準提取，而後保存在緩存中，之後就能夠直接從緩存提取數據。不過須要有機制維持緩存和數據庫的一致性。

使用儲存過程-那些處理一次請求須要屢次訪問數據庫的操做，能夠把操做整合到儲存過程，這樣只要一次數據庫訪問就能夠了。

批量讀取 - 高併發狀況下，能夠把多個請求的查詢合併到一次進行，以減小數據庫的訪問次數

延遲修改 - 高併發狀況下，能夠把屢次修改請求，先保存在緩存中，而後定時將緩存中的數據保存到數據庫中，風險是可能會斷電丟失緩存中的數據，

使用索引 - 索引能夠看做是特殊的緩存，儘可能使用索引就要求where字句中精確的給出索引列的值。

少

1，分表 - 把原本同一張表的內容，能夠按照地區，類別等分紅多張表，很簡單的一個思路，可是要儘可能避免分出來的多表關聯查詢。

2，分離活躍數據 - 例如登陸用戶業務，註冊用戶不少，可是活躍的登陸用戶不多，能夠把活躍用戶專門保存一張表，查詢是先查詢活躍表，沒有的話再查總表，這也相似與緩存啦。

3， 分塊 - 數據庫層面的優化，對程序是透明的，查詢大數據只用找到相應塊就行；如交易模塊

分流

1，集羣 - 將併發請求分配到不一樣的服務器上，能夠是業務應用服務器APP，也能夠是數據庫服務器。

2，分佈式 - 分佈式是把單次請求的多項業務邏輯分配到多個服務器上，這樣能夠同步處理不少邏輯，通常使用與特別複雜的業務請求。

3，CDN - 在域名解析層面的分流，例如將華南地區的用戶請求分配到華南的服務器，華中地區的用戶請求分配到華中的服務器。

4，分庫分表 -

水平拆分【分表】：

對於訪問極爲頻繁且數據量巨大的單表來講，首先要作的是減小單表的記錄條數，以便減小數據查詢所需的時間，提升數據庫的吞吐，這就是所謂的分表【水平拆分】

垂直拆分【分庫】：

是根據業務耦合性，將關聯度低的不一樣表存儲在不一樣的數據庫上，對數據庫進行拆分，從而提升數據庫寫入能力，即分庫【垂直拆分】

 

創建主從 - 讀寫分離就是隻在主服務器上寫，只在從服務器上讀，基本原理是讓主數據庫處理事務性查詢，而從數據庫處理select查詢，數據庫複製被用於把事務性查詢（增刪改）致使的改變；以毫秒級的更新同步到集羣中的從數據庫。