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： “沒有最好的方式，只有最適合的方式”，不同的業務場景需求，不同的模組：資料庫、快取、訊息中介軟體、媒體資源、系統應用等，需要選用不同的部署方案才能達到高可用，當然，一般更建議兩種方式組合部署。

Point9:監控+監控+監控（總要事情說三遍！）

系統研發完成，測試通過並不代表就結束了，一個高併發系統最關鍵的時期往往是在活動的峰值期間，為了不讓RD們24小時目不轉睛地盯著所有可能出現問題的地方，最好在關鍵處加上異常監控資訊，以便及時對異常事件做出響應。

這裡介紹兩個開源監控專案：

大廠的成熟解決方案

• 在百度的解決方案：百度雲、opcode快取、BigPipe、BDRP（RedisV3）叢集、ORP叢集、CDN分流,hiphoto等更大的雲實例。

• 從阿里同學那得知的一些那邊的解決方案：活用阿里雲服務，譬如雲監控、雲盾、ECS、OSS、RDS、CDN分流，這些大都已經是面向大眾的商業產品。

個人開發者/創業公司的解決方案

回頭單開一篇文章介紹，留個傳送門。

研發策略

一、認清業務的環境、形式

• 使用者緯度：超大量，正常使用者/惡意使用者。
• 地域：全國各地。
• 業務流程：
  • 【前臺】卡券、獎品展示，領用登記等。
    • 【後臺】資料接入、資料處理、資料同步、資料錄入、庫存管理。

通用的業務場景如下：

二、分析業務的狀態

商品/獎品展示層

• 商品/獎品展示：秒殺倒計時頁面。
• 秒殺進行中：點選進入秒殺頁面。
• 秒殺活動結束：提示活動已結束。

技術細節

頁面/伺服器優化，依賴包cdn網路加速部署，隱藏跳轉頁面，狀態切換（sh指令碼設定定時任務實現）,這裡就不擴充套件了，現在應對大型Web系統的成熟前端頁面技術棧特別多。

使用者登記層

• 秒殺進行中：秒殺登記頁面。
• 秒殺結束了：秒殺結束頁面。
  

技術細節

token加/解密（加密協議自己擬訂）

ajax跨域（常用jsonp）

資料接入層

• 資料校驗：完成對資料、使用者驗證（安全和速度均要考慮）。
• 存入nosql訊息佇列：去重/排序/快取/檢索資料。
• 檢測商品最大數量：提示活動已結束。

簡而言之：就是”一言不合就反饋，功成名就須盡人皆知”。

技術細節

資料校驗

存入nosql訊息佇列

資料處理層

• 資料持久化：轉存nosql資料到mysql資料庫，主要為dao層DB操作。
• DB優化：DB分表，DB表擴充套件，DB遷移。
• 轉存：sql轉存，匯出excel列印稽核。

技術細節

三、根據狀態進行程式碼模組層面的設計

四、全量的壓力測試

簡而言之：正式表演前，請務必帶裝彩排一輪