問題復現
咳咳，說實話，這個挺尷尬的，那時前兩天剛寫的介面，我還特意寫過一篇關于它的坑，沒想到還是有隱藏的bug，廢話不多說上圖
這是上次的那個介面功能，就是查詢未讀會話有幾個，不為0的話，會顯示小紅點
聽起來很簡單，但是今天就遇到了bug
問題是這樣的，我們操作的時候，快速把所有會話點了一遍，然后給某個會話設定為了未讀狀態，發現就對不上了，顯示還都是0，理應有未讀數1的，因為我剛把這個(某個)會話設定為了未讀狀態，推了一條系統訊息的（xxx設定了未讀）,但是從ES查詢的結果卻是沒有未讀會話，這個第一時間肯定能想到是資料沒有同步過來，那么這樣怎么優化呢？
思路
1.前端多一定的延遲，不要點開那個會話視窗的時候立馬掉這個查詢未讀會話的介面，讓他停個100ms行不？
2.后端ES的雙寫看看是不是異步去刷資料的，能不能改成同步
3.這個介面其實只需要查詢有沒有未讀會話就行了，不需要吧未讀的數量全部查詢出來
方案一：前端延遲，但是人家前端說已經延遲了500ms都不行，現在延遲1200ms資料正常，這個方案不行，這個必須要后端介入優化了
方案二：看了我們的同步資料的執行緒，如果是異步多執行緒跑的，盡量改為同步多執行緒去重繪，
方案三：方案三其實就跟資料庫的查詢很類似，就是Limit 1，限制我查到一條符合資料的結果我就中斷ES的查詢，直接回傳，然后這個介面也不回傳具體數量了，直接回傳true/false就行，有未讀就回傳true，沒有未讀會話就回傳false
這個方案ES的實作思路就是ES的分頁，給ES的from引數設定為0，size設定為1，也就是說從第0頁0條開始，查詢到符合1條第資料直接回傳，不再進行其他的查詢操作，等同于MySQL的Limit 1
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/381957.html
標籤：其他
上一篇：公司禁止JOIN查詢怎么辦？