假如目前的系統有100臺機器，能夠支撐每天1億的點擊量(這個就簡單比喻一下)，然后系統流量劇變了要，我如何應對，系統有那些策略可以處理，這里總結了一下之前的一些做法。

[[152984]]

1、水平擴展

這個最容易理解，加機器，這樣的話對于系統剛剛開始的伸縮性設計要求比較高，能夠非常靈活的添加機器，來應對流量的變化。

2、系統分組

假如系統服務的業務不同，有優先級高的，有優先級低的，那就讓不同的業務調用提前分組好的機器，這樣的話在關鍵時刻，可以保核心業務。

3、系統限流

系統機器也加了，然后分組也做了，但是就是能力提升不上來，說白了就那樣了，這時候，可以設置系統的極限能力閥值，例如QPS***到多少，或者是同時并發的任務有多少，超過這個閥值之后就拒絕提供服務了。

4、業務引流

這個的話跟多的是業務做的事情，把流量引走，不要來請求系統了，一種簡單的做法就是，冗余的業務直接隱藏掉鏈接，從開源節流的角度來想，就是開源。

5、業務降級

如果一個系統請求，涉及到多個邏輯處理，其中有的是可以沒有的，就是類似錦上添花的那種，在高并發的情況下，可以通過系統開關的形式，不去做這個請求，這樣就間接的提升了系統的能力，畢竟少做了一件事情。

6、依賴系統的能力擴展

如果單獨看應用系統，可能東西要做的還真不多，但是要結合上下游的系統，尤其是下游依賴的存儲系統，數據庫是否能夠支持夠，分布式緩存是否能夠支持夠，都需要做好評估。

7、系統依賴梳理

上一條主要是說存儲系統，如果本身是SOA的形式，可能會依賴其他系統，各個系統是否強弱依賴，在那個環節依賴了，都需要評估出來，可以人肉來做，也可以系統分析調用情況，來自動的做出來。

8、系統容量評估

系統到底能夠撐多少的量，這個要有個客觀數字的評估，需要結合系統的負載以及響應時間等數據，搞出一個模型出來，這樣方便數字化出來。

9、數據庫的讀寫分離以及主備按照讀寫比例進行劃分

這個在數據庫方面可以做優化

博文出處：http://iamzhongyong.iteye.com/blog/2154747