大型網站技術架構之高可用
服務部署：一般上線之前會合並代碼到develop分支上，然後通過打包平臺進行編譯打包，然後將包通過scp傳到服務器上，ssh 服務器ip 然後執行命令重啓服務，重啓之前，先從ngnix切除到這臺服務器的請求(通過命令修改配置刪掉對應服務器ip，然後reload nginx)，等待1、2秒 等到應用服務處理完正在處理的數據，最後重啓服務器，然後檢查其端口是否啓用，是否有錯誤日誌，如果一切正常則將服務掛到nginx上，再重啓其他服務
1、應用服務高可用
通過負載均衡器，對應用服務心跳檢測、對失效請求轉移到其他正常服務器上
集羣上的服務是對等的，無狀態的，伸縮更靈活
對於有狀態服務，session的管理(當用戶登錄成功後，用戶訪問其他頁面時，也就是在當前會話執行所有操作都是有效的)
例如用戶A加了一件商品到購物車，然後用戶A又加了一件商品到購物車，這個時候用戶看到購物車要有兩件商品，也就是說要有服務器上要保存某個人購物車的數據，等於就是說同個人的請求都需要打到同臺機器上。
-
通過對ip或根據客戶端cookie計算一個hash值，對機器數取餘，將同個客戶端請求達到同臺機器，但是當增加一臺或移除一臺機器時，都會導致請求打到其他器上了
-
將session信息存放到cookie上，請求時帶上，然後將新的session信息寫會客戶端，這可以避免上面服務伸縮帶來的問題，但是將session信息存放在客戶端不安全，由於客戶端可能會關閉cookie
-
session存放在數據庫中
登錄成功後返回給客戶端一個token，然後後面會話中帶上token，後端進行校驗會話是否有效，這種方式就是將session信息存儲在數據庫或緩存中
- 對於有些業務對session管理要求高的可以將session管理單獨做成一個服務器集羣，做成單點登錄(SSO)、用戶服務，對於用戶來說在各個網站都是用同一個賬號進行登錄，這些服務都需要請求session服務校驗用戶信息
2、服務層(公用服務、其他服務)高可用
應用層服務通過RPC方式調用基礎服務，這些基礎服務也是集羣部署的，無狀態的，負載均衡策略在調用端。
- 分級管理
將服務按照重要性劃分級別，分配對應配置的機器，保證重要的服務能高效穩定運行
- 異步
通過異步方式(消息隊列)解除服務間耦合和提高請求響應，例如註冊成功後需要給用戶下發郵件，以及分配權限，等一系列操作，可以通過下發一個註冊成功消息到隊列中，可以讓其他服務對此消息進行消費，坐後續邏輯，不要因爲發郵件失敗了而影響用戶註冊。讓用戶能快速註冊。
但是對應用戶響應請求，或者下一步操作需依然前面響應結果時，不能夠使用異步方式
- 服務降級（拒絕請求、關閉功能）
在高併發、高流量時候，爲了保證服務不被沖垮，會通過拒絕部分請求，可以隨機拒絕用戶請求
可以關閉其他不重要功能爲其他核心功能騰出資源
- 超時設置
爲了避免對方服務巖機或線程死鎖，調用端遲遲收不到響應，而此時調用端依然佔用資源(線程池資源，調用端公用同個tcp連接，當多個線程同時向同個socket連接寫數據時 系統通過給寫入緩存區加鎖保證線程安全)，同時也不能及時將請求轉發的其他服務器上。所以通過增加超時時間，超時時間不能過長，根據每個接口執行邏輯預測一個超時時間，過短會導致重試過多增加服務器壓力
- 冪等性
無論是服務執行成功了，但是響應數據時因網絡慢導致超時，還是服務負載高一直沒有響應都會導致調用端重複提交請求，因此就會導致重複調用問題，需要在服務端保證重複調用和調用一次結果一樣(冪等性)，不管接口是否會重複請求多少次，對業務數據都不會造成影響，例如轉轉接口需要保證冪等性，否則如果重複請求就會導致多次扣款情況
3、數據層高可用
同樣採用冗餘的方式，保證數據服務的高可用性，服務A中的分片數據同步一份到服務B中作爲一個副本，當服務A down機時會，會選舉其他服務節點中分區的副本爲主分區，然後將請求轉移到該服務上，並將數據同步到其他服務節點作爲副本，實現高可用。
- CAP原理:Consistency + Available + Partition
CAP原理對分佈式系統設計具有重要指導意義
Consistency: 一致性，所有應用程序都能訪問到相同的數據
Availiable: 可用性，無論什麼時候都可以進行讀和寫操作
Partition：分區忍耐性，對於數據量很大時需要對數據根據某個維度，例如根據用戶id將數據劃分到不同分區，這樣系統伸縮性好，通過增加多臺機器就可以解決數據量大到不能使用一臺機器能存下的難題，對於主從模式，增加從庫並不能解決數據量大的問題，因爲從庫存放的還是全部的數據，需要將數據分散到不同機器進行存放
以上三個條件不能同時滿足，必須要犧牲一個條件來換取另外一個條件，例如不能同時保證可用性和一致性，因爲如果需要保證可用性就需要將數據備份到多個機器上，然而不能保證在同步數據過程中其他讀請求不會讀備份機器，這就會出現數據不一致的問題。
在分佈式系統中，可用性是最需要保證的，其次是分區忍耐性，最後是一致性，可以通過補償事務，業務邏輯來保證數據最終一致性
- 一致性
強一致性：無論什麼時候讀取數據都能讀到相同的數據，當更新或插入數據時返回給客戶端失敗了，那麼一定是沒有操作成功，不會出現中間狀態，這個在單點數據服務是能保證的，但是如果在分佈式數據服務中保證強一致性需要犧牲性能，因爲當執行一個更新請求時，必須要等到將數據同步到其他機器時才返回結果
用戶一致性：實際上數據服務中的各個副本數據並不一致，但是通過一些補償操能返回給用戶正確的數據
最終一致性：多次請求數據服務時，每次請求結果會不一樣，但是經過一個窗口期時最終數據會達到一致的。數據不一致性一般出現在高併發寫和更新操作或數據的恢復或集羣擴容時
數據服務高可用保證
數據服務可用性保證：第一保證數據有備份，第二保證數據服務down機能夠將失效請求轉移到其他數據服務器上
- 數據備份(數據冗餘)
冷備份和熱備份：
冷備份：定時對數據進行備份，缺點就是會丟失一部分數據，從備份的數據恢復需要一定的時間，這段時間內不能提供服務
熱備份：每次寫入數據時都會同步一份數據到其他服務器上，這裏同步可以分爲兩種，同步和異步方式
同步方式：當寫入的數據都成功寫入到其他備份的服務器上才響應寫請求，爲了提高性能可用通過多個線程並行的寫入到其他機器上，最終以最耗時的請求爲最終處理數據
異步方式： 只給一個主服務上發送寫請求，寫成功後就返回，然後由主服務同步到其他從服務器上
MySQL採用一主多從方式，對數據庫操作請求發到主庫中，讀取數據操作發到從庫中，主庫和從庫採用binlog 進行同步數據
如果主庫掛了同樣會導致服務不可用，所以需要再起一個主庫，同時也需要將另外一個主庫數據同步到該主庫，用作冷備份，一旦主庫掛了就將其升爲主庫，接受寫請求。
- 失效轉移
失效確認
失效轉移
數據恢復
軟件質量保證
-
網站發佈(升級服務)
-
自動化測試
-
代碼版本控制 (主幹上線，分支上開發版本)
-
自動化部署、火車模型，多階段確認，上線前測試確認、合併分支確認、預上線確認、正式環境部署確認
-
灰度發佈(A/B test) 爲了避免當升級新版本時導致整體服務異常，而將整體服務回滾帶來的不可用性，採用分批次部署服務，將部分流量引入(一般是在網關切流量或在nginx切流量)到新版本服務器上，等check沒有問題後再部署到其他服務器上
數據和系統監控
沒有監控的系統猶如沒有儀表的汽車
用戶行爲數據的記錄可以成爲個人性化推薦基礎數據
系統運行狀態數據收集以及當系統有一定負載是進行報警
