解決企業搞併發的痛點，難在**？有套路嗎？
我想隨便講講大資料高併發貌似很高大上的內容是否有套路
所謂高併發，出現的問題。無非於資料量大、訪問突增、流量大、響應慢等。
看過很多解決的所謂高大上的方案。總歸介於怎麼做負載均衡、容災、快取、分布式等。從物理架構上來說，怎麼做好負載、集群、**或者就近**。從軟體的角度也無非怎麼做快取、動靜分離、讀寫分離等。
負載均衡技術
負載均衡
建立在現有網路結構之上，它提供了一種廉價有效透明的方法擴充套件
網路裝置
和伺服器
的頻寬、增加
吞吐量、加強網路資料處理能力、提高網路的靈活性和可用性。
常用的負載均衡技術包括：lvs、apache、dns等
動靜分離技術
將靜態內容（如：、css、js等）與動態內容分離，長用到的技術nginx。
快取技術
常見得將資料載入到記憶體。memcached、mongodb、redis
資料庫集群技術
目前常見的使用mysql作為源資料庫
分布式儲存技術或者分布式計算技術
目前比較流行的hadoop、spark
下圖簡單的展示乙個高併發架構圖
1、 對lvs做容錯。
2、 lvs將請求**到不痛集群環境
4、 資料回寫**。
一般的的解決方案有兩種
1、 系統或者伺服器的解決方案
增大伺服器的cpu。
增加記憶體條。
增加硬碟個數，對硬碟做raid5。
換掉免費的tomcat，使用商用weblogic
增加到二塊網絡卡。
花**直接購買高效能伺服器
當業務或者使用者不斷增大的時候效能又會出現瓶頸
2、 系統應用解決方案
網頁html 靜態化（需要cms專案支援）
伺服器分離（常用解決方案）
快取（常用解決方案）分布式快取
這個同樣會出現上述問題
3、 橫向拓展伺服器解決
拓展橫向應用伺服器
1、 解決ip
當使用者過大的時候採用dns解決ip問題
迴圈復用 dns將傳入的 ip 請求對映到定義的一系列迴圈形式的伺服器。一旦發生伺服器故障，迴圈復用 dns 繼續把請求傳送到這個故障伺服器，一直到把該伺服器從 dns 中移走為止。這樣許多使用者必須等到 dns 連線超時以後才能成功地訪問目標**
然後出現了負載均衡解決方案
使用負載均衡做位址**
1:**請求
2:故障移除
3:恢復新增
硬體上的負載均衡
netscaler、f5、radware和array等商用的負載均衡器。土豪任性
軟體上的負載均衡
lvs、nginx、apache等
架構設計原則 高併發
架構設計原則 高併發 高併發設計可以從以下幾方面考慮 1.無狀態 無狀態的應用容易進行水平擴充套件。實際常用 應用無狀態，配置檔案有狀態，例如，不同的機房讀取不同的配置檔案，通過配置中心指定。2.拆分 拆分維度 3.服務化 服務化需要考慮自動服務註冊，和服務發現，還有服務的分組 隔離，例如，有的系統...
高併發架構設計原則 拆分
在系統設計初期，是做乙個大而全的系統還是根據模組進行拆分要根據環境和需求進行權衡。訪問量不大 功能簡單 研發資源不多時可以做乙個大而全的系統即可 如果訪問量大資源充足 功能繁多可以考慮按功能拆分系統。下面幾種拆分維度 按照系統功能 業務拆分，比如商品系統 購物車系統 結算系統 訂單系統等。對乙個系統...
高併發架構設計學習總結
設計目標 打造乙個高可用 高效能 易擴充套件 可伸縮性強的應用系統。架構分類 1.業務架構,如何分拆模組,如何大團隊協作,快速高效滿足業務迭代,微服務 2.效能架構 高併發架構,高負載架構,架構 軟體應用分為 架構設計,程式,資料結構,演算法 常用設計方向 流量分流 nginx負載均衡,反向 靜態化...