記錄生產(chǎn)mysql的問題點。
業(yè)務場景與問題描述
請求一個外部接口時，每天的請求量在900萬左右。
分為請求項目和回執(zhí)這兩個項目。請求是用來調用外部接口，回執(zhí)是接收發(fā)送的接口。
在發(fā)送請求前會先插入數(shù)據(jù)庫。
在請求后，如果接口返回調用失敗，會更新數(shù)據(jù)庫狀態(tài)為失敗。
如果發(fā)送成功，則會等待上游給出回執(zhí)消息后，然后更新數(shù)據(jù)庫狀態(tài)。
而在生產(chǎn)運行過程中，半年出現(xiàn)過兩次mysql導致的mq消費者堆積的問題。
問題分析
記錄兩次不同的原因導致的生產(chǎn)問題及原因分析。
mysql死鎖問題
查看mq聚合平臺TPS
上生產(chǎn)發(fā)現(xiàn)mq數(shù)據(jù)一直堆積，且不斷上升。而TPS僅為30左右，一直上不去。
這就會使mq消費變慢了，導致不斷堆積。具體什么原因導致mq一直堆積，需要繼續(xù)排查。
查看生產(chǎn)服務器日志
查看生產(chǎn)服務器日志，發(fā)現(xiàn)有報錯dead Lock的錯誤。
|
1
|
error response from MySQLConnection [node=24, id=277499, threadId=2735941, state=borrowed, closed=false, autocommit=true, host=10.1.10.74, port=3306, database=sep_4, localPort=27744, isClose:false, toBeClose:false, MySQLVersion:5.7.25], err: Deadlock found when trying to get lock; try restarting transaction, code: 1213 |
具體的sql如下：
|
1
|
update stage set status = 'success',reply_time = '2021-03-07 10:40:11' where code = '000123' and create_time > '2021-03-03 00:00:00'; |
也就是說在執(zhí)行服務時出現(xiàn)了死鎖的情況。
具體有多少條以及耗時，在生產(chǎn)服務器看著不直觀，于是就讓dba將慢sql的語句和耗時查出來。
查出后發(fā)現(xiàn)最長的慢sql的耗時長達7780ms。
仔細查看會發(fā)現(xiàn)，sql會發(fā)現(xiàn)相同的id一個在執(zhí)行中，一個在Lock Wait狀態(tài)。
而這慢sql中有大量的Lock Wait狀態(tài)。
什么原因導致的死鎖
mysql使用的數(shù)據(jù)庫引擎時InnoDB。先了解下什么是死鎖：
所謂死鎖: 是指兩個或兩個以上的進程在執(zhí)行過程中,
因爭奪資源而造成的一種互相等待的現(xiàn)象,若無外力作用,它們都將無法推進下去.
此時稱系統(tǒng)處于死鎖狀態(tài)或系統(tǒng)產(chǎn)生了死鎖,這些永遠在互相等竺的進程稱為死鎖進程.
通過上面的排查可以看出，出現(xiàn)死鎖的問題就是：
在執(zhí)行sql更新一條數(shù)據(jù)時，會將這一行數(shù)據(jù)鎖定，執(zhí)行完成后會釋放行鎖，而沒有執(zhí)行的sql處于Lock Wait狀態(tài)。
而程序中導致此原因在于，在發(fā)送前后和回執(zhí)時，頻繁操作數(shù)據(jù)庫，可能會出現(xiàn)同時操作同一條數(shù)據(jù)的情況。
所以在執(zhí)行中就出現(xiàn)了鎖等待的情況。
分庫分表未帶分片鍵
首先告警的是stage_prod庫的CPU飆到了85%。
數(shù)據(jù)庫線程數(shù)是否被打滿
經(jīng)過查看數(shù)據(jù)庫連接情況可知，數(shù)據(jù)庫連接數(shù)并沒有被占滿。
查出慢sql和耗時
查出的問題sql：
|
1
|
update stage set status = 'success',reply_time = '2021-03-07 10:40:11' where create_time > '2021-03-03 00:00:00'; |
查看sql會發(fā)現(xiàn)，這條sql竟然沒有帶分片鍵code字段。而這條sql是回執(zhí)時執(zhí)行的。
排查生產(chǎn)服務器日志
代碼中有做判斷，如果code值不為空，sql會帶上code的值。那么沒帶上，就需要查看為何沒有帶上。
查看代碼會發(fā)現(xiàn)，code是從redis中獲取的，是在發(fā)送時set到redis中的。但是沒有set進去就很奇怪了。
初步懷疑是redis問題，然后就與redis維護的平臺溝通，發(fā)現(xiàn)果真是因為redis故障導致的問題。
為什么不帶分片鍵CPU就會飆升
首先公司用的是hotdb分庫分表，因為每天的入庫量是在900萬左右，一個表是上億條數(shù)據(jù)。
如果只是單純用索引，是無法滿足要求的。
分庫分表hotdb，根據(jù)code值做hash分片，做了64個分片。也就是說64個數(shù)據(jù)庫，分布在8臺服務器上的16個實例里面。
這樣可以避免各分片數(shù)據(jù)不均，理論上避免了過度集中在某個分片上。
而如果不帶分片鍵code的sql，所有的dml操作全部下發(fā)到所有的底層庫上進行執(zhí)行，相當于遍歷了一遍庫。
這樣就可能會導致CPU直接飆到99%，甚至直接導致服務器直接崩掉，這樣操作是很可怕的。
解決辦法
應急處理：先停掉幾臺服務減少數(shù)據(jù)庫操作
數(shù)據(jù)持續(xù)堆積，會影響數(shù)據(jù)處理速度。那么，就要先降低操作的速度，最快速的辦法就是停服務，減少數(shù)據(jù)庫的操作頻率。
減少數(shù)據(jù)庫操作避免數(shù)據(jù)庫死鎖
死鎖一般時由于程序上沒有控制好dml操作的提交，沒有及時提交.
減少重復操作同一條數(shù)據(jù)。在批量操作時減少每批dml數(shù)，保證快速提交，避免長事務，避免重復提交dml。
那么怎樣減少操作呢？
合并sql
將發(fā)送前插入和發(fā)送失敗時更新，直接合并到一條sql，這樣就可以避免多次操作同一條數(shù)據(jù)的情況。
批量執(zhí)行時減少長事務和條數(shù)
執(zhí)行時發(fā)現(xiàn)，每次批量執(zhí)行20條sql，比一次性執(zhí)行200條的效率更快。
所以盡可能避免這種問題。
每條sql必須帶分庫分表分片鍵
原則就是不能因為一條數(shù)據(jù)就拖累整個數(shù)據(jù)庫的操作速度。
分片鍵必須帶上，如果不帶分片鍵，就拋錯。
增加時間區(qū)間開閉區(qū)間
用code來做分片鍵，用createTime做分區(qū)。那么在保證code存在的情況下，可以寫上開閉區(qū)間，可以提高執(zhí)行效率。
更優(yōu)解：sql順序執(zhí)行
這種方案可以通過把將要執(zhí)行的sql統(tǒng)一發(fā)到一個mq來消費執(zhí)行，這樣可以保證sql順序執(zhí)行，從而避免死鎖的產(chǎn)生。
但是這個需要根據(jù)業(yè)務場景來區(qū)分。
復盤
mysql死鎖問題，要盡可能避免頻繁操作同一條數(shù)據(jù)，也要避免長事務；
針對分庫分表問題，一定要帶上分片鍵；
監(jiān)控機制不可少；
總結
到此這篇關于mysql死鎖和分庫分表問題的文章就介紹到這了,更多相關mysql死鎖和分庫分表內容請搜索服務器之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持服務器之家！
原文鏈接：https://blog.csdn.net/weixin_42246822/article/details/115711697
