一、服務協調
分布式協調技術主要用來解決分布式環境當中多個程序之間的同步控制，讓他們有序的去通路某種臨界資源，防止造成"髒資料"的後果。
分布式鎖也就是我們分布式協調技術實作的核心内容。
分布式鎖兩種實作方式：
1. 基于緩存（Redis等）實作分布式鎖 擷取鎖的時候，使用setnx加鎖，并使用expire指令為鎖添加一個逾時時間，超過該時間則自 動釋放鎖，鎖的value值為一個随機生成的UUID, 釋放鎖的時候進行判斷。 擷取鎖的時候還設定一個擷取的逾時時間，若超過這個時間則放棄擷取鎖。 釋放鎖的時候，通過UUID判斷是不是該鎖，若是該鎖，則執行delete進行鎖釋放。
- SETNX ：set一個key為value的字元串，傳回1；若key存在，則什麼都不做，傳回0。
- expire: 為key設定一個逾時時間，機關為second，超過這個時間鎖會自動釋放，避免死鎖。
- delete ：删除key
2. ZooKeeper是一個為分布式應用提供一緻性服務的開源元件，它内部是一個分層的檔案系統目錄樹 結構，規定同一個目錄下隻能有一個唯一檔案名, 基于ZooKeeper實作分布式鎖的步驟如下：
- 建立一個目錄mylock
- 線程A想擷取鎖就在mylock目錄下建立臨時順序節點
- 擷取mylock目錄下所有的子節點，然後擷取比自己小的兄弟節點，如果不存在，則說明目前 線程順序号最小，獲得鎖
- 線程B擷取所有節點，判斷自己不是最小節點，設定監聽比自己次小的節點
- 線程A處理完，删除自己的節點，線程B監聽到變更事件，判斷自己是不是最小的節點，如果 是則獲得鎖
二、服務削峰
1、為什麼要削峰
主要是還是來自于網際網路的業務場景，例如，春節火車票搶購，大量的使用者需要同一時間去搶購； 以及大家熟知的阿裡雙11秒殺， 短時間上億的使用者湧入，瞬間流量巨大（高并發）。
2、流量削峰方案
削峰從本質上來說就是更多地延緩使用者請求，以及層層過濾使用者的通路需求，遵從“最後落地到資料 庫的請求數要盡量少”的原則。
1. 消息隊列解決削峰 要對流量進行削峰，最容易想到的解決方案就是用消息隊列來緩沖瞬時流量，把同步的直接調用轉 換成異步的間接推送，中間通過一個隊列在一端承接瞬時的流量洪峰，在另一端平滑地将消息推送出去。
消息隊列中間件主要解決應用耦合，異步消息， 流量削峰等問題。常用消息隊列系統：目前 在生産環境，使用較多的消息隊列有 ActiveMQ、RabbitMQ、 ZeroMQ、Kafka、RocketMQ 等。 在這裡，消息隊列就像“水庫”一樣，攔截上遊的洪水，削減進入下遊河道的洪峰流量，進而達 到減免洪水災害的目的。
2. 流量削峰漏鬥：層層削峰 分層過濾其實就是采用“漏鬥”式設計來處理請求的，這樣就像漏鬥一樣，盡量把資料量和請求量一 層一層地過濾和減少了。如下圖所示：
分層過濾的核心思想
- 通過在不同的層次盡可能地過濾掉無效請求。
- 通過CDN過濾掉大量的圖檔，靜态資源的請求。
- 再通過類似Redis這樣的分布式緩存過濾請求
分層過濾的基本原則
- 對寫資料進行基于時間的合理分片，過濾掉過期的失效請求。
- 對寫請求做限流保護，将超出系統承載能力的請求過濾掉。
- 涉及到的讀資料不做強一緻性校驗，減少因為一緻性校驗産生瓶頸的問題。
- 對寫資料進行強一緻性校驗，隻保留最後有效的資料。
三、服務降級
1、什麼是服務降級
當伺服器壓力劇增的情況下，根據實際業務情況及流量，對一些服務和頁面有政策的不處理或換種簡單的方式處理，進而釋放伺服器資源以保證核心服務正常運作或高效運作。
整個架構整體的負載超出了預設的上限門檻值或即将到來的流量預計将會超過預設的門檻值時，為了保 證重要或基本的服務能正常運作，我們可以将一些 不重要 或 不緊急 的服務或任務進行服務的 延遲使用 或 暫停使用。
2、降級政策
當觸發服務降級後，新的交易再次到達時，我們該如何來處理這些請求呢？
從分布式,微服務架構全局的 視角來看，降級處理方案：
- 頁面降級 —— 可視化界面禁用點選按鈕、調整靜态頁面
- 延遲服務 —— 如定時任務延遲處理、消息入MQ後延遲處理
- 寫降級 —— 直接禁止相關寫操作的服務請求
- 讀降級 —— 直接禁止相關讀的服務請求
- 緩存降級 —— 使用緩存方式來降級部分讀頻繁的服務接口
針對後端代碼層面的降級處理政策，則我們通常使用以下幾種處理措施進行降級處理：
- 抛異常
- 傳回NULL
- 調用Mock資料
- 調用Fallback處理邏輯
3、分級降級
結合服務能否降級的優先原則，并根據台風預警（都屬于風暴預警）的等級進行參考設計，可将分布式服務架構的所有服務進行故障風暴等級劃分為以下四種：