寫部落格的時間比較少，所以今天一下寫兩篇，這篇先寫個大概，後面再慢慢補全。
問題排查：
解決方案：
1.增加客流服務例項。
2.每個例項開啟2個執行緒消費資料
3.優化業務邏輯。
經過優化後，每條訊息處理速度為180-190ms，提公升了4倍左右，等晚上公升級上線，成功消費掉了堆積資料，後續到現在並沒有出現效能瓶頸。
其實這裡的優化處理很常規，後面再有客戶接入大量客流裝置的時候，也不能每次都單純的靠加伺服器去解決，後來我考慮到了另乙個服務治理框架dubbo，dubbo服務間是使用rpc協議通訊，而目前我們的專案是使用的spring cloud，服務間通訊是feign的偽rpc通訊，實際上還是http通訊。並且考慮到我們的專案處理客流資料最大的瓶頸就是服務間通訊的耗時，所以我個人覺得此處有兩種修改方式，第一種方案是非常適合改為rpc通訊，整合rpc通訊框架，優化效能。第二種方案是對請求結果做快取。不過目前向上面反應了優化方案，看起來積極性不高，所以後面有時間我會在自己的專案上搭建乙個試一下，這個才是我覺得這次問題處理收穫最大的地方。
一次優化記錄
備註 由於隱私 部分使用了偽 偽sql 直接查十點查全部 select from 使用者優惠券表 where 優惠券id in select id from 優惠券表 where 限制 新使用者 and 90天內 總時間40 秒 這裡用exlpain分析 優惠券id是有索引的，但是實際上沒有走索引。...
一次優化記錄
今天收到乙個同事的求助，說有乙個sql跑了乙個多小時沒有結果。我看了看，這個sql是這樣的 隱藏了敏感資訊 select 號碼,列2,列3,max starttime flag from 表1 t1 where flag 0 and 號碼 not in select 號碼 from 表2 t2 gr...
記錄一次效能優化
做了這麼久開發，終於涉及到效能優化了 原因是開啟乙個頁面花了2 6秒，被提了bug 不得不說自己有點小白，嘗試了非同步執行緒和把單次的dubbo查詢優化成批量的查詢。但是這兩種嘗試都沒有宣告成功 出了問題首先要找到問題在 既然是耗時，那就要看看到底 耗時最多 這裡要說一下，因為我是改別人的 所以對業...