https://dbaplus.cn/news-134-2970-1.htmlhtml
本文根據高新剛老師在〖2019 DAMS中國數據智能管理峯會〗現場演講內容整理而成。redis
（點擊文末連接可獲取完整PPT）數據庫
講師介紹緩存
高新剛，京東數科數據庫團隊負責人，負責京東數科數據庫平臺的管理維護工做，帶領團隊平穩護航屢次61八、1111的大促活動。對數據庫多業務場景架構設計、高併發解決方案、數據生態管控有着豐富的實踐經驗；對數據庫庫中間件、分佈式數據庫和自動化智能化管理平臺設計開發有着深刻的實踐和探索；長期專一於數據庫降本增效和技術產品化輸出。安全
經過這篇文章你們能夠了解到京東數科數據庫團隊在面對大規模集羣、海量數據和高併發場景下的運維概況，包括團隊主要的運維目標、運維體系和運維相關的自動化智能化的產品，以及介紹完整的京東數科618大促備戰的過程，解密京東數科在大流量的數據庫應用場景下的應對策略。性能優化
分享概要服務器
一、運維概述網絡
二、備戰準備數據結構
三、618進行時架構
四、案例覆盤
本次分享將圍繞數據庫運維，從四個部分進行：第一部分先介紹數據庫團隊運維的概況，接下來經過大促備戰準備、618進行時、以及案例覆盤這三部分分享，來介紹咱們數據庫團隊完整的備戰過程。
1、運維概述
一、運維團隊
先介紹一下咱們團隊，下圖爲咱們團隊全部成員。
之因此選擇這張照片，最關鍵的是標語——「運責心繫天下，維穩守護一輩子」。做爲數據庫運維人員，責任心是必須具有的屬性。
咱們團隊三個主要的工做方向：
1）數據庫運維
咱們負責京東數科全部業務的數據庫運維工做，服務於整個研發團隊，保證數據庫平穩高效運行。
2）自動化智能化運維產品
這個產品有一個很是好的根基，全部的需求、功能點都來自線上運維需求，來自咱們的痛點。它服務於咱們DBA運維人員，致力於提升咱們團隊總體的運維效率，完善數據庫周邊的生態服務。
3）科技輸出
把咱們在公司內部生產的優質的數據庫架構、分佈式數據庫解決方案，以及作得比較成熟的數據庫產品輸出給外部的公司，幫助客戶快速創建一套完整的數據庫架構體系。
二、運維目標
下圖的七個關鍵詞是咱們平常運維最基本的目標，若是咱們在如下這七個方面作得很是好，那麼咱們就能實現保障數據庫平穩高效的目的。
1）海量數據
首先，海量數據運維。這是DBA必需要面對的話題。那麼咱們如何保證海量數據庫平穩高效運行呢？我認爲運維規範是最重要的，按照規範作好架構規劃、作好冷熱數據分離，作好變動規範等等。只有這樣咱們才能駕馭海量數據的運維工做。
2）架構轉型
第二，架構轉型。如今不少公司的業務都面臨的架構轉型這個難題，無論是業務發展戰略的須要仍是數據庫出現了性能瓶頸的問題，不少人都在作去oracle，在作分佈式數據庫或者利用中間件進行水平拆分的相關工做。對於DBA來講，須要在這個過程當中作好如下服務：一是異構數據庫的遷移，二是數據庫之間實時同步，三是在保證架構合理的前提下嚴格控制成本以及保證數據安全。
3）服務可用率
第三，服務可用率。關於這一點，我以爲「精細」是很是關鍵的。如何理解「精細」二字呢？如今不少公司都開始作本身的容災系統，MySQL的高可用切換大都基於MHA進行二次改造開發，還有不少人用raft多副本寫來一致性協議去保證數據一致性。總的來講，在切換效率上和數據一致性保障上都有所提高。
可是在我看來，切換以前的故障探測、故障場景的分析以及切換決策的邏輯，這些方面要遠遠比切換自己重要。咱們要對故障的根因進行充分的分析，要很是清晰地涵蓋全部極端場景，這樣整個容災系統才能保證排除掉全部異常狀況，因此作好數據庫故障場景精細化管理很是重要。
4）持續
第四，性能保障。這一點無需贅述，做爲一個運營人員，咱們要持續保障數據庫性能。關於這一點，我想說一個很重要的現象，在咱們團隊中不少人不肯意去作性能保障的工做，他們更願意作前瞻性的技術研究，作自動化、智能化的設計開發，以及科技輸出的相關工做。
在咱們團隊有一段時間我發現咱們的DBA把更多的精力投入到數據庫的拆分遷移、投入到自動換運維產品的開發設計，投入到對外輸出的項目當中去，忽略DB性能的管理優化，他們認爲性能優化不容易出成績，因此他們更願意作新技術的研究，去開發數據庫相關的產品組件，去作科技輸出。其實這就偏離了DB運維的本職工做。性能優化要持續作下去，即使咱們如今有不少自動化的優化手段，也要堅持作好性能優化保障，由於咱們的運維產品尚未到達徹底人工智能的那個階段。因此這項工做咱們要持續下去。
5）保障
第五，數據安全。數據安全對於咱們而言就是「數據不丟失、不泄露」，具體內容爲儲存數據快速同步、分佈式事務的一致性、在關鍵的敏感字段上進行數據加密、數據庫備份和容災。只有作到這些才能保證數據的安全。數據安全是安身立命之本，它就是那個1，若是沒有那個1，後面再多0都是無效的。
6）高效
第六，水平拆分。如今不少公司都在作中間件的開發，實現數據庫的水平拆分、實現相似業務透明、分庫分表等等，但如何去衡量中間件產品的好與壞呢？在我看來就是高效，不少公司作了相似的工做，尤爲是中間件支持分佈式的事務，可是又有幾家公司敢在本身核心業務上用這個東西呢，這裏就涉及到效率的問題。好的產品組件都作到了服務高效、對業務透明、研發改形成本低、有很好的數據流控管理、自動的彈性擴容還有高效的分佈式事務服務，這些都是分佈式數據庫追求的目標。
7）價值
最後，數據服務。在完成前面六項基本運維目標之後，如何保證數據在各個系統、各個層面之間的流轉？如何保證數據同步？如何結合大數據平臺進行分析、計算，幫助業務人員挖掘數據的價值？須要作好數據生態管控，經過複製平臺，ETL管控平臺作好增值的數據服務。
以上這些就是咱們運維的基本目標。
三、運維體系
接下來介紹一下咱們的運維體系，把剛纔基本的運維目標再提高一下。
咱們的核心目標是保證數據一致性、保證容災可用性，還要符合安全合規的管控。基於這些方面，再經過運維自動化提高運維效率，保證數據治理，維護數據生態。
那麼如何去實現核心目標呢？這就須要咱們按照各個業務層面的業務需求，去作相關運維自動化產品的工做，而這些產品其實都是由人爲手動階段逐漸演變出來的產品。
1）應用層
首先在應用層，業務的需求有什麼？
① 數據庫建模
這個工做是很是重要的，如今好多人都在說大數據、數據標準、數據治理。其實自動化的數據建模纔是數據標準管控的源頭，只要把數據建模作好，後面大數據的事情就很是容易了。基於咱們的需求，數據建模實現了這麼一個平臺DBCM。
② SQL自助查詢
如今不少研發在開發調試過程當中須要查詢數據庫，還有一些業務人員須要查詢導出一些業務數據。在整個查詢過程當中須要管控，一些核心數據也要進行加密，過後還有一些查詢審計的工做，最終這些需求造成了咱們查詢機的產品，它可以幫助咱們進行線上運維，並幫助運營人員實現數據的快速查詢。
③ SQL自助變動
之前咱們作數據運維的時候，大多數數據變動都是手動操做的，這種方式不但誤操做風險大，並且DBA的工做效率極低。因此咱們作了一個工單系統MagicFlow。
這個工單系統包含三個功能：
第一，SQL審覈。研發提上來的SQL是否合理？是否規範？是否有風險？經過SQL審覈基本上就可以把它過濾掉。
第二，審批流。這一點很重要，研發作什麼操做都要通過上級的審批，包括數據庫作什麼操做也須要經理或者總監作一層審批，尤爲在一些大型銀行或者企事業單位，這種審批仍是很是重要的。
第三，自動執行。下降DBA手動執行的風險點。自動執行模塊還能根據數據庫性能進行調度調整。在性能壓力比較大的時候，工單是會延後執行的。
2）中間層
中間層就是數據庫中間件，剛纔說了數據庫中間件只要作到了高效的服務就OK了。一般包含水平拆分、讀寫分離、彈性縮擴容、分佈式事務。咱們ShardingSphere目前是Apache明星項目，具備業內影響力的開源數據分片中間件，創建了爲上百家企業提供數據庫解決方案的生態圈。
3）數據庫層
接下來在數據庫層，DBA平常的操做如今已經都概括到數據庫的自動化運營平臺裏了，平常的部署、高可用切換、備用等操做基本上都已經涵蓋在自動化平臺裏。
還有數據庫性能，之前數據庫對於研發人員就是一個黑盒，若是研發想了解數據庫的性能就要找DBA去諮詢；如今咱們經過數據庫性能展現平臺CleverDB，把全部數據庫維度的信息都展示在平臺上面，實現了數據庫性能自助管理。在數據庫出現故障的時候，咱們也會進行分析，而後快速定位這個問題。
4）大數據層
最後在大數據層面，DBA作的是數據抽取和複製訂閱，這一部分有兩個工具：一個是數據複製平臺DBRep，它能夠作到實時數據的複製和解析；再一個是大數據計算與分析平臺，它可以計算海量的邏輯運算。
2、備戰準備
接下來說一下618備戰的具體狀況，經過下圖你們可以瞭解到，在備戰這個階段作的事情最多。咱們要作備戰巡檢、容量的評估、優化改造、數據歸檔、壓力測試、切換演練和變動管控，若是把這些點作到了，618時工做人員是特別輕鬆的，只須要作監控和應急處理。最後，每次618或者雙十一後，咱們還會對備戰準備和當天出現的問題進行事件的管理，並結合案例進行總結。
一、備戰巡檢
① 自增主鍵
說到備戰，首先要作的就是數據庫深度巡檢，首先是自增主鍵的問題，你們都知道自增主鍵爲int類型時有一個上限值，有符號的時候是21億，無符號的時候是42億。當表中的自增主鍵到達這個上限時，會從1開始插入，結果表中已經有id=1的記錄了，這個時候就會報主鍵衝突。
在這個點上咱們曾經出現過兩次比較嚴重的問題。第一個單表記錄大概是7億左右，當時研發同事要處理一部分數據，經過清洗後再寫入這個表，爲了避免影響線上的正常寫入，研發同事就提了一個工單，將自增主鍵改爲了20億，從7億到20億中間有足夠的空間進行數據導入。結果過了一個多月，故障發生了，自增主鍵寫滿了，代碼日誌顯示主鍵衝突，排查了好長時間以後DBA才意識到是這個21億的問題，這是一個很是慘重的例子。
第二個故障是咱們有一個數據庫作了水平拆分，大概是10個庫，每一個庫1000張表，並且這個表用了全局自增id，當時的狀況就是每一個表的記錄條數遠遠小於21億，但全局自增id的那張表已經到達21億的上限，也就是全部分表的總記錄條數到達了21億。這個時候後續的數據就沒法寫進來了。固然解決辦法也很簡單，就是把全局自增id表刪掉，而後快速建一個bigint表，讓它從21億以後繼續自增，這樣就解決了，但仍是影響了一段時間寫入和操做。
② 磁盤空間
第二個是磁盤空間的檢查，磁盤空間的檢查包含系統層面和數據庫層面的檢查。DB相關的就是binlog、errorlog、slowlog generallog 還有數據文件，重點關注磁盤使用率、數據增加率、剩餘空間預計使用時長。這裏面強調兩點：第一點，咱們作了不少智能化的組件，在服務器常常會裝各類client，產生一些日誌，日誌有時候很是大，若是運維人員不關注的話有可能會衝爆磁盤。第二點是在數據庫，重點說的是general_log，有些DBA爲了分析問題會把這個日誌打開，結果打開以後問題分析完忘關了，隔了很長時間這個日誌也會把整個數據庫填滿的。
③ 表分區
表分區這塊，網絡公司也是有作這種架構的，按照月、季度或者半年建立分區。618活動從6月1日到6月19日，因此6月份時間點很是關鍵，咱們要檢查一下分表或者分區都有6月份以後的表，要確保分區已經建立完畢。除此以外，按月水平拆分的分表也須要注意一樣的問題。
④ 鏈接數
在鏈接數方面，咱們也遇到不少問題。四年前，我在團隊定過一個目標——無論什麼樣的活動，什麼樣大促的節日，咱們都不能出現鏈接數的故障，只要不出現咱們團隊就去團建。結果四年過去了，這個目標尚未實現，你們就知道鏈接數的故障真的是層出不窮的。不過，雖然咱們出現了不少問題，但並不表明咱們沒有應對方案。
首先在活躍鏈接數這部分基本上是從慢查詢、事務邏輯和訪問邏輯三個方面去優化。
第一，絕大部分活躍鏈接數高都是由於慢查詢，通常狀況下咱們DBA經過添加索引或者研發改寫SQL均可以解決；
第二，大事務、長事務引起的鎖等待，一個事務包含不少邏輯步驟，有些邏輯可能會產生排它鎖，所以而引發的和這個鎖相關表得查詢都被堵塞了。在高併發的場景下就顯得格外突出。這種狀況咱們通常都會要求研發精簡或者拆分事務邏輯。把大事務變成小事務；
第三，業務調用頻繁，併發訪問控制，寫入量和查詢量很是大，這個可能要從業務邏輯上去梳理，寫的時候經過MQ去控制，讀訪問看看可否在前面添加redis緩存。好比說一秒執行1000個相同的SQL，一樣，應用服務器由多臺應用部署，打到數據庫上的話，數據庫很容易就滿了，在這塊若是寫的操做就要加一些MQ。若是是隻讀操做就要經過緩衝或者優化調用邏輯。
其次最大鏈接數問題，研發在大促過程中常常進行應用擴容，好比說擴容100臺應用server，可以保證應用層面不出現任何壓力問題。但你們想一下，若是擴容了200臺服務器,每一個應用的鏈接數是10，若是打到數據庫鏈接是多少？以前這部分咱們是沒有進行有效監控的，後來咱們把應用和數據庫的元數據打通，就能知道任何一個應用服務器的臺數是多少，鏈接的配置是多少，經過臺數和鏈接數相乘，與最大數進行比較，這樣可以在大促以前預判配置是否是合理的。
⑤ 慢查詢
剛纔也說到慢查詢，這是一個持續優化過程，經過掃描的行數、返回的行數以及執行時間這些方面去分析。咱們如今有一個自動化的運維平臺，裏面有慢查詢的分析，因此這部分不只有DBA在優化，每個研發也會關注本身的數據庫系統。
⑥ Top SQL和熱點表
對Top SQL要有一個很清晰的瞭解，尤爲是核心的數據庫。高頻的SQL經過審計獲取相關的信息，對高頻的SQL能夠得到熱點的信息，哪些表被頻繁訪問，哪些表數據量比較大，哪些表作了水平拆分以後分佈不均勻，這些均可以經過表維度獲取。
⑦ 備份
接下來是備份，在大促當天或者前一天，全部的數據庫都是不備份的。爲了不從庫的IO爭用，緣由很簡單，把IO讓給大促的業務壓力，怎麼去處理這個事情呢？咱們要保證大促前幾天全部的備份都是有效的，一旦出現問題時，咱們能夠經過前幾天的備份和日誌去進行快速的恢復。
⑧ 定時調度
不只包含數據庫運維層面的調度任務，還還包含業務層面的跑批任務。目的就是爲了減小沒必要要的IO。例如數據庫備份、業務跑批、ETL抽取、信息採集。這些都不能在大促零點這一刻發生，因此咱們會把這些任務日後延，通常都是兩個小時之後。咱們要確保調度任務錯開大促高峯時間，因此每一個做業的開始和結束時間都須要咱們梳理。
定時調度，這裏不只包含數據庫運維層面的調度任務，好比信息採集 備份調度，更主要的是DBA要掌握業務跑批得時間和時長 、大數據抽取的時間和時長。咱們要確保調度任務錯開大促高峯時間。因此每一個做業的開始和結束時間都是須要咱們梳理的。
⑨ 容量評估
容量評估與磁盤空間的巡檢不太同樣，它包含硬件的使用容量和性能使用容量，容量評估的目的是爲了評估數據庫的架構、性能與資源是否匹配，以此推進硬件和架構的優化工做。後面會重點就講這塊。
⑩ 硬件&機房
硬件和機房的檢查其實不是咱們DBA來進行，可是像磁盤出現故障的地方必定要在大促的時候檢查出來。這個每一年都作，並且硬件的廠商也會在關鍵的時期排售後工程師協助咱們完成這些巡檢工做。
⑪ 業務梳理
業務梳理也是很是重要的，好比核心業務對數據庫的依賴程度，業務對數據的依賴程度是強依賴仍是弱依賴，在咱們公司內部要求弱依賴，數據庫掛了,核心業務不能掛，不能影響到終端用戶。在這方面作了不少架構上的彌補，好比說加了MQ，加了Redis。
事務邏輯的讀寫，尤爲是核心業務，在覈心業務支付主鏈路上，任何操做的事務咱們都會去分析，保證每一個事務的效果。若是數據庫宕機，業務有沒有熔斷的保護措施來避免終端用戶受影響？業務方之間有不少接口調用的邏輯，哪些接口能夠作降級保護，哪些接口有嚴格的超時限制，在覈心業務這個範疇裏，這些都須要DBA去了解清楚。
接下來是上下游的調用，經過上下游接口調用的分析，咱們要保證每個接口效率都是高效的，若是說出現了接口上的故障，整個業務要有自動熔斷的能力。
下圖是咱們巡檢的通道，如今咱們的數據庫規模已通過萬，現有DBA是徹底不可能作到人工逐個巡檢的，因此咱們也是經過智能化平臺把這個平臺開放給研發和全部DBA，經過這個平臺可以快速定位問題，這樣前面全部的問題都能在很短期內被發現。
二、容量評估
今年公司層面硬件服務器是零採購，在數據容量方面面臨的壓力是很是大的。業務發展須要服務器，可是咱們沒有新的機器，那麼如何對資源進行合理的管控？如何甄別資源使用不合理的業務架構呢？咱們經過如下幾個維度來作。
首先是SQL質量，如何看待一個SQL的好壞呢？經過這三個維度：第一個叫CPU維度，單個CPU維度上面產生的QPS越大，說明SQL的效率越好。好比說消耗1%的CPU，QPS是2000，你就能夠知道，當CPU打滿的時候QPS最大可以支撐到多少。
接下來還有IO層面，也就是單個IO上面產生的QPS有多大，就說明查詢的效率有多快。
經過QPS除以百分比，就能知道最大可以支撐QPS和TPS，經過這個方式作了幾個分檔，落在哪一個檔裏就能獲得多少分數。經過這種方式目的是督促研發去改造它的SQL，經過這個邏輯會給每個數據庫打分。分數若是合理，研發就能夠繼續去用；若是不合理，就會被扣分。這個分數和績效是息息相關的，因此每一個研發都很是注意SQL的質量。
第二個是磁盤使用率，好比說磁盤空間關注的是否是接近100%？容量這部分咱們關注的是磁盤使用率是否合理，好比說超過了80%，這時候應該作什麼呢？應該去作歸檔。若是這個數據庫長期只有300G，但磁盤是7T的硬盤，咱們認爲嚴重浪費了資源，這個DB資源須要縮容處理。因此在這方面咱們會對兩頭極端狀況進行扣分，督促研發去改進架構。
此外，這裏面會結合一些權重，好比說SQL的權重、主從庫的權重、業務等級的權重，核心業務和非核心業務的權重比是不同的。
經過上圖，你們能夠更好地理解容量評估要作什麼，也就是說，在紅框內咱們認爲服務器使用是合理的，在紅框以外的大於70%擴容去作歸檔，小於30%則是資源被嚴重浪費，咱們要求研發作縮容處理。經過這樣的方式咱們實現了今年服務器零採購，這是一個很是了不得的事情，由於京東每一年的硬件採購費用很是高。
咱們常常用這樣的邏輯給研發解釋爲何要作這個工做。首先，一個業務剛成立時，咱們基本上會給到單機多實例的架構。也就是說，在物理機上面選擇其中一個數據庫實例去用（通常狀況下一個物理機建立5-8個數據庫實例），隨着業務不斷地發展，咱們會彈性擴到物理機上面，若是物理機還不能知足它的訪問需求，咱們會經過CDS和SS去作水平的拆分。
經過巡檢，經過容量評估，咱們基本上可以快速定位數據庫服務器資源使用狀況，接下來基於這些信息咱們能夠在備戰的時候清楚要作的事情，例如要優化哪些東西，是否是要作架構的調整等等。
三、優化改造
在自動化性能展現平臺裏面包含了優化的功能，SQL的優化是作一系列的採集分析，給用戶優化建議，用戶經過優化建議能夠自動去作索引的添加或者SQL改寫的工做。
配置優化也是，有些業務的數據庫配置須要作一些動態的調整，好比說作一些促銷活動時，某些數據庫的參數須要微調，這個時候經過配置優化功能就可以快速地實現。
數據優化這部分在整個備戰過程當中消耗DBA的精力很是大，由於不管是數據的歸檔仍是數據結構的變動，效率和時長都是很是長的。
好比說把7T的服務器裏面30%的數據挪到另一臺機上面去，這個過程不可以一次性操做完成，要一點點去作，並且還要考慮數據庫的性能，中間可能會有停頓。咱們的數據庫歸檔平臺和數據庫變動平臺就是能夠在數據庫高併發過程當中進行有效的管控操做節奏。
架構的優化，r2m是咱們內部Redis集羣，Hcenter就是HBase的集羣。經過這種途徑添加r2m緩存，添加MQ消息隊列，把一些OLAP的查詢挪到大數據上面去。代碼這個層面的優化主要是基於前面巡檢分析進行業務邏輯優化，好比說對一些事務要有邏輯的控制。以及關鍵接口添加降級熔斷開關。
下圖是擴縮容的邏輯圖，在咱們自動化平臺實現全部環節步驟。把DBA的運維思想融入到自動化平臺裏面去。好比說你在作擴容的時候，究竟是提升硬件服務器的配置，仍是說去作垂直拆分，仍是作水平拆分。這些邏輯都有必定的規範，整個擴容和縮容準備會進入到數據遷移的過程，在數據遷移裏面會經過數據管道，相似數據複製相關的工具去幫你進行數據的搬遷，同時還會有一些數據一致性校驗的工做，最後經過數據庫切換實現縮擴容的動做。
四、數據歸檔
數據歸檔，有兩個比較核心的點：
第一，在歸檔時對數據庫的性能進行監控，若是性能很高或者壓力很大時歸檔須要暫停。
第二，歸檔對冷熱數據有很清晰的劃分，這個也是根據SQL審計得來的，平常SQL訪問都落在哪一個區域以內，經過分析咱們能知道數據在哪裏。經過數據劃分以後，咱們就能夠指導研發在歸檔平臺去作數據歸檔的請求。
歸檔基本上有如下四大類：
第一，備份、刪除。這些數據須要保留不少年，這時只須要把數據庫作一個備份，把線上的數據刪了。
第二，歷史表。若是有足夠的空間，能夠建立一張歷史表，把歷史數據挪過去，減小業務表的數據體量，這樣能夠保證正常業務高效的訪問業務表。
第三，歸檔庫。根據用戶歸檔的規則，把歷史數據挪到另一個歸檔庫裏面去。
第四，大數據平臺。這個歸檔平臺也能夠作ETL抽取工做，能夠把這些數據挪到大數據平臺裏面去。
五、壓力測試
壓測很簡單，就是經過壓測演練去尋找應用層面、緩存、數據庫自己，以及應用接口是否有異常狀況。基於預估的峯值壓力，以及大促熱點活動進行有針對性的壓測。
六、切換演練
切換演練，這是網絡公司每月都要進行的，作這個的目的很簡單，就是爲了提高整個團隊的協做能力。由於這裏涉及到研發、數據庫、應用運維，因此進行一次演練可讓不少團隊一塊兒協做。
最主要是提高團隊應急故障的處理能力，還有作高可用系統的檢查。由於高可用系統在初始化時有可能域名綁定的是物理IP，這時再去作切換就可能會出現問題，因此有些數據庫高可用仍是須要進行檢測的。
七、變動管控
在大促以前咱們都會進行封網的操做，儘可能不讓研發上線作數據庫改動。正常的流程是研發提了一個工單，先經過自動的審覈，再通過研發總監或者經理的審覈，最後DBA審覈，全部審覈經過以後會經過自動執行模型到數據庫裏面來。
在真正大促開始的時候，咱們會在研發Leader和DBA Leader之間會加一個VP的審覈，也就是說會讓更高層級的領導去管控變動的風險。
研發提工單最怕的是什麼？他們懼怕流程不清晰、流程繁瑣、審批麻煩，要作的事情在流程上體現不清晰。DBA在審覈工單的時候最怕什麼？他們擔憂研發提交的數據源不許確、SQL語句有錯誤（尤爲是不少語句中的其中一個是錯誤的）、沒有where條件、須要回滾數據的工單。
因此基於這些痛點，咱們開發了工單自助系統，這個系統包含兩個部分，一個是流程管控，另一部分是inception自動的審覈系統。
其實咱們是不提倡在大促中間去作變動的，咱們當時有一個很是嚴重的故障，有一個SA作批量的裝機，由於有一個應用想擴容，這哥們想擴100臺虛機，在擴容的時候使用DHCP動態去分配IP，結果分配IP裏面有幾個是數據庫的VIP。你們想想，這個動做一旦真的執行下去，會產生很嚴重的問題，因此經過工單流程，咱們仍是能作一些管控的。
3、618進行時
在大促零點峯值到來以前，咱們會作一些操做：第一，關閉數據庫半同步，提升數據庫的讀寫性能；第二，關閉全部的數據庫信息採集。
咱們要確保在大促峯值壓力過程當中，不會出現備份、ETL抽取、數據推送和業務跑批等沒必要要的IO壓力。總的目標就是保證業務峯值的io容量。固然這樣操做一樣是有必定風險和代價的。好比核心業務數據的一致性風險、備份恢復時間長、任務跑批延後等。
618當天咱們更多的是經過監控大盤去了解全部系統的運行狀態。如圖所示，數據是以業務的視角進行展現的，每個框都是數據庫集羣，業務研發人員經過這樣的監控大屏能夠看到全部數據庫的指標。若是他看不懂能夠看水位圖，若是整個集羣壓力到達像右上角紅色的部分那樣的程度，則說明有問題。
DBA要關注每一臺機器的性能，0點時刻咱們把上圖稱爲「大促心跳」，全部的壓力會直線上升，經過這個圖能夠看到哪一個機器是異常的，哪一個沒有內心預期的壓力大。哪些機器的性能波動不在預期範圍以內，這些是咱們以後要覆盤、總結的地方。
還有真的出現故障的時候，下圖是性能分析的頁面。也就是說，從頁面層面和問題解決層面，咱們有三種不一樣的視角監控數據庫的狀態。
在應急預案保障方便，咱們在大促以前都作了梳理，硬件層面、性能故障、服務組件故障，無論哪一個層面出現問題，咱們都有相應的應急手冊作指導，規範運營人員的應急操做。
大促結束以後咱們又作了事件的管理，把大促備戰和618當天發生的事件和故障記錄了下來，這個是記錄的維度。這個系統最主要的目的是尋求故障解決方案，把故障完全地分析一遍，經過業務的層面、架構、運維的視角，再結合安全和合規的要求，尋求最合理的優化改造方案，並持續跟蹤改形成果。
4、案例分析
案例一
給你們分享兩個例子，第一個例子，有一個數據庫，由於擴容的緣由主庫後面掛了15個從庫，真正在大促0點那一刻這個數據庫讀寫性能很是慢，後來通過分析，咱們發現就是這15個從庫在向主庫獲取日誌的時候對主庫壓力太大了，因此當時的解決方案是關閉了幾個不過重要的從庫，把主從複製斷開。
這個事情經過覆盤咱們仍是找出不少可以改進的點。
第一，在數據庫架構裏要嚴格控制從庫的數量，超過5個之後，咱們就要用級聯複製的方式或者dbrep作複製。
第二，在擴容以後研發要作二次的壓測了。若是當時進行壓測的話，是可以發現主庫性能降低的故障問題的。
第三，自動化分析系統爲何當時沒有識別這個故障？就是由於對這個複製用戶產生的訪問壓力，咱們自動化性能分析平臺把它給忽略了，這一點要在之後自動化雲平臺上去添加自動識別的異常，若是它的併發進程過多也是有一個異常。
第四，自愈，這個問題解決方法就是要殺掉幾個從庫。當時咱們DBA仍是很糾結的，15個從庫可能對應着不一樣的業務接口，關閉哪個從庫，當時咱們仍是討論了很長時間。如何實現自愈呢？咱們把全部的業務，全部接口按照一個業務等級去作一個排序，把等級低的直接關閉，這就不須要跟研發溝通了。
第五，資源擴容的時候要有一個數量的提醒。
第六，應用接口增長容錯機制。當時咱們關了幾個從庫，關閉以後應用接口就瘋狂地報錯，致使後面的一系列應用也出現了問題。雖說沒有影響到終端用戶，可是咱們認爲接口要增長容錯的機制，也就是說針對數據庫掛掉的時候，應用可以有一個降級的邏輯。
案例二
第二個案例，在619你們都已經開了慶功宴，有的人都喝香檳去了，咱們DBA在619零點十八分作了一個操做，就是打開半同步。剛纔講了，大促以前要關閉半同步，要提高主庫性能。咱們認爲大促已經結束了該把半同步打開，結果打開一瞬間觸發了一個bug，數據庫重啓了。
但咱們過後分析這個故障，咱們發如今兩階段提交的最後一個階段，這個過程分爲三個步驟，第一個Flush Stage，第二個Sync Stage，第三個Commit Stage。在flush stage環節會把數據寫到Binlog緩衝裏面去，在Sync Stage裏面會把全部Binlog刷盤，第三個是根據順序的調用存儲引擎提交事務，這個就是Binlog寫磁盤的操做邏輯。
整個過程當中跟半同步有什麼關係呢？後來咱們分析了一下源碼，也找了一些資料，發如今第一階段，半同步在打開的時候，每個事務會往active transaction這hash表裏記錄提交事務的name、pos和entry標識，緩存這些信息的目的是在發送binlog時判斷要不要等從庫返回的ACK。這個entry的意義就是告訴從庫這個event須要返回ACK，實際上就是供從庫去判斷要不要返回ACK應答的標識。若是從庫在收到binlog的時候發現有entry值，就會返回ACK應答，若是沒有它就不返回。
在第二個階段設置binlog的相對位置，就是設置一個等待ACK返回的binlog值和pos點。若是從庫返回的ACK裏面包含的內容和pos點比等待的值要大，那說明這個事務就能夠提交了，若是小的話就不能提交。恰好咱們DBA就在這個階段半同步打開了操做。
這個時候你們能夠想象一下，在flush階段有一條數據寫入了，寫入的時候active transaction這張表裏是沒有entry標識的。在第二個階段——Sync Stage階段，從庫由於沒有標識，因此就不會返回ACK。可是主庫由於識別了sync_master_enabled這個變量，因此它認爲這個事務應該等ACK的返回，結果從庫沒有返回ACK,主庫又一直都在等，因此出現了assertion failure的錯誤。
其實這個錯誤也很簡單，在改寫的時候，這個bug只須要同時驗證enable和entry這兩個值，若是都有的話纔會去等待ACK的反饋。咱們查詢官網的資料後發現5.6.35，5.7.17，8.0.1之後的版本都解決了這個問題。
經驗總結
最後是經驗的總結，好的地方不說了，說一下咱們須要改進的地方。
① 容災演練
咱們常常作的演練都是模擬主從切換，但對於極端的場景咱們是沒有測到的。這些極端的場景如何去作演練？這些是咱們從此要注意的地方。
② 性能優化
性能優化這部分要解決的問題也不少，咱們要多從業務視角指導研發去作優化任務，在優化過程當中還須要改進。
③ 數據治理
數據治理就是數據冷熱的分離，這樣可以對數據庫進行保護和容災。但冷熱數據的界定還須要更加的靈活和準確。
④ 資源管控
資源管控能夠幫咱們作架構和資源合理性評估，可能之後互聯網公司會更加註重硬件資源的使用率，服務器採購會愈來愈少，如何在有限資源裏把架構設計得更加優化，這些方面須要考慮。
⑤ 業務優化
咱們的DBA仍是要多深刻到業務層面，幫助研發減小業務邏輯在數據庫層面的交互次數，簡化事務邏輯。同時提出降級熔斷的方案。幫助研發打造健壯的業務系統體系。
PPT連接：https://pan.baidu.com/s/1DdHBbQq-uLFyyUuqxmP4qw
> > > >
活動推薦
2020 Gdevops全球敏捷運維峯會將在北京開啓年度首站！重點圍繞數據庫、智慧運維、Fintech金融科技領域，攜手阿里、騰訊、螞蟻金服、中國銀行、平安銀行、中郵消費金融、建設銀行、農業銀行、民生銀行、中國聯通大數據、浙江移動、新炬網絡等技術表明，展望雲時代下數據庫發展趨勢、破解運維轉型困局。