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

高並發大流量網站架構簡單思路，並發流量架構
*******************************
前端
*******************************
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)

著作權聲明：本文為博主原創文章，未經博主允許不得轉載。