大促準備（五）壓測改造

壓測是準備大促過程當中相當重要的一個環節，在真正開始壓測以前系統一般要作必定的改造，以使得壓測請求的代碼執行路徑更符合實際狀況，主要進行的改造和準備主要有以下內容

一、存儲準備

對於壓測服務中涉及到db（msyql、hbase、ob）的系統，在壓測前須要聯繫DBA、PE先準備好所需的壓測表。
對於緩存（tair、tbase）也須要進行壓測緩存key和正式key區隔處理，能夠和zcache同窗確認其是否支持，若是不支持，就須要本身實現。另外緩存中壓測數據的過時時間能夠設置的短些，可以知足壓測的要求便可，以避免得壓測數據佔用過多的緩存空間，影響正常業務的緩存命中率(最好能經過drm推送的方式來修改)。

2.異步線程傳遞context

在不少系統中會使用線程池來執行異步操做或者是並行執行操做，而當前請求是否爲壓測請求的標識是在ThreadLocal中保存的，具體到sofa系統中是用AbstractLogContext來封裝實現的。於是在進入到異步線程中時須要把當前請求的context傳入到異步線程中，而且在異步線程中的執行中添加try finally語句塊，在finally中須要把異步線程中context清除掉，以避免線程池下次執行時形成context 污染。

3.緩存命中率改造

在進行壓測時，所使用的壓測數據是有限的，百萬級別的就算是比較大了，而壓測的請求量一般是每秒數萬或數十萬的量，於是會重複使用這些數據。對於會訪問緩存的請求，當循環一輪後這些數據基本上都會在緩存中了，若是此時仍然持續壓測，那基本上就只是壓緩存了，而不能壓到db操做和後續的do轉model等操做了。

於是應當可以控制必定比例的請求的強制走db，這個比例值應當是能夠動態調整的，經過調整這個比例也能夠了解本身系統db的qps峯值、本身系統所有走db狀況下服務的qps值。

4.邏輯改造

緩存命中率改造主要是針對讀服務，目的是使得壓測請求執行狀況儘可能符合真實狀況。對於寫服務也須要作相似的改造。

大多數的寫服務會進行冪等控制，會根據主鍵先到db中進行下查詢，若是查詢到數據，就再也不寫入db了，於是在進行寫服務壓測時，也須要進行適當的改造，以使得請求更符合真實狀況，主要的改造有兩種方式：

1. 主鍵數據足夠的隨機，避免發生重複，這樣能夠保證每次的數據都會寫db
2. 對於主鍵有必定規則要求，不能經過隨機數mock的，針對壓測流量，當db中已存在數據，執行一次update操做，修改一個不關鍵的屬性，好比更新時間等，也執行下db寫操做

5.鏈路切換改造

在大促中還有一種狀況是大促時執行的鏈路和平常的鏈路是不一樣的，對於鏈路的切換也須要添加對應的控制，可以經過推送配置進行切換。
更精確的控制的是壓測時進行的鏈路切換隻針對壓測請求生效而不對正常請求生效，在大促期間的鏈路切換對平常請求生效。要實現這樣的控制，在代碼的實現層面須要好好的設計，一方面要知足功能的實現，一方面還要具有良好的可讀性，減小後續的維護成本。

6.數據|請求錄製

前面提到的都是正常的壓測，這些壓測所採用的數據都是經過必定的規則mock出來的，可是對於有些特殊的場景，是不能用隨意mock出來的數據的，這時就必須把線上已有的數據或者請求錄製起來，經過重放的形式進行壓測。

這種狀況會變得特別複雜，須要開發特別的系統或者對已有的中間件進行改造才能夠實現。