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

2022-08-19 20:06:08 字數 1260 閱讀 1128

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

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

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

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

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

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

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

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

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

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

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

少是指查詢的資料要少。

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

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

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

分流三種。

1,集群 - 將併發請求分配到不同的伺服器上,可以是業務伺服器,也可以是資料庫伺服器。

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

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

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

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

軟體剛開始的時候是為了實現功能,隨著資訊量和使用者的增多,大資料 和高併發成了軟體設計必須考慮的問題,那麼大資料和高併發本質是什麼呢?本質很簡單,乙個是慢,乙個是等。兩者是相互關聯的,因為慢,所以要等,因為等,所以慢,解決了慢,也就解決了等,解決了等,也就解決了慢。關鍵是如何解決慢和等,核心乙個是短...

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

現在,軟體架構變得越來越複雜了,好多技術層出不窮,令人眼花繚亂,解決這個問題呢,就是要把複雜問題簡單化,核心就是要把握本質。軟體剛開始的時候是為了實現功能,隨著資訊量和使用者的增多,大資料和高併發成了軟體設計必須考慮的問題,那麼大資料和高併發本質是什麼呢?本質很簡單,乙個是慢,乙個是等。兩者是相互關...

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

現在,軟體架構變得越來越複雜了,好多技術層出不窮,看得威哥眼花繚亂,解決這個問題呢,就是要把複雜問題簡單化,核心就是要把握本質。軟體剛開始的時候是為了實現功能,隨著資訊量和使用者的增多,大資料和高併發成了軟體設計必須考慮的問題,那麼大資料和高併發本質是什麼呢?威哥在網上也查閱了好些資料,總結了下大資...