大促系統全流量壓測及穩定性保證

應對突發的峰值訪問，高壓下的架構演進（數據）

京東商城數據流向：

• 訂單生成前，包括單品頁，購物車，架構，促銷等功能，我們每個用戶進來需要訪問。它的特點是大促期間訪問量非常大
• 訂單預處理，訂單生成之后，這是一個原始生成單，之后需要對訂單進行預處理，進行拆包，包裹的拆分、大家電小家電拆開包裹運送等。因為是統一下單，這一塊是訂單預處理。挑戰是訪問量大，各個模塊如拆單、訂單轉移，支付臺帳等可能會承受非常大的壓力，我們會采取擴容存儲，限流，數據結構優化等方法去應對。
• 訂單履約階段，真正到后面是整個處理過程，配送黏合起來做的系統。這是京東商城的服務結構。

交易系統的三層結構

上面是調用來源，中間是我們的服務，下面是依賴的底層服務。其中強依賴服務是關鍵路徑所需要調用的服務，是主流程中不可缺少的一部分。

強依賴服務在大促期間不能被降級，我們需要提前擴容，以及進行代碼重構、拆分、按來源單獨部署等方法提前進行優化。

交易系統的訪問特征

購物車：結算頁：產生訂單頁面訪問的比例是 16 ：4 ：1。每天 PV 就是幾十億，幾百億、上千億，因此我看到最大的量 1 分鐘是幾千萬。

全鏈路全流量線上壓測

系統會有很多的變更，數據變更或者是代碼變更結構變更都會產生，我們知道這個系統能夠承受多大量，上來對它進行壓測。

壓測分為線上壓測、線下壓測，主力做線上壓測。（下壓測，環境跟線上不一樣，路由器和機器 CPU，物理機，每一個不相同或者架設的路由超過 3 層，丟包，各種數據不一樣，壓測出來的數據經常會差異。）

壓測方法：

• 演練縮減服務器：把集群機器逐臺往下縮減，真正看到線上量能扛到什么情況。
• 復制流量：主要通過 TCPCopy 復制端口流量，多層翻倍放大流量。
• 模擬流量：非常簡單的底層工具去做壓測。用壓測平臺，把這些工具集成起來做模擬流量壓測。
• 流量泄洪：把訂單在這個結構，接住堵在這個地方不往下放，往后拽都是密集的一些服務。從這一塊把量堵住，堵幾十萬，突然有一天打開，看到一個峰值，看每一分鐘處理量，往后能承受多大量，是不是能夠承受發起的量。

根據壓力表現進行調優：

• 多級緩存：逐級做緩存，前面做一些靜態緩存掉，后面會做一些基礎數據緩存，最后大數據，一層一層往上能擋住整個這一塊，
• 善用異步：異步雙寫，會寫丟數據，寫丟沒關系，購物車是整體的，加一個商品，寫不過來，下次過來又會全覆蓋。這樣購物車就有一個多機房多活的可用性。
• 超熱數據的緩存：利用 Queue 的原理，不斷往里塞 SKU
• 數據壓縮：對 Redis 存儲的數據進行壓縮，這樣空間又縮小四分之一或是三分之一，數據到后面就會很小。當量小之后，訪問效率就會升高，數據量彈出很小，丟單率很小，可以提高可用性。

轉載于:https://www.cnblogs.com/luohaochi/p/11054242.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的软件架构阅读笔记11的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。