最近給第三方做了乙個介面，介面的作用是接收資料對資料進行驗證之後通過kafka推送到模型進行資料處理，最終通過kafka接收模型的資料，開始只做了乙個非同步的介面，由於對方業務原因需要乙個同步的介面傳輸資料，但是每當執行一段時間之後程式就會進入假死狀態，介面無法正常呼叫；
同步介面的實現是使用阻塞map，當對方傳送請求時，對資料進行驗證，然後推送到模型，等待結果返回之後將處理好的資料推送到對方介面，此時這次請求給呼叫方返回相應資訊；
開始認為是由於使用者量過大導致記憶體不足引發的程式假死，使用jmeter進行壓力測試非同步介面模擬10000個請求同時呼叫介面，程式如絲滑般執行，沒有絲毫問題，所有請求都正常返回（這裡由於在家裡通過vpn連線的公司開發伺服器，網路不穩定，所以就拿少量測試用例為例）；
然後開始懷疑是不是同步介面出了問題，剛開始模擬少量請求，因為當時是在開發環境進行測試，模型並沒有放上去，所以沒有返回資訊，一直在等待模型的返回結果，也是沒有問題的，這時候呼叫非同步介面也沒有任何問題；
思考：所有資源都是阻塞狀態，因為沒有處理結果，一直沒有釋放程序，當資料過大時會不會造成伺服器資源耗盡，導致程式假死？當再次加大同步介面的呼叫次數的時候，再去嘗試請求非同步介面，發現非同步介面也沒有了返回資訊，這時遍確認了問題所在；
執行緒全部在阻塞狀態，當太多資源沒有釋放掉時，伺服器資源耗盡，導致程式無法正常執行；
找到問題之後就是要解決問題，去掉同步介面是不可能的，所以要給阻塞的執行緒設定乙個超時時間，當長時間沒有等到模型的處理資料時，主動放棄監聽，釋放掉占用的資源，從而保證伺服器資源充足；
雖然問題解決了，但是模型的資料產出最長達10秒鐘，當併發量過大時還是會出現這種問題，在不動模型的情況下如何解決這種問題？如何一直保證伺服器資源充足？
阻塞map的實現：
壓力測試簡介和jmeter的簡單實用：
Select 使用不當引發的core，你應該知道的
排查乙個宕機問題，搞了好幾天時間，最終確定原因 最終確定問題原因，在此分享一下 如下rip不正確，指令位址錯亂，棧資訊已破壞 在此基礎上準確定位非常困難，但是仍可發現一些線索 根據當前棧資訊，大概尋找到懷疑的函式 檢視整個棧上下資訊，看有無懷疑的函式 所以很有可能就是fetchnsaddrev函式導...
Select 使用不當引發的core，你應該知道的
排查乙個宕機問題，搞了好幾天時間，最終確定原因 最終確定問題原因，在此分享一下 如下rip不正確，指令位址錯亂，棧資訊已破壞 在此基礎上準確定位非常困難，但是仍可發現一些線索 根據當前棧資訊，大概尋找到懷疑的函式 檢視整個棧上下資訊，看有無懷疑的函式 所以很有可能就是fetchnsaddrev函式導...
記一次本地快取使用不當引發的一系列生產問題
專案基於spring cloud netfilx一套的微服務架構，大約有10來個微服務，每個服務都會用到一些基礎公用資料 類似於字典之類的 這份資料統一由基礎服務進行維護，每個服務要用到時通過rpc呼叫基礎服務獲取相關資料，為了減少rpc的呼叫於是就設計出一套本地快取方案，各個服務本地快取一套基礎公...