前沿探索:騰訊云數(shù)據(jù)庫自治服務最佳實現(xiàn)(下)

來源:云加社區(qū)
作者:劉迪
時間:2020-08-18
2214
本文是對騰訊云數(shù)據(jù)庫高級產品經理劉迪在云+社區(qū)沙龍online的分享整理,為大家?guī)眚v訊云在數(shù)據(jù)庫自治服務領域的探索和實踐,希望與大家一同交流。

三、DBbrain行業(yè)典型案例分享

下面我們結合一個行業(yè)用戶的案例,來給大家進一步分享數(shù)據(jù)庫自治在實際的生產過程中如何應用。

640.webp (9).jpg

電商大促大家都不陌生,騰訊云自身也支撐了非常多的大規(guī)模電商。那么電商在每次的大促過程中,如何利用數(shù)據(jù)庫的自治服務,來保障自身的數(shù)據(jù)庫安全?

在備戰(zhàn)階段需要進行故障梳理、資源評估等工作,在沒有數(shù)據(jù)庫自治之前,這些工作都必須由DBA來進行。一旦在某個環(huán)節(jié)出現(xiàn)了問題,或者業(yè)務出現(xiàn)了問題,往往DBA就變成了“背鍋俠”,總能找出DBA的問題。

而使用數(shù)據(jù)庫自治服務就可以有效解決上述問題。

1.數(shù)據(jù)庫巡檢,評估風險

首先,我們可以通過數(shù)據(jù)庫巡檢全量的實例,評估相應的風險。因為電商行業(yè)的實例很多,如果讓DBA手動巡檢,工作量是非常巨大的,所以常規(guī)DBA會進行核心實例的巡檢,或者只對經常出故障的實例進行巡檢,但這樣就會有很多潛藏的風險。所以全量巡檢、多維度巡檢是非常必要的。

為什么說在這個地方可以發(fā)現(xiàn)問題?因為在備戰(zhàn)階段業(yè)務側一般會封網(wǎng),一旦封網(wǎng),業(yè)務邏輯不到必要的bug修復時是不會調整的。所以在封網(wǎng)后進行全量巡檢、排查問題,只要修復了那么在之后大促的過程中,就可以盡可能的減少問題。

640.webp (10).jpg

數(shù)據(jù)庫自治的巡檢報告,包含從基本信息到資源狀況、任務狀態(tài)的巡檢,以及日常的訪問行為等非常全面的信息。

熱點訪問是非常關鍵的,很可能業(yè)務沒有出問題,但冷熱數(shù)據(jù)一旦沒有進行區(qū)分,那么在并發(fā)量高的情況下一定會出問題。所以我們可以在用戶封網(wǎng)后提供全鏈路的檢查。

2.助力業(yè)務優(yōu)化改造

640.webp (11).jpg

在排查之后,我們還需要助力客戶進行業(yè)務的優(yōu)化。如圖所示,我們把優(yōu)化大致分為五層。

其中,SQL優(yōu)化是大家非常容易上手、操作起來非常方便的一個優(yōu)化,比如索引優(yōu)化、改寫優(yōu)化等。其次還有更深入的配置優(yōu)化、數(shù)據(jù)優(yōu)化、架構優(yōu)化和業(yè)務優(yōu)化等。

之所以排為1-5,是因為在第一層的優(yōu)化中,業(yè)務的配合度會比較高、改動比較小,隨著逐漸深入,可能就需要業(yè)務側更改代碼邏輯。我們會根據(jù)業(yè)務不同的需求提供相應的優(yōu)化建議。

3.業(yè)務場景的故障自愈

640.webp (12).jpg

最后,我們發(fā)現(xiàn)還有一些問題。比如大促中臨時的變更發(fā)布,導致因為數(shù)據(jù)庫層面沒有相應的應對措施,數(shù)據(jù)庫被擊穿或者壓力很大。還有可能是低質量的SQL,在壓力和數(shù)據(jù)量激增的情況下數(shù)據(jù)庫出現(xiàn)問題。

