問題的發現過程是這樣的，一些硬體裝置上傳的實時裝置資訊客戶端不能展現，於是查詢日誌，發現資料時間延遲非常嚴重，後台邏輯把這些資料當作過期資料扔掉了，所以沒有進入實時資料的服務（此服務是單獨部署的）。
於是開始查問題，難道原始資料就是過期的？鑑於北京的霧霾天可能對北斗（ps：我們主要是裝置的北斗位置資料）產生影響，所以首先檢視了北斗接收的資料，結論是無誤。
再檢視資料庫的日誌，資料庫插入前資料嚴重滯後，懷疑可能是資料積壓太多，插入緩慢。
而我們的後台邏輯是插入資料庫成功後才進入實時資料服務，所以進入實時服務的資料也滯後。
另外，實時資料服務有乙個檢查時戳的協程，如果資料過期就踢掉。
至此，大概的問題就找出來了，實時服務踢掉了資料，客戶端檢視實時資訊當然看不到。
另外還出現了問題是資料回放的請求響應極慢，30秒級別。
開始排查可能造成此問題的原因~
**貌似正常，後端開發拍了胸脯，過了一遍邏輯確實沒什麼問題。
那就看看部署問題吧
top一看，cpu竟然用了100%，全被mongod這個占用了。
開始google，baidu。。。
直到看到這篇文章：
我們業務的特點是資料量大，實時性要求高，很多資料是根據id和時戳來進行的業務。
於是把所有使用者的實時資料均針對id和時戳加了索引。
主要用到的命令如下：
db.***.getindexes()檢視索引
db.***.ensureindex()設定索引
cpu瞬間降下來了。
目前還得觀察，不過我想問題已經解決了~
記一次CPU突然飆公升到 100 問題排查
線上 cpu 飈高問題該如何定位問題呢？是因為執行緒太多，導致上下文切換？還是因為應用 現了死迴圈？還是gc頻繁導致 cpu 突然飆公升？該如何入手呢？首先要知道那些情況會導致 cpu 的突然飆公升 頻繁gc，訪問量高時，有可能造成頻繁的gc 甚至fgc。當呼叫量大時，記憶體分配過快，就會造成gc執...
記一次除錯
這是我最近幾個月來遇到的最棘手的乙個問題 昨天花了4個小時找出第一層次的原因 這個糾結啊，本來和老婆說好準時下班回家吃飯的，結果被這個問題拖了老久。這是乙個gradle的plugin，用來resolve公司內部的dependency的，弄完了跑測試專案的，拋乙個npe，而且npe還不在自己的 裡面。...
記一次 EqualsAndHashCode的疑惑
lombok的使用真的是讓開發人員欲罷不能，乙個 data不管有多少屬性全部搞定，以後加字段也不用從新生成get和set方法。不過這裡還是有乙個小坑需要注意一下，舉個例子 public class equalsandhashcodetest data noargsconstructor access...