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

*******************************
前端
*******************************
1.增長必要的硬件和帶寬，同時額外儲備一部分，以備不時之需
2.特別監控網絡數據流量是否正常，如是否有大規模的爬蟲、DDOS等渾水摸魚，能夠針對iP和Cookie的限流
3.使用CDN同時作一些必要的算法改造，動靜分離



*******************************
代碼端
*******************************
1.必要的代碼優化改造如軟件升級、慢查詢、客戶端緩存、多線程之類
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)