背景
隨着流量增長,服務的節點越來越多,對服務性能要求也越來越大,在服務啓動時經常會發現存在抖動,針對這些服務抖動,就需要採取一些預測措施,下面就簡單介紹下系統相關的服務預熱、中間件預熱、數據庫預熱等
預熱場景
服務預熱
在《springcloud線上發佈超時》系列文章中已經描述了一些微服務需要預熱的服務資源,
- 連接池
- 線程池
- 限流池
- grpc連接
- jit
池資源相關預熱我這裏就不描述了,參考我的發佈預熱系列文章:springcloud線上發佈超時
這裏說一下jit,網上有兩種方案,
方案一 定製化jdk
將jit過程信息保存到文件中,下次發佈時自動加載,成熟方案是阿里的jwarmup,已經集成到阿里的jdk中,有興趣的可以瞭解下
方案二 跑測試用例預熱
一般都是採用測試用例預熱,如果僅僅是jdk預熱,可以直接跑幾個測試用例循環n次就行,但是如果涉及到中間件預熱,這裏就可能不滿足需求了。 我現在就是採用流量錄製以及回放預熱,如下圖:
方案三 定製路由策略,通過tag配置來路由
這裏的方案就是需要定製化路由策略,剛啓動的服務註冊時帶上一些配置信息,網關或者服務調用段獲取到配置後來根據配置來路由,先路由少量流量,慢慢增加直到路由100%,這樣可以達到針對jit的預熱效果
中間件預熱
redis預熱
先在很多服務爲了提高吞吐量而使用redis,這就會導致服務啓動後或者redis數據丟失後,會導致請求都打到db中去,從而導致db壓力倍增,這就是常見的redis雪崩。
CDN預熱
CDN經常是也承擔了入口緩存,那麼這裏也會需要預熱,可以錄製生產流量回放來達到預熱效果。
mysql預熱
mysql重啓後十幾分鐘的性能是非常差的,原因是因爲InnoDB有innodb buffer pool,詳細可以參考該鏈接:https://blog.csdn.net/u014236541/article/details/79870670