面對這種情況,傳統(tǒng)的方法一般是直接kill掉對話,持續(xù)kill或者定時kill進行降級。如果無法降級則進行重啟或者HA切換,或者進行業(yè)務側的應用回滾或者臨時降級,但相對來說實踐起來比較困難。

數(shù)據(jù)庫資質DBbrain在這個時候就可以發(fā)揮作用。首先7x24小異常診斷與優(yōu)化,可以在還未發(fā)生問題時就發(fā)現(xiàn)隱患,并提出優(yōu)質的解決方案。此外,還提供了高并發(fā)場景的解決方案,并且可以自動持續(xù)的kill掉阻塞的SQL。

4.高并發(fā)場景解決方案

640.webp (13).jpg

剛才我們提到,DBbrain在高并發(fā)場景提供了數(shù)據(jù)庫性能優(yōu)化以及降級止損的解決方案。方案具體有三項:

(1)熱點更新保護

在高并發(fā)場景中,經常出現(xiàn)對同一行數(shù)據(jù)的更新,在沒有緩存的情況下,都會打到底層的數(shù)據(jù)庫。為了保護和減小開銷,針對語句的排隊機制,盡可能把具有相同沖突的語句放在內存隊列排隊,通過開啟熱點更新保護來減少鎖沖突的開銷,提高高并發(fā)場景的數(shù)據(jù)庫性能。

(2)SQL限流

顧名思義,就是幫助用戶進行業(yè)務降級。限流的操作類似于改寫,但技術方案不同??梢酝ㄟ^創(chuàng)建SQL限流任務,自主設置SQL類型、最大并發(fā)數(shù)、限流時間、SQL關鍵詞,來控制數(shù)據(jù)庫的請求訪問量和SQL并發(fā)量,進而達到服務的可用性,不同的任務之間不會發(fā)生沖突。

(3)空閑事務自結束

自動結束(Kill)空閑事務,避免大事務未提交導致大量資源爭搶。會自動識別開啟的事務,如果開啟事務后在一定時間內沒有進行提交,會自動結束該事務。

四、數(shù)據(jù)庫自治的未來展望

640.webp (14).jpg

數(shù)據(jù)庫自治在未來應該會朝著自愈、自優(yōu)化的方向發(fā)展,不僅能自主調節(jié)索引建議,還可以自主創(chuàng)建索引,自動進行識別、添加和刪除。

并且在未來還應該可以自動對執(zhí)行計劃進行回歸修正,優(yōu)化策略下沉與引擎融合,讓用戶需要干預的越來越少,提供的優(yōu)化服務越來越多。

最后是能夠自動識別并殺掉失控SQL,并阻止進行至優(yōu)化完成,幫助數(shù)據(jù)庫層面做更多業(yè)務層面的代碼實現(xiàn)。

這些都是未來將要實現(xiàn)的功能,或者是數(shù)據(jù)庫自治在未來能讓大家看到的迭代或者技術點。

Q&A

Q:數(shù)據(jù)庫審計功能很重要,特別現(xiàn)在等保也有要求。騰訊云數(shù)據(jù)庫審計的功能是通過旁路審計,還是從proxy節(jié)點抽取日志?

A:騰訊云數(shù)據(jù)庫的審計,是在內核層面實現(xiàn)的,并不像其他的審計功能需要外掛Agent,或者在接入機上安裝采集的進程實現(xiàn)。

騰訊云的數(shù)據(jù)庫審計,是在連接release之前,在語句提交之后進行規(guī)則匹配,如果命中規(guī)則便將內容轉變成json,拷貝成審計的內容發(fā)回,批量進行Flush刷盤,最后存儲到列式存儲中,提供用戶的查詢,并且為數(shù)據(jù)庫審計提供數(shù)據(jù)源。

