上午9點，資料庫cpu達到100%，導致資料庫服務超時，不可用
查詢原因：個人使用者許可權表大概7000萬資料，9點業務高發期，而且每一次操作都會驗證許可權。大量的併發被掛起，導致雪崩， 1、而平時不會出現的原因是有快取，而且昨晚上游系統下發資料導致快取全部被清空。
2、個人使用者許可權太大，一次查詢可能會查過上萬條資料
3、有一張表，10萬資料，6個優先順序，需要6個sql進行union查詢，導致查詢慢，cpu高
後來進行優化，分成6個單獨的sql查詢，優先順序高的有值，就不會繼續查，否則繼續查sql.
上線後，的確針對這個sql沒有了超時等情況，cpu在80%以下，沒收到報警，很開心
但其他查詢：例如這個許可權查詢總是超時，而且多個服務都癱瘓，
最後：發現資料庫qps高峰在6000左右，拆分後的sql執行次數一天在100萬次左右，於是提高資料庫連線數800到1200，儘管cpu到了90%左右，但服務都可以訪問了，懷疑是qps太高，但連線數不夠，導致服務不可用
2019.1.8：補充1
預載入所有的資料到快取後，但依然資料庫對應sql訪問量不減，無奈之下甚至開始r懷疑edis是否取值成功
後來突然想到：存在的放在redis,那不存在的還是要查6次資料庫啊，
於是針對這個處理，資料庫查不到的，放到redis裡,value預設0，於是就可以無需查詢資料庫了，全部從redis走
2019.1.8：補充2
教訓：一定要仔細關注mysql的慢查詢語句，針對執行多次的語句，看一下它的查詢條件，重點關注。我們就是自認為後年的引數是n個查詢條件中的乙個，沒有去關注查詢條件。後來發現 就是這個sql ,把他對應的值放到快取裡後，系統立馬快了很多。
2019.1.9:補充
qps不變，但資料庫cpu在保持在5%，和前端時間的90%天差地別
計畫解決策略：
1、下發資料時，修改zk值，為防止白天載入熱點資料到redis會影響白天業務，特於晚上定時任務：預載入使用者許可權熱點資料，修改完畢後，修改zk值
2、分庫儲存（按使用者分庫），畢竟資料量太大
3、預載入的資料：過期時間加隨機值
2018 9 28 生產問題備註回憶
生產問題總結 表現 1 應用伺服器掛了2臺，資料庫服務記憶體突然公升高 2 資料庫資料許可權表查詢超時 原因 大批量的人為匯入excel同時操作，1 匯入前會檢驗使用者許可權，預設載入在快取裡，但此時redis快取沒有起作用，導致大量請求直接查詢資料庫，造成超時。2 檢驗後，計算實時資料時，取預留比...
2020 12 02 生產問題記錄
專案之前是採用oracle資料庫進行儲存，上週進行了國產化資料庫遷移改造，改造之後，有對接系統反饋有程式問題。原有程式介面一直沒有問題，正常執行。且在25號後沒有對 進行更改，對比 也沒有問題，單獨執行sql語句也是能正常查出符合的資料。大致sql是要查詢出一天內的資訊記錄，使用的是between ...
11 9 生產環境部署
fabric ca在整個證書管理環節中處於十分核心的位置。在生產環境中部署時，必須從多個方面進行考慮，以充分確保安全性 可靠性 規範性等指標。1.根證書的生成 根證書目前可以通過從權威機構 包括golbalsign verisign 申請，或採用自行簽名的方式生成。技術上來講，兩者都可以完成部署過程...