乙個專案剛開始的時候是為了實現基本功能，隨著版本和功能的迭代，大資料和高併發成了軟體設計必須考慮的問題!
本質很簡單，乙個是慢，乙個是等。
兩者是相互關聯的，因為慢，所以要等，因為等，所以慢，解決了慢，也就解決了等，解決了等，也就解決了慢。
關鍵是如何解決慢和等？
核心 乙個是短，乙個是少，乙個是分流,最後乙個是集群/橫向擴張/讀寫分離/建立主從
短頁面靜態化- 使用者可以直接獲取頁面，不用走那麼多流程，比較適用於頁面不頻繁更新。使用快取- 第一次獲取資料從資料庫準提取，然後儲存在快取中，以後就可以直接從快取提取資料。不過需要有機制維持快取和資料庫的一致性。
使用儲存過程-那些處理一次請求需要多次訪問資料庫的操作，可以把操作整合到儲存過程，這樣只要一次資料庫訪問就可以了。
批量讀取 - 高併發情況下，可以把多個請求的查詢合併到一次進行，以減少資料庫的訪問次數。
延遲修改 - 高併發情況下，可以把多次修改請求，先儲存在快取中，然後定時將快取中的資料儲存到資料庫中，風險是可能會斷電丟失快取中的資料。
使用索引 - 索引可以看作是特殊的快取，盡量使用索引就要求where字句中精確的給出索引列的值。
少
1，分表 - 把本來同一張表的內容，可以按照地區，類別等分成多張表，很簡單的乙個思路，但是要盡量避免分出來的多表關聯查詢。
2，分離活躍資料 - 例如登入使用者業務，註冊使用者很多，但是活躍的登入使用者很少，可以把活躍使用者專門儲存一張表，查詢是先查詢活躍表，沒有的話再查總表，這也類似與快取啦。
3， 分塊 - 資料庫層面的優化，對程式是透明的，查詢大資料只用找到相應塊就行；如交易模組
分流
2，分布式- 分布式是把單次請求的多項業務邏輯分配到多個伺服器上，這樣可以同步處理很多邏輯，一般使用與特別複雜的業務請求。
3，cdn- 在網域名稱解析層面的分流，例如將華南地區的使用者請求分配到華南的伺服器，華中地區的使用者請求分配到華中的伺服器。
4，分庫分表-
水平拆分【分表】：
對於訪問極為頻繁且資料量巨大的單錶來說，首先要做的是減少單錶的記錄條數，以便減少資料查詢所需的時間，提高資料庫的吞吐，這就是所謂的分表【水平拆分】
垂直拆分【分庫】：
是根據業務耦合性，將關聯度低的不同表儲存在不同的資料庫上，對資料庫進行拆分，從而提高資料庫寫入能力，即分庫【垂直拆分】
建立主從 - 讀寫分離就是只在主伺服器上寫，只在從伺服器上讀，基本原理是讓主資料庫處理事務性查詢，而從資料庫處理select查詢，資料庫複製被用於把事務性查詢(增刪改)導致的改變；以毫秒級的更新同步到集群中的從資料庫。
·end·php開源社群高階·提公升·漲薪
高併發解決方案
時常看到高併發的問題，但高併發其實是最不需要考慮的東西。為何，他虛無縹緲，很少有 真的需要這些東西，而且其中很多技術，其實你已經在用了。有這個意識就夠了，不需要時刻盯著這個問題。只有很少的 真的能達到高併發。簡單做乙個歸納，從低成本 高效能和高擴張性的角度來說有如下處理方案 1 html靜態化 2 ...
高併發解決方案
將靜態資源分離到靜態站，對靜態資源的請求打到靜態站，增加動態站的請求處理量 頁面靜態化是將程式生成的頁面儲存起來，使用模板技術如freemarker和velocity生成靜態頁面 nginx快取頁面資訊，再次請求時直接從快取中獲取，不需要重新生成，頁面快取記憶體中，提高訪問速度 具有相同處理功能的伺...
高併發解決方案
秒殺場景一般會在電商 舉行一些活動或者節假日在12306 上搶票時遇到。對於電商 中一些稀缺或者 商品，電商 一般會在約定時間點對其進行限量銷售，因為這些商品的特殊性，會吸引大量使用者前來搶購，並且會在約定的時間點同時在秒殺頁面進行搶購。限流 鑑於只有少部分使用者能夠秒殺成功，所以要限制大部分流量，...