在這個階段,如果在return和連接release中間,審計規(guī)則配的比較復雜或者比較多,就可能會出現(xiàn)性能損耗,但這個損耗是非常低的,在5%以內。

騰訊云數(shù)據(jù)庫的審計功能,與市面上其他審計相比的優(yōu)勢點在于,是通過內核側實現(xiàn),不需要再從旁路進行Agent審計,這樣一是可以避免漏審,二是旁路審計抓到的只是SQL包,抓包解析有可能有些信息抓不到,而騰訊云數(shù)據(jù)庫自治的審計除了常規(guī)內容之外,還能抓到SQL執(zhí)行的一些相關信息,比如影響行數(shù)、掃描行數(shù)等。

Q:數(shù)據(jù)庫走向自治后,DBA的工作內容有什么變化?

A:比如性能調優(yōu),故障恢復監(jiān)控、帳號管理、實現(xiàn)高可用、數(shù)據(jù)備份部署、架構選型等,在數(shù)據(jù)庫實現(xiàn)自治后,類似這些的重復、簡單的工作都可以被協(xié)助實現(xiàn)。而DBA更多的會傾向于更有價值的、與業(yè)務側結合更緊密的工作,類似于數(shù)據(jù)庫架構師、業(yè)務架構師的工作。

Q:數(shù)據(jù)庫的服務降級有哪些表現(xiàn)形式?

A:數(shù)據(jù)庫降級服務主要有幾種方式實現(xiàn)。比如SQL限流,用戶最直觀的感受是當SQL超過了數(shù)據(jù)庫的承載量后,會被拒絕,在日志中會看到一個自定義的錯誤反饋。因為SQL限流是在語義解析器之后、優(yōu)化器之前進行識別,當并發(fā)度超過我們設置的每秒并發(fā),并且特征相符,就可以在進入優(yōu)化器前進行攔截。另一種降級可以通過賬號和權限來限制;還有一種也可以通過DBbrain“實時會話”中提供的持續(xù)kill來實現(xiàn)。

Q:DBbrain是否在SQL優(yōu)化方面提供SQL優(yōu)化預估的時間消耗?并且在提供索引建議的同時,提供一個按鈕點擊即可通過onlineddl手動建索引?

A:DBbrain現(xiàn)在給出的是cost分析。選擇cost分析的原因,是因為cost更能體現(xiàn)出SQL在計算開銷、內存開銷、磁盤讀取數(shù)據(jù)開銷的代價特征,而時間往往是不準確的。比如在一個很空閑的系統(tǒng)中,執(zhí)行一些比較費時的操作,時間往往很快,但一旦數(shù)據(jù)量突增、系統(tǒng)環(huán)境發(fā)生變化后,同樣SQL的時間會變長很多,甚至是從量變到質變。而cost分析,哪怕是十行的數(shù)據(jù)沒有加索引都可以識別出來,就會減少只通過時間分析導致的誤判和影響。

對于提供點擊的onlineddl手動創(chuàng)建索引功能,應該會在后續(xù)提供給大家,也是后續(xù)比較重要的一項功能,幫助完成從發(fā)現(xiàn)問題、定位問題、優(yōu)化問題到最后執(zhí)行,這樣一個全鏈路的優(yōu)化閉環(huán)。

立即登錄,閱讀全文
原文鏈接:點擊前往 >
文章來源:云加社區(qū)
版權說明:本文內容來自于云加社區(qū),本站不擁有所有權,不承擔相關法律責任。文章內容系作者個人觀點,不代表快出海對觀點贊同或支持。如有侵權,請聯(lián)系管理員(zzx@kchuhai.com)刪除!
優(yōu)質服務商推薦
更多
掃碼登錄
打開掃一掃, 關注公眾號后即可登錄/注冊
加載中
二維碼已失效 請重試
刷新
賬號登錄/注冊
小程序
快出海小程序
公眾號
快出海公眾號
商務合作
商務合作
投稿采訪
投稿采訪
出海管家
出海管家