這是學習筆記的第 2217篇文章
讀完需要
9
分鐘
速讀僅需7分鐘
最近有一個數據庫的延遲問題比較明顯，大體的邏輯是有一批數據需要在緩存中校驗，如果數據過期，就需要重新刷新數據，整個數據量大概有2000萬，更新的數據量平均在600萬左右，也就意味著基線變更數據是600萬左右，需要根據數據的熱度適時更新。
大體邏輯如下：
在緩存層面進行校驗，查看數據的狀態，
select xxxxx from test_list where uid=xxxx;
如果存在且失效，則進行更新：
update test_list set xxxx where uid=xxxx;
如果不存在則進行數據插入：
insert into test_list values(xxxx,xxxxx);
最早收到相關報警，是從高可用層面報出的，提示數據庫產生了較大的延遲，導致高可用檢測失敗。查看歷史的監控數據，發現在早間的一個時間段，比如9:00~10:00，會有明顯的數據延遲情況。
其實可以做一下估算，每秒的QPS大概在2000左右（加上查詢部分），產生的binlog是比較集中的。
可以補充一下對於延遲問題的分析，在高峰時段，沒有任何慢日誌，臨時開啟了general log，裡面的邏輯也是比較清晰簡單。在這種情況下想做優化，貌似空間不大，但是每天早上會收到高可用報警真是很煩。
於是為了能夠快速收場，看MySQL 8.0在複製方面有了新特性writeset，為了並行對比已有的COMMIT_ORDER,WRITESET模式，我在這套環境的從庫上面搭建了MySQL 8.0的Slave節點。
整個部署架構是類似這樣的形式。
第二天靜等數據結果，實際結果讓我著實有些吃驚，開啟了writeset之後，紅色部分就是8.0的表現，相比綠色的部分MySQL 5.7差了很多。
當然這塊可以對新版本的複製特性進行後續的講解，調整為默認的設置之後，依然有差距。
這個問題的解決之道其實得跳開已有的背景和數據來看，而要從整個流程來切入，我從開發同學那裡要來了相關的代碼邏輯，也做了一些分析，下午的時候和開發同學進行了進一步的溝通，對於這個問題的處理結果還是頗有自信，期待明天的數據。
去IOE or Not?
拉里·佩奇（Larry Page）的偉大歸來
《吊打面試官》系列-Redis基礎
唯一ID生成算法剖析，看看這篇就夠了
關於大數據運維能力的一些思考
DBA菜鳥的進化簡史：不忘初心，記工作中踩過的三個坑
美女主持直播,被突發意外打斷!灣區網友卻高喊: 我懂!超甜
