通常，功能上線之前，壓測是必不可少的，可以從以下幾個點進行優化 ：
1、redis連線數、大key(hash key)。但凡用到執行緒池的地方，都是有優化空間的，合理設定執行緒池引數可以提高吞吐量。這些引數的設定是經過很多次的壓測調整再壓測這樣試出來的；
2、dubbo執行緒數、超時時間等；
3、記憶體快取。如果分布式快取還是不夠快的話，可以增加記憶體快取，springboot支援很多記憶體快取框架的。事實上，一般都是要加記憶體快取的，不然tps上不去。加了記憶體快取以後，記憶體快取的重新整理就成為了乙個新問題，一般可以採用定時任務重新整理、mq訊息通知、zk監聽等方式；
4、mysql讀寫分離就不用說了，連線數、索引等等，一般問題不大。因為，大部分的應用是讀多寫少；多說一句，其實有一些資料也可以考慮非同步批量寫入mysql；
5、不同業務之間要進行隔離。最常見的是，一台機器上只部署乙個服務，這樣可以減小受其它服務的影響。但有時候，這樣也不夠，比如限時搶購、直播商品等，就是某些商品的訪問量非常大，而其它大部分商品的訪問量小，雖然可能同屬商品服務，但是其它商品還是會受到這些熱點商品的影響，這種情況下建議把這些熱點商品單獨拿出來放到乙個地方，比如，我們提前把這些商品放到乙個單獨的redis中。做多了之後呢，可以把這種業務場景單獨抽取成乙個服務；
6、能非同步就絕不同步。如果有些操作可以非同步執行的話就非同步執行吧，都同步操作那誰受得了啊。比如，直播間中的彈幕、聊天訊息、禮物等等，都可以通過mq做成非同步的；
7、加機器。通過增加服務的數量可以提高服務的吞吐量，最好是自動（彈性）擴縮容的，畢竟伺服器是要錢的；
8、不必要的日誌少打一點兒。日誌畢竟是要寫到磁碟上的，當然一般影響不大，但是如果實在沒辦法可以試試這一招，日誌太多會占用磁碟io；
最重要的是，多壓測，找出系統瓶頸，並加以優化，通過壓測可以找到各項引數的最佳值。這個時候，監控就顯得尤為重要，各個元件的監控，各種維度的監控，越詳細越好。
隔離，一定要隔離，業務隔離，避免相互影響，斷路器
監控和告警，出現問題可以第一時間發出告警和通知
pinpoint是乙個很有用的工具，可以每乙個請求在每一步花費的時間
qps：queries per second，意思是「每秒查詢率」。是一台伺服器每秒能夠響應的查詢次數，是對乙個特定的查詢伺服器在規定時間內所處理流量多少的衡量標準。
tps：transactions per second，意思是每秒事務數。乙個事務是指乙個客戶機向伺服器傳送請求然後伺服器做出反應的過程。客戶機在傳送請求時開始計時，收到伺服器響應後結束計時，以此來計算使用的時間和完成的事務個數。tps是衡量系統效能的乙個非常重要的指標。
顯然，qps不能描述增刪改，因此tps才能更好反應服務的吞吐量。
如果沒有定義事務，會把每個請求作為乙個事務。
如果是對乙個介面（單場景）壓測，且這個介面內部不會再去請求其它介面，那麼tps等於qps，否則，tps不等於qps。
如果是對多個介面（混合場景）壓測，不加事務控制器，jmeter會統計每個介面的tps，而混合場景是要測試這個場景的tps，顯然這樣得不到混合場景的tps，所以，要加了事物控制器，結果才是整個場景的tps。
在jmeter聚合報告中，throughput是用來衡量請求的吞吐量，也就是tps，tps=樣本數/執行時間。
開關，涉及老資料的功能，上線之前不妨加個開關，比如opensearch切換程elasticsearch等，有了開關就可以在必要的時候（出現問題的時候）手動切回去
hashmap是無序的，linkedhashmap是有序的
修資料、遷移資料方案：
1、資料量少的話，寫個程式跑一下就好；
2、資料量大的話，建議用mq，寫乙個生產者程式讀資料，啟動多個消費者寫資料。
採用mq方式有兩個好處：
（1）消費者越多，處理速度越快，這比乙個程式裡啟多個執行緒來處理要強得多；
（2）一旦出錯，資料仍然在佇列中。否則，你就要扒日誌去找哪些處理失敗了，當然也可以記錄到表中，回頭再重新執行一遍；
重要的業務要加強**review，review要及時，可以先用**規範外掛程式掃一遍，bug永遠出在最意想不到的地方，老司機也可能翻車，
索引、預設值等不必再說，無論mysql還是mongodb
少自己造輪子，多用開源的工具類和開源的解決方案，hutool了解一下
多用stream，多用parallelstream，不過一定要注意用法和場景
多關注線上異常，及時清理線上異常
多關注系統效能，多看看系統監控，阿里雲，自定義的grafana，反正多看看監控，可以及早發現問題，重點是領導一般不會關注具體功能實現，而關注的是資料
人與人之間是有能量場的，誰的能量強，氣場就強，能量小的人就被比下去了
多表現自己，高調做事，低調做人
db2效能問題排查與優化
最近在做公司產品的排查性穩定性測試中，遇到乙個小問題。在更換的資料初時化資料後，由加壓機鏈結應用伺服器變的非常緩慢。由此，判斷為以下幾種情況，再在與研發一起分析完was6.0的伺服器日誌後，決定對db2引數進行調整。1 情況一 區域網資料報傳輸問題，經過對區域網內包的監控沒有發現異常情況排除情況一。...
flip close Oops問題排查
1 問題描述 oops 1 cpu 0 0 00000000 00000001 64206e6f 838ceae0 4 838ceae0 83816140 00000001 00000007 8 0000080f 00000004 00000020 83934668 12 82fdb128 ffff...
404問題排查
當tomcat沒有日誌的時候，不一定訪問沒有到達tomcat 我們可以通過web.xml中的filter來攔截請求，把斷點打到第乙個filter smartfilterdispatcher 上，確定請求，然後檢視問題在 resource name add cust topic destination...