大家都知道，高併發系統有三把斧子：快取、熔斷和限流。但還有一把斧子，經常被遺忘在角落裡，鬱鬱不得志，那就是預熱。
先說兩個現象。這些現象，只能在併發高的系統**現。
好吧，它已經引起了多個故障。
乙個高併發環境下的db，程序死亡後進行重啟。由於業務處在高峰期間，上游的負載均衡策略發生了重分配。剛剛啟動的db瞬間接受了1/3的流量，然後load瘋狂飆公升，直至再無響應。
原因就是：新啟動的db，各種cache並沒有準備完畢，系統狀態與正常執行時截然不同。可能平常1/10的量，就能夠把它帶入死亡。
另外乙個常見的問題是：我的一台伺服器發生了問題，由於負載均衡的作用，剩下的機器立馬承載了這些請求，執行的很好。當服務重新加入集群時，卻發生了大量高耗時的請求，在請求量高的情況下，甚至大批大批的失敗。
引起的原因大概可以歸結於：
（1）服務啟動後，jvm並未完全準備完畢，jit未編譯等。
（2）應用程式使用的各種資源未準備就緒。
（3）負載均衡發生了rebalance。
這兩個問題，都是沒有做好預熱
warm up，即冷啟動/預熱的方式。當系統長期處於低水位的情況下，流量突然增加時，直接把系統拉公升到高水位可能瞬間把系統壓垮。通過"冷啟動"，讓通過的流量緩慢增加，在一定時間內逐漸增加到閾值上限，給冷系統乙個預熱的時間，避免冷系統被壓垮。
我想要這樣的曲線。
流量是不可**的，這不同於自然增長的流量，或者人為的***----這是乙個從無到有的過程。甚至一些自詡超高速的元件，如lmax的disruptor，在這種突然到來的洪峰之下也會崩潰。
warmup最合適的切入層面就是閘道器。如圖：node4是剛啟動的節點，整合在閘道器中的負載均衡元件，將能夠識別出這台剛加入的例項，然後逐步放量到這台機器，直到它能夠真正承受高速流量。
假如所有的請求，都經過閘道器，一切都好辦的多，也有像sentinel 之類的元件進行切入。但現實情況往往不能滿足條件。比如：
（1）你的應用直接獲取了註冊中心的資訊，然後在客戶端元件中進行了流量分配。
（2）你的應用通過了一些複雜的中介軟體和路由規則，最終定位到某一台db上。
（3）你的終端，可能通過了mqtt協議，直接連上了mqtt服務端。
我們進行一下抽象，可以看到：所有這些流量分配邏輯，包括閘道器，都可以叫做客戶端。即所有的warmup邏輯都是放在客戶端的，它們都與負載均衡緊密耦合在一起。
按照以上的分析，通過編碼手段控制住所有的客戶端呼叫，即可解決問題。
乙個簡單的輪詢方式
（1）我要能拿到所有要呼叫資源的集合，以及啟動時間，冷啟動的配置等。
（2）給這些資源分配一些權重，比如最大權重為100，配置100秒之後冷啟動成功。假如現在是第15秒，則總權重就是100*(n-1)+15。
（3）根據算好的權重，進行分配，流量會根據時間流逝逐步增加，直到與其他節點等同。
（4）乙個極端情況，我的後端只有1個例項，根本就啟動不起來。
拿springcloud來說，我們就要改變這些元件的行為。
（1）ribbon的負載均衡策略。
（2）閘道器的負載均衡策略。
還好，它們都是基礎元件，不用來回拷貝**了。
顧名思義，意思就是把所有的介面都提前訪問一遍，讓系統對資源進行提前準備。 比如，遍歷所有的http連線，然後傳送請求。 這種方法是部分有效的，一些懶載入的資源會在這個階段陸續載入進來，但不是全部。 jit等一些增強功能，可能使得預熱過程變得非常的長，走馬觀花的方式，只能在一定程度上有作用。
再比如某些db，在啟動之後，會執行一些非常有特點的sql，使得pagecache裡載入到最需要的熱資料。
系統在死亡時做乙個快照，然後在啟動時，原封不動的還原回來。
這個過程就比較魔幻了，因為一般的非正常關閉，系統根本沒有機會發表遺言，所以只能定時的，在執行中的系統中做快照。
節點在啟動時，再將快照載入到記憶體中。這在一些記憶體型的元件中應用廣泛。
通過比較，我們發現，最靠譜的方式還是進行編碼，將warmup邏輯整合在客戶端。這個工作可能是痛苦的、漫長的，但結局是美好的。
當然也可以通過「摘除nginx->修改權重->reload nginx」的方式。有時很有效但不總是有效，通常很放心但不總是放心。
一切隨你。畢竟沒有前戲直奔主題，那叫魯莽。
高併發 高可用
高併發 提高系統併發能力的方法主要有兩種 前者垂直擴充套件可以通過提公升單機硬體效能，或者提公升單機架構效能，來提高併發性，但單機效能總是有極限的，網際網路分布式架構設計高併發終極解決方案還是後者 水平擴充套件。網際網路分層架構中，各層次水平擴充套件的實踐又有所不同 1 反向 層可以通過 dns輪詢...
高併發 高併發測試筆記
問 高併發測試 一般你們用什麼工具來模擬 10萬級別的客戶端併發？在普通的電腦上可以模擬嗎 10萬併發需要至少10萬的套接字，套接字在核心中占用記憶體100000 6k 2 1g記憶體，系統需要能夠開啟10w個fd。一般的系統能夠能模擬 問 預設每個程序只能開1024個fd，修改後最大可以10w，那...
併發與高併發（二十）高併發 應用拆分思路
這一章節我們將講解高併發解決方案中的應用拆分思路，也可以稱之為系統拆分。單個伺服器再優化，它的處理都是有上限的，因此我們採用擴容 快取 訊息佇列等對程式進行優化，這些手段都可行，但還不是全部。隨著專案的需求要求越來越多，應用自然會跟著越來越大，因此呢，架構師設計出了特別容易擴充套件的方案，從整體將乙...