問題的發現過程是這樣的，一些硬體裝置上傳的實時裝置資訊客戶端不能展現，於是查詢日誌，發現數據時間延遲非常嚴重，後臺邏輯把這些資料當作過期資料扔掉了，所以沒有進入實時資料的服務（此服務是單獨部署的）。

於是開始查問題，難道原始資料就是過期的？鑑於北京的霧霾天可能對北斗（PS：我們主要是裝置的北斗位置資料）產生影響，所以首先查看了北斗接收的資料，結論是無誤。

再檢視資料庫的日誌，資料庫插入前資料嚴重滯後，懷疑可能是資料積壓太多，插入緩慢。

而我們的後臺邏輯是插入資料庫成功後才進入實時資料服務，所以進入實時服務的資料也滯後。

另外，實時資料服務有一個檢查時戳的協程，如果資料過期就踢掉。

至此，大概的問題就找出來了，實時服務踢掉了資料，客戶端檢視實時資訊當然看不到。

另外還出現了問題是資料回放的請求響應極慢，30秒級別。

開始排查可能造成此問題的原因~

程式碼貌似正常，後端開發拍了胸脯，過了一遍邏輯確實沒什麼問題。

那就看看部署問題吧

top一看，CPU竟然用了100%，全被mongod這個佔用了。

開始google，baidu。。。

直到看到這篇文章：http://m.blog.csdn.net/blog/roler_/40107751

我們業務的特點是資料量大，實時性要求高，很多資料是根據ID和時戳來進行的業務。

於是把所有使用者的實時資料均針對ID和時戳加了索引。

主要用到的命令如下：

db.XXX.getIndexes()檢視索引

db.XXX.ensureIndex({id:1})設定索引

CPU瞬間降下來了。

目前還得觀察，不過我想問題已經解決了~

出現問題不可怕，主要是通過學習去解決它，我現在想找個靠譜運維，幫我做這些事，歡迎大家騷擾。