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

***
前端
***
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)

來自：http://blog.csdn.net/yangzhawen/article/details/47040357