學習心得

本篇主要是思想總結，沒有技術幹貨，隻是一些底層知識的學習感觸。

神隐

在面臨一些海量資料處理的時候，計算機的處理速度也會很長，這可能導緻我們系統出現一段時間的不可用，或者表現在使用者端就是突然間的卡頓。

回想到之前學習過的架構也好，底層算法也罷。對于此類問題有個統一的解決思路-------拆分過程

這些東西目前在我腦海裡還很抽象，我盡量舉一些例子具象化。

redis中的hash結構，它有一個擴容機制，當負載因子達到一定數值，就會觸發hash的擴容，但是如果此時 hash 中的資料量已經非常大，擴容操作将會耗費大量的時間，此時redis會處于不可用的狀态（redis單線程處理用戶端請求），而redis則采用了 漸進性 rehash的方法。

• 先建立出擴容後的hash
• 然後慢慢的把舊hash中的資料往新hash這邊搬（搬一會兒，停下來做其他的事，然後又過來搬）

而反應到使用者這邊，我們并不知道，就好像使用者正在上課的老師，而redis就是在下面搞小動作的學生，老師轉過頭來，它就停止搞小動作，專心聽講，老師轉過去，它又搞小動作。

而在CMS垃圾回收器裡也有所展現，GC過程中是存在一個 STW的狀态，也就是所有使用者線程被暫停。而這個時間随着垃圾回收的用時增加而增加。

當STW的時間過長時，使用者這邊就會表現出系統卡頓的現象。而 CMS 也是以搞小動作的方式進行了時間拆分。

• 暫停一會兒，我GC一下
• 開啟使用者線程，跟我GC一起玩
• 再暫停一下，等我搞搞小動作
• 再開啟，跟我GC一起玩

或許我們本應該 STW 0.5秒，但是這樣一拆，假如每次就 0.1秒的暫停時間。使用者這邊卡頓現象就很微弱。

這樣把原本應該花費的時間進行拆分，而讓使用者根本感覺不到的操作。前人的思想值得敬佩，真·神隐之術。

拆東補西

雖然平時說拆東牆補西牆經常是作為貶義詞，但是運用在一些場景中，便是智慧。

尤其突出的就是并發問題中的 CAP 原理。我們隻能得其二，不能全都要。那這個時候就要考慮了，我們到底要什麼。是強一緻性？是高可用性？還是分區容錯性？

如果我們要保持強一緻性，那麼在很多場景下，直接加鎖，妥妥的線程安全。但是，并發數一上去，處理時間就大大延長，使用者得到回報的時間又大大增加，可用性大大降低。

凡事結合實際需求，今天是西牆那邊起風，那就該去補西牆。明天是東牆漏風，那就該去補東牆。

并發場景中處處展現均衡之道。