關於網站高可用性問題的總結

本文是工做中遇到的網站高可用問題及相關解決思路和方法的總結，比較零碎，且會在後續工做過程當中不停豐富，有不對之處，請指正。

先後端分離

先後端分離後，可使用更加輕量級的web容器部署靜態資源，如nginx等，還能夠對靜態資源進行cdn加速，同時針對營銷或者活動頁面，可使用內容管理平臺，實時更改頁面，快速迭代。服務端出來後，專一於業務流程，且爲後續的服務拆分提供了便利。

按照業務領域拆分服務

隨着業務量的增長，單體架構不能再知足高併發場景，按照業務領域將服務端拆分爲多個獨立的服務。服務拆分後，這些服務獨立部署，獨立擴展，服務之間徹底解耦。

拆分後的服務一般是無狀態的，會話管理等一般交給網關層，或者統一的sso服務，業務服務省去了複雜的會話管理，服務效率提升；

拆分後的服務支持分佈式多實例部署，從而達到按需擴展的目的，在應對突發的流量暴增時，如營銷活動等，能夠迅速按需擴展，提升站點的可用性。

集羣部署，負載均衡

拆分後的服務支持分佈式部署，可使用集羣部署、負載均衡的方式進一步提高網站可用性。集羣部署模式下，多臺實例分擔流量，並能靈活地增減成員實例；負載均衡機制能夠確保某些成員實例失效時，能迅速將流量切換到其餘正常成員實例上，從而提升站點的可用性。

負載均衡的方式一般有兩種：

• 硬件負載——F5 7層或者4層網絡代理
• 軟件負載——nginx反向代理

負載均衡的算法一般有：輪詢法、隨機法、源地址哈希法、加權輪詢法、加權隨機法、最小鏈接數法

可參考：6種負載均衡算法

使用緩存提升查詢服務性能

在查多寫少的場景，很是適用使用緩存來提高查詢服務的性能，減輕對數據庫的壓力。一般使用redis cluster做爲緩存服務器，redis cluseter機制能很大程度上保證緩存服務的高可用性，及時緩存服務故障，還能從數據庫獲取信息。

spring+mybatis+redis作擴展緩存的具體實踐後續給出。

數據庫讀寫分離，分庫分表

業務迅猛到後面，當用戶在千萬級別時，數據庫會成爲最後的瓶頸，首先能夠根據業務場景分析，考慮作讀寫分離。寫到master庫，讀salve庫。若是讀寫分離也沒法知足高併發要求，須要考慮使用分表分庫的思路進行橫向擴展。數據庫只容許單表操做對於分表分庫落地很是友好，所以，在開發前期就約定，業務數據庫操做必須單表操做。

讀寫分離，分庫分表的技術手段尚未嘗試過，可是如今的系統設計之初就是按照單表操做約定的，所以後續進行橫向擴展時會比較便利。

orcle不是分佈式數據庫，但提供了RAC模式。參考：oracle rac和分佈式數據庫的區別

分庫分表的實際落地方案是有必定難度和取捨的，其中最關鍵點須要考慮到sharding數的擴張，有空研究下。

數據庫儘可能少使用事務

通常意義上，你們都會使用數據庫級別的事務來保證業務操做的原子性和數據一致性，可是數據庫事務的使用會帶來性能上的損耗，爲此，除非非用不可，其餘時候儘可能少用。實踐下來，這一條是能夠作到的。

那麼何時能夠不用呢？簡單講前置數據庫操做能夠重複進行時，就能夠不作事務控制。就是好比用戶註冊場景，會先insert ‘通行證credential’表，再insert ‘用戶user’表，不使用事務控制，咱們能夠將credential的操做放在user表操做前面，即便credential成功，user插入失敗，對數據一致性沒有影響，由於用戶再次註冊會從新生成一個userId，能從新insert credential後，再insert user表。對於用戶的影響也和加上事務控制的效果一致。很差的影響在於多生成了一條credential記錄。這裏的insert ‘通行證credential’表操做就是前置數據庫操做，可是非關鍵數據庫操做，由於註冊的最終效果是必須在user表中插入一條userId，後續登陸時會從user表中獲取用戶信息進行驗證。

何時非用不可呢？在訂單/支付等業務系統時，同一筆訂單不容許重複支持這是底線，所以在訂單支付場景，須要加上事務控制，避免訂單重複支付發生。

異步化非關鍵業務

非關鍵業務是指用戶不關心的業務環節，好比註冊完成後，發送營銷短信通知給用戶，用戶並不關心這個營銷短信是否能及時送達。對於此類非關鍵業務環節，能夠在設計上進行異步化處理。

經常使用的處理方式有：

• 簡單的處理方式——在流業務線程以外，另起線程/線程池來出來這類異步任務；特別須要主要線程池的使用，一般要同時限定thread size和queue size，不然在某些異常狀況下，異步線程所有阻塞，致使任務堆積，會影響到主業務線程的執行。
• 更好的方式——使用queue來做爲任務的中轉站，有後臺job進行任務的離線處理，這樣作還能有其餘便利之處，好比job做爲基礎設施存在，可以有效利用計算資源。

異步化須要考慮業務場景是不是關鍵場景，任務是否能夠容忍丟失。若是不容忍丟失，則智能使用queue的方式，且要對消息進行持久化。

使用異步IO

tomcat使用NIO提高服務性能，對提升網站的可用性也是有益的。

NIO vs BIO vs AIO 須要從新研究下，後續補上。

服務降級，服務熔斷

網站架構發展到後面，服務之間的調用變得錯綜複雜，故障發生以後可以清晰知道是那條服務鏈路出現了問題，並能及時處理變得很重要。所以須要對服務進行治理，提供服務註冊、發現機制，在此基礎上，當發現某個服務異常時，能夠對該服務或者某個調用渠道進行服務降級，或者針對下游某個異常服務進行熔斷處理，確保網站其餘非異常服務的可用性。

好比：統一登陸服務場景，須要根據不一樣的登錄方式，調用下游不一樣的帳戶驗證服務，A帳戶驗證服務一旦出現問題不能殃及B帳戶驗證，因此能夠在A帳戶/B帳戶驗證服務的調用上加上熔斷機制處理，確保A帳戶驗證服務調用和B帳戶驗證服務調用之間互不影響。

這一點的設計思想是：理性地砍掉腐爛的手，繼續前進，是一種捨得精神。

 

TODO......