高可用系統設計

在系統運行期間，有可能硬件的損壞、軟件運行中流量激增致使宕機等，致使系統不能正常運行。爲了解決這些異常，咱們能夠從如下幾個來考慮。

冗餘

好比咱們旅遊拍了不少照片，放在手機裏怕丟怎麼辦啊，咱們會上傳到百度網盤，這個就是冗餘。
冗餘是最簡單的辦法，同時也要作到故障轉移，好比爲了保證nginx的高可用，咱們會啓動兩個nginx，一個是主一個是備，還要再弄一個Keepalive，當主掛了，Keepalive會自動切換到備份的nginx。
好比mysql數據庫，咱們會作主從，slave經過binlog同步master的數據，當master掛了，會切換到slave（因爲數據的同步是異步的，此時可能會丟失數據）。
好比redis，咱們採用哨兵或者集羣的形式，當master掛了自動檢測並切換到slave。
好比消息隊列，好比hadoop，好比kafka，好比elasticsearch等等，都是經過冗餘來保證系統或者副本的高可用性。
若是條件容許，還須要作到多地多活。否則備份同一個機房，機房發生火災，數據所有丟失，備份同一個地點，發生地震洪水等天然災害，數據所有丟失。

超時重試

當咱們調用第三方接口的時候，或者網關層調用業務邏輯層等，因爲網絡或者其餘問題，致使咱們的請求沒有獲得響應或者好久才獲得響應，爲了保證咱們的服務是高可用的，咱們一般會設置重試的次數和超時的時間。
重試的次數不能太大，這樣很容易請求流量翻了不少倍，形成被請求服務的雪崩。
超時的時間不能設置的太長，這樣很容易讓本身一直等待，積壓了不少請求，致使本身服務雪崩。也不能過短，還沒響應就直接取消了，形成請求成功率降低。
若是A調用B，B調用C，此時A的超時時間應該要長與B調用C的超時時間。好比A->B是100毫秒，B->C是200毫秒，B在150毫秒拿了C的響應，可是A已通過期了，而後A又開始了重試，請求流量又漲漲漲。
咱們重試的機制，必需要肯定被調用方的接口是冪等性的，否則會形成數據的錯亂。

降級熔斷

當咱們調用第三方接口的時候，第三方響應慢或者沒響應，好比宕機或者網絡不可用，不斷的請求，會佔用咱們的系統資源，更甚者會致使咱們系統的雪崩，因此咱們經過降級熔斷來避免雪崩狀況。
好比咱們原先調用第三方獲取商品的信息，此時第三方不可用，咱們就調用本身的本地緩存、redis緩存或者直接返回空，這個叫降級。若是第三方一直不可用，那咱們就不調用第三方，直接本身處理，這個叫熔斷。若是熔斷了，須要異步調用看第三方服務是否恢復了，若是恢復了，取消熔斷。
目前比較火的就是sentine以及hystrix。

冪等設計

當咱們提供接口給第三方的時候，因爲第三方可能的重試，形成數據的錯亂，因此咱們要保證咱們的系統是冪等的。接口冪等設計

限流

當咱們提供接口給第三方的時候，因爲第三方可能大規模的調用，流量超過了咱們系統的峯值，致使咱們系統的不可用。咱們能夠想直接降級來解決，返回空或者緩存數據，可是有些業務場景，好比秒殺，就不能經過降級來解決，此時就須要限流，讓有限的流量進來。經常使用的限流算法有令牌桶和漏桶兩個。有時候也根據計數器，來限制數據庫鏈接池、線程池的併發數。

壓測

不論是哪一種限流方式，咱們都須要知道咱們系統的峯值在哪裏，因此須要壓測，方便擴容和設置限流閾值。

線下壓測

包括使用apache ab、apache jmeter、loadrunner、Tcpcopy 這些工具，對接口進行壓測，對測試的結果進行性能優化以及確認系統的閾值。壓測的時候儘可能保證硬件設施和測試數據接近線上，這樣才能夠保證結果的準確性。

線上壓測

當服務器比較少的時候，咱們還原線上的環境須要的開銷其實不太大，若是服務器不少的時候，那開銷就很大了，因此要利用線上的環境來進行壓測。
線上壓測包括讀壓測、寫壓測、讀寫混合壓測。寫壓測的時候，要注意寫的數據和真是數據隔離。
好比咱們有100個服務作集羣，在凌晨或者流量小的時候，逐步引流到指定的服務，好比從100到90到80，監控各個服務、數據庫、第三方中間件等的cpu內存狀況。