【后端】設計高並發場景下的高可用后端系統

本文轉載自查看原文 2017-03-08 14:57 1353

PS：前段時間和Mentor們一起參與研發”百度地圖百城千店感恩節AR游戲送大禮”的后端項目，積累了一些高並發情景下的系統設計經驗，這里統一抽象成【秒殺情景下的后端系統】，歸納總結一下學習到的知識點。

轉載地址：http://blog.daijiale.cn/2016/12/07/%E3%80%90%E5%90%8E%E7%AB%AF%E3%80%91%E8%AE%BE%E8%AE%A1%E9%AB%98%E5%B9%B6%E5%8F%91%E5%9C%BA%E6%99%AF%E4%B8%8B%E7%9A%84%E5%90%8E%E7%AB%AF%E7%B3%BB%E7%BB%9F/?utm_source=tuicool&utm_medium=referral

背景

為什么要構建一個高並發場景下的后端系統？

技術角度：業務規模覆蓋用戶群大，數據聯通實時性強，響應時間要求極短，需要高可用，高並發。
市場角度：用戶體驗、曝光度、促銷（秒殺）等。

簡而言之，就是讓自己編寫的系統應用做到如何更優雅的”接客”。

好，現在我們來看看，如何用正確的”姿勢”來”接客”？

設計思路

設計層面需要考慮的Points

Point1:靜態頁面設計

cdn托管
網址隱藏
頁面壓縮
緩存機制

Point2:動態頁面設計

隊列設置
樂觀鎖（利用redis原子操作實現）
異步調用
資質搶購

Point3:高可用（雙活）

雙活：讓主備兩個數據中心都同時承擔用戶的業務，此時，主備兩個數據中心互為備份，並且進行實時備份，尤其是在緩存層和DB層。

Point4:高並發（負載均衡，安全過濾）

負載均衡：分軟件層、硬件層、鏈路層，但不管哪一層，主要有兩種通用常用技術思路：第一種是將大量的同時發送的數據流在多個節點上進行處理。第二種是將單一負載的大量分擔在多個節點上進行並行處理，並且在所有節點都完成處理后將結果合並起來輸出給用戶。而現在，負載均衡技術已經不是什么新鮮技術，一般維護過服務器，或有兩台以上的服務器都可以使用負載均衡技術。

安全過濾：設置比較完備的rules過濾器。

Point5: 數據庫設計注意靜態配置和動態數據分離

靜態配置：在前端頁面主要呈現內容為主，在接口層主要只讀的數據字段。

動態數據：頻繁更新，頻繁檢索的數據字段。

Point6：緩存雪崩

注意設置緩存失效時間，不然超出redis緩存最大內存，溢出講導致雪崩。

Point7：緩存擊穿

注意設置緩存失效時間的隨機性，別同一時間同時失效，瞬間同時失效將導致密集的IO讀寫操作，容易導致緩存擊穿。

Point8:脫離原站點部署

簡而言之就是：千萬不要把雞蛋放在一個籃子里！！！

分業務分布式部署

定義：一個業務分拆成多個子業務，部署在不同的服務器上。
好處：強調機器間的協作，其重點是任務可拆分，如：某個任務需要一個機器運行10個小時，將該該任務用10台機器的分布式跑，可能2個小時就跑完了。（子任務之間有依賴關系）。
壞處：中心化帶來的主要問題是可靠性，若中心節點宕機則整個系統不可用，分布式除了解決部分中心化問題，也傾向於分散負載，但分布式會帶來很多的其他問題，最主要的就是一致性。

分容器分布式部署

定義：俗稱”集群”，同一個業務，部署在多個服務器容器上。為的
好處：同一個業務部署在多台機器上，提高系統可用性。如：某個任務需要一個機器運行10個小時，那任務放到處理該任務的集群上還是需要10個小時。假如有10個這樣的任務，放到同一個集群上，仍然需要10個小時，但是由於掛載的機器來自不同地域節點，可以提升帶寬上的物理傳輸速度，一台服務器垮了，其它的服務器可以頂上來。
壞處：整體性能難得到顯著得提升，受業務內極端需求峰值限制。

PS： “沒有最好的方式，只有最適合的方式”，不同的業務場景需求，不同的模塊：數據庫、緩存、消息中間件、媒體資源、系統應用等，需要選用不同的部署方案才能達到高可用，當然，一般更建議兩種方式組合部署。