[故障公告] 13:52-14:03，訪問量突增，博客web服務器CPU 100%

13:52-14:03，因爲訪問量突增，博客web服務器全線CPU 100%，形成博客站點不正常訪問，由此給您帶來麻煩，請您諒解。

爲了迎接訪問量的增加給web服務器CPU帶來的巨大壓力，上週咱們已經將博客web服務器換成了阿里雲獨享型服務器。

今天下午故障前，博客站點一共投用了3臺4核8G+1臺8核8G阿里雲服務器。

13:50左右，爲了防止4臺服務器撐不住，咱們使用阿里雲的彈性伸縮服務，建立了一個根據CPU佔用狀況自動增長服務器的「報警任務」。

哪知剛建立完，訪問量就突增上去了，負載均衡中有1-2服務器出現CPU 100%。因爲彈性伸縮服務的「報警任務」剛建立，須要一些時間蒐集數據，還沒啓動。即便啓動，也須要2分鐘蒐集CPU報警信息。因而，咱們趕忙建立彈性伸縮服務的定時任務增長服務器。

定時任務啓動後，雖然增長服務器是自動進行的，但建立服務器、啓動服務器、配置數據庫訪問控制、掛上負載均衡這些操做須要一些時間。

在等待增長服務器期間，CPU 100%問題如雪崩般。1臺服務器出現CPU 100%必定時間，負載均衡健康檢查失敗，將這臺服務器踢出。在一樣的訪問量下，負載均衡中的服務器變少了，這時CPU 100%更嚴重，更多的服務器CPU 100%，而後一臺一臺被踢出，直到剩下最後1臺。根據阿里雲負載均衡健康檢查的策略，若是隻剩下1臺，即便健康檢查失敗，也不會踢出。但這時最後1臺是否被踢出已經可有可無，由於這臺服務器的CPU根本頂不住，一直100%，博客站點訪問全線503。

這時好想有一個緊急按鈕——「中止健康檢查，全部服務器給我硬撐，撐得住繼續撐，撐不住也要繼續撐」，若是真有這樣的按鈕，負載均衡中只會有部分服務器CPU 100%，不至於全線503，能夠支撐到新增的服務器上線。

可是沒有這樣的緊急按鈕，咱們只能眼看着全線503，乾等新增的服務器上線。。。

新增服務器上線後，博客站點很快恢復了正常。