壓測是準備大促過程中至關重要的一個環節，在真正開始壓測之前系統通常要做一定的改造，以使得壓測請求的代碼執行路徑更符合實際情況，主要進行的改造和準備主要有如下內容
1、存儲準備
對於壓測服務中涉及到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了，因而在進行寫服務壓測時，也需要進行適當的改造，以使得請求更符合真實情況，主要的改造有兩種方式：
- 主鍵數據足夠的隨機，避免發生重複，這樣可以保證每次的數據都會寫db
- 對於主鍵有一定規則要求，不能通過隨機數mock的，針對壓測流量，當db中已存在數據，執行一次update操作，修改一個不關鍵的屬性，比如更新時間等，也執行下db寫操作
5.鏈路切換改造
在大促中還有一種情況是大促時執行的鏈路和日常的鏈路是不同的，對於鏈路的切換也需要添加對應的控制，能夠通過推送配置進行切換。
更精確的控制的是壓測時進行的鏈路切換隻針對壓測請求生效而不對正常請求生效，在大促期間的鏈路切換對日常請求生效。要實現這樣的控制，在代碼的實現層面需要好好的設計，一方面要滿足功能的實現，一方面還要具備良好的可讀性，減少後續的維護成本。
6.數據|請求錄製
前面提到的都是正常的壓測，這些壓測所採用的數據都是通過一定的規則mock出來的，但是對於有些特殊的場景，是不能用隨意mock出來的數據的，這時就必須把線上已有的數據或者請求錄製起來，通過重放的形式進行壓測。
這種情況會變得特別複雜，需要開發特別的系統或者對已有的中間件進行改造纔可以實現。