壓力 mas pop 流量 track 操作 正常 其他 可能

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

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