後來經過我們排查日誌發現乙個現象，提出該問題的使用者都是基礎資料比較多的，因為我們是金融軟體，所以當使用者的基礎資料比較多的時候，在首頁展示時會先去查詢基礎資料，然後在輪詢這些基礎資料查詢介面得到結果之後再進行一些邏輯運算。有不少使用者多達幾十甚至上百條基礎資料，所以導致查詢時非常慢。
這個問題的關鍵是使用者基礎資料的查詢，以及對基礎資料輪詢查詢介面次數較多導致的。所以當了解了問題的根源所在，我們就從根源出發解決這個問題。
我們想到的是，既然是因為查詢基礎資料和輪詢基礎資料次數較多導致的，那麼我們就減少次數。
怎麼減少呢？我們的方案是提前查詢使用者基礎資料到redis進行快取，而不是在客戶登入時再去載入，這樣使用者登入時的基礎資料查詢次數就減少到了0。因為我們的使用者基礎資料變化的不是那麼頻繁，所以我們可以這樣提前快取。
那什麼樣的使用者才去提前載入呢？肯定不是所有使用者，我們只針對基礎資料條數達到某一閾值時的使用者（稱為特殊使用者，將使用者新增至白名單使用者表white_user表）。比如基礎資料達到5條時，該閾值可引數化配置，並根據條數和頁面響應時間測試得出該值。比如當有5條基礎資料時，達到頁面響應時間使用者可忍受程度的極限。
我們必須要自動發現特殊使用者，將其新增至white_user表。我們選擇在使用者登入時開啟執行緒判斷使用者是否滿足白名單使用者的條件，滿足則新增至white_user表，不滿足的先判斷是否在表裡，在則刪除掉。（使用者可自己操作減少基礎資料）
分析完問題，也大致確定了解決方案。我們來總結下解決方案：
1、自動發現特殊使用者，新增至white_user表。-根據基礎資料閾值，判定是否為特殊使用者。
2、凌晨定時載入白名單使用者基礎資料至redis。-定時跑批，執行任務。
2、客戶登入時，執行非同步操作。根據基礎資料個數與閾值比較，判定是否可以列為特殊使用者，並新增至白名單使用者表；不滿足特殊條件時若使用者在白名單使用者表，則刪除。
3、非同步重新整理使用者基礎資料，當使用者修改基礎資料時，非同步更新基礎資料。
4、因為載入到redis的資料設定的都有過期時間，所以。。。。
第乙個問題解決方案，redis分布式鎖
定時任務執行時，利用redis實現分布式鎖，使得只有一台跑批系統執行任務。
第二個問題解決方案，可以和第一種一樣也使用分布式鎖，但還可以用另一種
所以即使是集群環境下多台機器都執行，也不會重複操作同一使用者資料，不會做重複操作。
一次生產事故的優化經歷
跟蹤web伺服器業務日誌，發現在資料庫更新層報請求不到新的資料庫連線或者資料庫連線已經用完，認為是資料庫的最大連線數太小，於是調整mysql資料庫最大連線數為以往的3倍 下次搶標的時候繼續觀察業務日誌，發現已經不報資料庫鏈結的相關錯誤了，但還是很多使用者反饋搶標時候打不開頁面。在搶標過程中繼續觀察，...
一次生產事故的優化經歷
原 一次生產事故的優化經歷 跟蹤web伺服器業務日誌，發現在資料庫更新層報請求不到新的資料庫連線或者資料庫連線已經用完，認為是資料庫的最大連線數太小，於是調整mysql資料庫最大連線數為以往的3倍 下次搶標的時候繼續觀察業務日誌，發現已經不報資料庫鏈結的相關錯誤了，但還是很多使用者反饋搶標時候打不開...
一次生產事故的優化經歷
分析過程 跟蹤web伺服器業務日誌，發現在資料庫更新層報請求不到新的資料庫連線或者資料庫連線已經用完，認為是資料庫的最大連線數太小，於是調整mysql資料庫最大連線數為以往的3倍 下次搶標的時候繼續觀察業務日誌，發現已經不報資料庫鏈結的相關錯誤了，但還是很多使用者反饋搶標時候打不開頁面。在搶標過程中...