這是一種典型的大併發訪問同乙個不存在的cache的情形，
因此對於可預先知道的快取，可以採取在程式啟動的時候就生成。
對於這種無法預知key的，以論壇帖子列表為例，可以採取兩種策略，
1.第乙個發現cache中沒有快取物件時，先放入乙個空的臨時物件，
比如返回list，可以先生成乙個長度為0的arraylist,同時將生成快取的操作放到佇列中或者由當前執行緒完成，再將生成的資料替換剛才的臨時快取物件。
這種做法的缺點是，如果生成快取的時間較長，那麼會有一部分請求得到的不是實際資料，影響部分使用者體驗。且如果當前生成快取的時候出現異常，需要等剛才的臨時快取失效之後，才會再次觸發生成快取的請求。
優點是編寫**簡單，即使該快取永遠無法生成，也不會出發太多的生成快取的操作。
不怕使用者惡意請求來產生過多的無法命中的快取。
屬於犧牲少量使用者體驗來保障系統的穩定的做法。主要用於重要性較低的業務。
2.用申請鎖的方式將生成快取的操作以同步方式進行，
優點是基本不會出現取到方法1中的那種臨時快取，
缺點是，**編寫稍複雜，生成快取操作耗時太久或出現問題，或者網路故障等其它原因導致該快取永遠無法生成的時候，
那麼每次呼叫過讀取該快取的請求，都將被拖住，嚴重的時候整個伺服器執行緒佔滿被拖垮。
一旦使用者惡意請求導致快取無法名字，伺服器很容易被搞掛。
根據實際業務選擇吧。
大併發量需要注意的問題
程式在有很複雜的邏輯且資料量大的情況，大多數優化方案可以選擇多執行緒，加大併發量，這樣可以顯著提高程式執行的速度。但是最近在 開發的過程中遇到乙個問題，程式的併發量上去了，但是速度仍然沒有提高，經過分析，是由於大量的併發都會修改某一張表的同一行資料，導致資料庫行鎖等待，進而影響程式執行的速度。程式邏...
請求大資料量介面時手動分頁
前段時間做專案遇到這麼種情況，需要呼叫乙個批量查詢介面，get請求的 比如根據使用者id批量查詢使用者資訊的，介面提供方提供的就是get請求的，然而我們一次要查詢幾萬個使用者，這樣請求的結果就是介面直接掛掉，因為get請求沒法傳遞那麼多資料，最後的解決方案是人為地進行分頁 private listq...
表資料量較多及併發量較大時，如何修改表結構
現在假設乙個場景 假設乙個系統已經執行一段時間，資料量已經很大，這時候系統公升級，有張表需要增加個字段，但是併發量白天晚上都很大，請問怎麼修改表結構？修改表結構會導致表鎖，資料量大修改資料很長，導致大量使用者阻塞，無法訪問該如何解決？首先建立乙個和你要執行的alter操作的表一樣的空的表結構。執行我...