專案基於spring cloud netfilx一套的微服務架構，大約有10來個微服務，每個服務都會用到一些基礎公用資料（類似於字典之類的），這份資料統一由基礎服務進行維護，每個服務要用到時通過rpc呼叫基礎服務獲取相關資料，為了減少rpc的呼叫於是就設計出一套本地快取方案，各個服務本地快取一套基礎公用資料，但是為了保證本地快取資料與基礎服務的一致性，就需要定時的進行同步，並且每次服務重啟後，還需要全量拉取一次。
背景介紹完了，接下來說一下問題，基於這套方案，目前每次同步或者全量拉取時都會造成記憶體和cpu持續告警。
1、因為一次性拉取的資料太大了（幾百m），所有服務全部向基礎服務請求，基礎服務奄奄一息。
2、各自服務拉回資料後，會發生大量的json解析，造成cpu告警。
3、各自服務需要把資料在各自集群中進行同步傳輸，又造成二次傷害。
4、一次性拉回的資料瞬間佔據雙倍記憶體，容易導致fgc。
問題本身解決起來非常簡單，換redis完事，但是受實際專案約束，要想一次性把所有服務的本地快取都替換掉，也是挺麻煩的，但是問題又迫在眉睫，所以基於綜合考慮，決定先解燃眉之急，再做長遠打算。
1、拆分
把一次性拉取拆分成多次小資料量拉取
2、服務交錯拉取
各個服務把同步的時間錯開，避免同時請求。
3、控制全量同步
取消所有服務重啟即拉取的方式，而是通過介面呼叫，手動控制。
通過上述改進方式，可以暫時緩解當前問題，並且容易實施，風險較小。
但是最終要徹底解決這個問題，就是去掉本地快取的方式，而是採用快取中介軟體，比如redis，既減少了記憶體的浪費，又避免了全量同步和實時同步的麻煩。
這個問題產生的原因還是因為技術上選型的錯誤，對於使用本地快取考慮不足造成的，對於一些占用較大記憶體的資料不應該設計成本地快取，否則無論是對於記憶體的管理、快取的一致性都會帶來一些困擾，比如本文中遇到的這些問題。
記錄一次由於執行緒使用不當引發的血案
最近給第三方做了乙個介面，介面的作用是接收資料對資料進行驗證之後通過kafka推送到模型進行資料處理，最終通過kafka接收模型的資料，開始只做了乙個非同步的介面，由於對方業務原因需要乙個同步的介面傳輸資料，但是每當執行一段時間之後程式就會進入假死狀態，介面無法正常呼叫 同步介面的實現是使用阻塞ma...
Select 使用不當引發的core，你應該知道的
排查乙個宕機問題，搞了好幾天時間，最終確定原因 最終確定問題原因，在此分享一下 如下rip不正確，指令位址錯亂，棧資訊已破壞 在此基礎上準確定位非常困難，但是仍可發現一些線索 根據當前棧資訊，大概尋找到懷疑的函式 檢視整個棧上下資訊，看有無懷疑的函式 所以很有可能就是fetchnsaddrev函式導...
Select 使用不當引發的core，你應該知道的
排查乙個宕機問題，搞了好幾天時間，最終確定原因 最終確定問題原因，在此分享一下 如下rip不正確，指令位址錯亂，棧資訊已破壞 在此基礎上準確定位非常困難，但是仍可發現一些線索 根據當前棧資訊，大概尋找到懷疑的函式 檢視整個棧上下資訊，看有無懷疑的函式 所以很有可能就是fetchnsaddrev函式導...