現在，軟件架構變得越來越復雜了，好多技術層出不窮，令人眼花繚亂，解決這個問題呢，就是要把復雜問題簡單化，核心就是要把握本質。
軟件剛開始的時候是為了實現功能，隨着信息量和用戶的增多，大數據和高並發成了軟件設計必須考慮的問題，那么大數據和高並發本質是什么呢？
歡迎關注博客園麥小逗，小逗與你同在
本質很簡單，一個是慢，一個是等。兩者是相互關聯的，因為慢，所以要等，因為等，所以慢，解決了慢也就解決了等，反之亦然。
關鍵是如何解決慢和等，核心一個是短，一個是少，一個是分流。
短是指路徑要短。典型的MVC結構是請求->controller->model->view，然后把頁面返回給用戶。下面分別介紹三個核心。
短
1.頁面靜態化 -- 用戶可以直接獲取頁面，不用走那么多流程，比較適用於不頻繁更新的頁面，比如登錄頁、表單頁等。
2.使用緩存 -- 第一次獲取數據從數據庫准提取，然后保存在緩存中，以后就可以直接從緩存提取數據。不過需要有機制維持緩存和數據庫的一致性。
3.使用存儲過程 -- 哪些處理一次請求需要多次訪問數據庫的操作，可以把操作整合到存儲過程，這樣只要一次數據庫訪問就可以了。
4.批量讀取 -- 高並發情況下，可以把多個請求的查詢合並到一次進行，以減少數據庫的訪問次數。
5.延遲修改 -- 高並發情況下，可以把多次修改請求，先保存在緩存中，然后定時將緩存中的數據保存到數據庫中，分享是可能會斷電丟失緩存中的數據。
6.使用索引 -- 索引可以看作hi特殊的緩存，使用索引就要求where字句中精確的給出索引列的值。
少
少是指查詢的數據要少。
1.分表 -- 把本來同一張表的內容，可以按照地區、類別等分成多張表，很簡單的一個思路，但是要盡量避免分出來的多表關聯查詢。
2.分離活躍數據 -- 例如登錄用戶業務，注冊用戶很多，但是活躍的登錄用戶很少，可以把活躍用戶專門保存一張表，查詢是先查詢活躍表，沒有的話再查總表，這也類似於緩存啦。
3.分塊 -- 數據庫層面的優化，對程序是透明的，查詢大數據只用找到相應塊就行啦。
分流
1.集群 -- 將兵法請求分配到不同的服務器上，可以是業務服務器，也可以是數據庫服務器。
2.分布式 -- 分布式是把單詞請求的多項業務邏輯分配到多個服務器上，這樣可以同步處理很多邏輯，一般適用於特別復雜的業務請求。
3.CDN -- 在域名解析層面的分流，例如將華南地區的用戶分配都華南的服務器，華中地區的用戶分配到華中的服務器
THE END
歡迎各位攻城獅指正修改，也可微信搜索微信號amcdulls，或程小白，同步更新博文
轉載自http://www.cnblogs.com/New-Zealand/p/5165663.html