高併發大流量站點架構簡單思路

******************************* 前端 ******************************* 1.添加必要的硬件和帶寬，同一時候額外儲備一部分，以備不時之需 2.特別監控網絡數據流量是否正常。如是否有大規模的爬蟲、DDOS等渾水摸魚，可以針對iP和Cookie的限流 3.使用CDN同一時候作一些必要的算法改造，動靜分離 ******************************* 代碼端 ******************************* 1.必要的代碼優化改造如軟件升級、慢查詢、client緩存、多線程之類 2.設計高峯期時的降級使用：關掉或暫停非核心的頁面功能、後端統計功能 3.SOA作好橫向擴展，最好是本身主動化擴展 4.負載選擇七層仍是四層。負載會不是瓶頸 5.各類高大上的緩存：reids、mongdb、memcache等 6.web到數據庫端需要一個「隔離區」，讓數據平穩、源源不斷的進入數據庫 7.儘可能不要使用帶複雜業務邏輯處理的存儲過程（猶其是在N大數據結果集中作業務邏輯處理)。下降數據庫CPU和內存壓力 8.功能模塊間。作好隔離。不能因爲一個功能載入不出數據。而影響其餘非相互依賴功能。 9.合理的鏈接池設計 ******************************* 後端 ******************************* 1.主從複製： 狀況1：很是難作到實時，但是切換時，可能有部分數據沒有同步過來，帶來了數據的一致性問題。 可以在操做主數據庫的同一時候。記錄操做日誌。切換到備時，會和操做日誌作個check，補齊未同步過來的數據。 狀況2：dbrd+master-slave模式或share eveything架構 2.PXC或MGC羣集的share nothing架構 3.依照頁面不一樣需求拆分數據庫:如用戶登陸、購物車、下單、支付等分佈在不一樣數據庫 4.按區域劃分DB：如華東、華北、華中、華南、華西不一樣區域用戶到不一樣IDC的DB，最後數據彙總到總部IDC就能夠；當問題爆發時不會影響全局。單機房DB壓力會減小. 5.數據庫硬件：如使用SSD、閃存存儲等. 6.純內存數據庫：如timesten、HANA或本身定製開發 7.殺手鐗： 1）強行設置交易完畢如起飛時間也過也不可能退款的數據歸檔。歸檔數據僅僅供查詢 . 2）假設第一種強行歸檔數據量依舊巨大，可以依照天如10天以前的歸檔。畢竟 80以上的交易都會完畢。在不大量改動代碼的狀況，如前端需要退款、改簽處理， 將數據直接insert導入主庫就能夠，畢竟數據庫insert不是最大的瓶頸. 3）依照訂單狀態拆分：下單未支付、支付完畢、處理中、支付完畢。分別架構到不一樣的表. ---------多機房容災探討 1.異地機房容災 A->P仍是A->A 2.單機房可以考慮多路光纖 3.底層複製：硬件、軟件(RSYNC、DBRD、OGG)