大資料和高並發的解決方案總結

標籤：

現在，軟體架構變得越來越複雜了，好多技術層出不窮，令人眼花繚亂，解決這個問題呢，就是要把複雜問題簡單化，核心就是要把握本質。

軟體剛開始的時候是為了實現功能，隨著資訊量和使用者的增多，大資料和高並發成了軟體設計必須考慮的問題，那麼大資料和高並發本質是什麼呢？

本質很簡單，一個是慢，一個是等。兩者是相互關聯的，因為慢，所以要等，因為等，所以慢，解決了慢，也就解決了等，解決了等，也就解決了慢。

關鍵是如何解決慢和等，核心一個是短，一個是少，一個是分流。

短是指路徑要短。典型的mvc結構是請求->controller->model->dao->view，然後把頁面返回給使用者。要想短的話，

1，頁面靜態化- 使用者可以直接擷取頁面，不用走那麼多流程，比較適用於頁面不頻繁更新。

2，使用緩衝- 第一次擷取資料從資料庫准提取，然後儲存在緩衝中，以後就可以直接從緩衝提取資料。不過需要有機制維持緩衝和資料庫的一致性。

3，使用儲存過程-那些處理一次請求需要多次訪問資料庫的操作，可以把操作整合到儲存過程，這樣只要一次資料庫訪問就可以了。

4，批量讀取 - 高並發情況下，可以把多個請求的查詢合并到一次進行，以減少資料庫的訪問次數

5，延遲修改 - 高並發情況下，可以把多次修改請求，先儲存在緩衝中，然後定時將緩衝中的資料儲存到資料庫中，風險是可能會斷電丟失緩衝中的資料，

6,  使用索引 - 索引可以看作是特殊的緩衝，盡量使用索引就要求where字句中精確的給出索引列的值。

少是指查詢的資料要少。

1，分表 - 把本來同一張表的內容，可以按照地區，類別等分成多張表，很簡單的一個思路，但是要盡量避免分出來的多表關聯查詢。

2，分離活躍資料 - 例如登入使用者業務，註冊使用者很多，但是活躍的登入使用者很少，可以把活躍使用者專門儲存一張表，查詢是先查詢活躍表，沒有的話再查總表，這也類似與緩衝啦。

3， 分塊 - 資料庫層面的最佳化，對程式是透明的，查詢大資料只用找到相應塊就行。

分流三種。

1，叢集 - 將並發請求分配到不同的伺服器上，可以是商務服務器，也可以是資料庫伺服器。

2，分布式 - 分布式是把單次請求的多項商務邏輯分配到多個伺服器上，這樣可以同步處理很多邏輯，一般使用與特別複雜的業務請求。

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

 

暫時總結這麼多的方案，隨著技術的進步，會有更多的方案出現，一起成長進步中。。。。。

 

大資料和高並發的解決方案總結