<b>摘要：</b>從傳統it部署到雲，人肉運維已經是過去式，雲上運維該怎麼開展？人工智能對于運維“威脅論”也随之襲來，如何去做更智能的活，當下很多運維人在不斷思考和探尋答案。在2017雲栖社群運維/devops線上技術峰會上，阿裡雲資料庫技術專家喜樂就為大家分享了對于雲資料庫的選型的考量和雲資料庫的使用經驗以及對于雲資料庫未來的展望，精彩不容錯過。
<b>以下内容根據演講視訊以及ppt整理而成。</b>
<b>演講者簡介：</b>
喜樂，阿裡雲資料庫技術專家，2010年加入阿裡巴巴，最近四年時間一直在資料庫技術組，專注于雲資料庫的業務和架構。
本次分享主要分為以下四個部分：
一、背景
二、雲資料庫架構選型
三、雲資料庫的使用經驗談
四、展望未來
<b>一、背景</b>
近幾年，devops一直都是一個特别火的話題，devops旨在将開發、線上部署、運維、品質控制以及技術營運等全部工作都整合在一個團隊裡，通過團隊成員之間的緊密配合實作産品的快速疊代。曾經有的技術團隊做到了在一天之内釋出産品10次以上，如果技術團隊擁有了devops的能力之後，這個團隊的産品就能夠實作線上上進行快速疊代，也就能夠适應網際網路飛速發展環境下的業務需求。
本次分享的主題主要與資料庫相關，将主要為大家介紹作為一名開發人員需要掌握哪些最關鍵的資料庫技術點，希望本次的分享能夠為大家在架構的設計、線上運維以及問題的排查等方面提供一些幫助和指導，也希望大家能夠通過學習資料庫技術進一步提升自己的devops能力。
<b>二、雲資料庫架構選型</b>
如今包括企業級産品在内的網際網路産品越來越豐富，傳統的資料庫産品隻有oltp和olap的，但是在未來資料庫産品會越來越多樣化。目前的阿裡雲的資料庫産品也已經非常豐富了，可以提供比如像傳統的mysql、sql server、pg、hbase、redis以及mongodb等資料庫産品，而且如果單機無法存儲全部資料還會提供資料庫分片技術。目前，資料庫的形态越來越多，是以大家可能在資料庫的選型上會産生一些困惑，本次分享會為大家介紹一些與資料庫選型相關的知識，鍊路的形态、安全性、可靠性、易用性、還有應用的架構和業務的類型，這些方面都會影響大家對于資料庫選型的考量。
阿裡雲能夠提供多種類型的雲資料庫。接下來首先介紹一下資料庫架構三種最基本的形态，下圖中最左邊是一種傳統的主備架構，這種架構采用的都是本地存儲的方式而非共享存儲，前面會使用lvs。對于這種架構而言，在通常情況下，使用者隻會連接配接到主資料庫上，而備庫采用熱備的方式進行實時地資料同步。
上圖中的第二種形态是一個三節點的資料庫架構，相比第一種架構，這裡面加入了一個hidden節點。在雙節點時通過mysql具有的半同步機制基本上可以做到資料不丢失，但是在極端的情況下，比如在網絡和主機同時故障的時候或者備庫存在延遲的情況下，資料可靠性就可能得不到保證。當使用了三節點之後，主庫寫入任何一條資料時，都要讓事務傳入到其中的一個備庫上，之後才能夠傳回給使用者，這樣就保證了資料一定是在兩個節點同時寫入的，這就是三節點的最基本模型。當然這個模型還可以擴充成為五節點、七節點這樣的模型，以前的一些分布式資料庫就是依靠這樣的模式來實作的，這樣能夠在出現資料庫的單點故障時保證資料的零丢失。
上圖中的第三種形态是一種共享存儲的資料庫架構，通常情況下隻存在一個主資料庫，後面存在多個備庫，但是中間的存儲卻隻有一份，主備資料庫都将資料寫到共享存儲上。當然對于共享存儲而言，一般也會存儲三份。這種架構和前面提到的第二種架構的差别在于：在第二種架構方式中，當切換到備庫之後，就直接基于備庫本地存儲的資料對外提供服務，而第三種架構則是使用原來的共享存儲，實際上還是原來那份存儲提供服務，這就會涉及到對于日志進行應用，是以會需要多花費一些時間，但是上面master和slave節點的伺服器實際上是無狀态的，這樣的架構下所能提供的資料可靠性就會更強一些。這三種架構目前已經應用于mysql、sql server、pg、redis、mongodb這幾種基礎的資料庫中了。
下圖的架構就是redis sharding的結構，顧名思義其就是一種分片的結構。大家可以看到圖中存在proxy節點也就是mongos中間節點，其下面則是剛才提到的主備的結構。所有的資料都會按照一種分片的規則路由到下面的某一個分片上來提供服務，而路由的規則則會存儲在一個元件上，這就是一種典型的分片結構。這裡的結構在前面隻加了一個lvs，是以整個sharding隻有一個vip。
下圖是mongodb sharding的結構，當資料量超過單機的承受能力之後，往往需要進行橫向的擴充，此時就可以采取這樣的sharding結構。其下面的每一個分片都是之前提到的三節點的結構形态，通過多個mongos将他們組合起來，每一個mongos前面都會架設一個vip，也就是說使用者購買了這樣的mongodb sharding之後會拿到多個vip，這樣在使用上就會更加靈活。
<b>三、雲資料庫使用經驗談</b>
接下來就為大家分享關于雲資料庫使用方面的經驗之談。對于雲資料庫的使用而言，如果想要做到安全，穩定又可靠，其實存在很多關鍵點，其中比較重要的就如同下圖中所列舉出來的這些點：應用資料源配置、報警配置、可運維時間選擇、慢sql監控及優化、參數選擇、主備資料庫之間的同步方式、資料備份、日志備份、賬戶管理、存儲架構、網絡安全以及架構安全等，在後面将會為大家進行更加詳細的介紹。下圖中左邊的是整個系統從底層的硬體和作業系統一直到最上面的應用系統的分層結構。今天主要分享的就是資料庫的服務，相應的就是紅框裡這部分，也就是應用架構到資料庫服務這兩層之間的部分，這裡就涉及到設計、優化以及配置。
<b>應用資料源配置</b>
關于應用資料源配置，首先建議所有應用系統在使用雲資料庫時要使用長連接配接，這樣應用程式就能夠使用連接配接池，使用長連接配接的消耗最小并且不必每次都建立連接配接。其次就是應用程式應該能夠自動進行重連，也就是說當網絡發生變更的時候或者當資料庫的主庫發生故障發生自動切換的時候，如果應用程式具有自動重連的機制就可以做到在幾秒之内自動重新連接配接到新的資料庫上，這樣對于應用程式的影響也會是最小的，是以應用程式一定要能夠進行自動重連。第三個建議就是對于連接配接池逾時的配置，這部分至少需要連接配接逾時、socket逾時這兩個配置，連結逾時指的是判斷首次進行tcp三次握手的時候發出ack包的回包有沒有逾時；socket逾時是指在建立連接配接之後，在向雲資料庫發送資料之後逾時了，沒有得到任何的回包，這有可能是在資料包發送的途中連接配接斷開了，也有可能是資料包已經到達server了，但是server回包時逾時了，這兩種情況都可能造成socket逾時。其實對于像java這樣比較成熟的語言而言，會具有像jdbc這樣的驅動，還可能存在sql statement逾時。sql statement逾時不是資料庫本身提供的，一般情況下是由用戶端自己完成的，因為資料庫采用的都是停等協定，當用戶端給資料庫發送一個sql之後就會阻塞在這裡，如果當sql發出去了，到一定時間還沒有傳回sql的查詢結果，用戶端就會再啟動一個線程向資料庫發送一個kill的指令将之前的那個連接配接殺死，中間的這段時間就需要通過sql statement逾時來進行設定。
另外，所有應用用戶端連接配接池的最大連接配接數總和應小于資料庫的最大連接配接數。通常情況下，可能會存在很多個應用連接配接資料庫，這些應用去連接配接資料庫時都會設定自己連接配接池的最大連接配接數，如果當所有的應用所設定的連結總數大于資料庫所設定的最大連接配接數，就會發生将資料庫的連接配接撐爆的情況。超過最大連接配接數之後再請求的連接配接就會被資料庫伺服器拒絕，這就會對于應用造成很大的傷害，是以推薦在實作用戶端時或者開發同學在配置連接配接池時一定要保證用戶端連接配接池的最大連接配接數總和小于資料庫最大連接配接數。有的雲資料庫可以将連接配接數作為購買項進行設定的，也有的需要通過對于資料庫參數的調整進行設定，大家需要根據自己所使用的資料庫進行設定。
除此之外，如果應用能統計業務sql的執行頻率及執行時間的監控資料那就最好不過了。通常情況下按照三層設計的dao層就是專門負責連接配接資料庫的，希望大家能夠對于這一層的代碼進行切面，無論使用單個資料源還是多個資料源，都應該對于所有關于資料庫的操作都要統計sql執行頻率和執行時間的監控資料，這樣當每次進行應用釋出的時候，如果增加或者修改了sql就可以及時得到該條sql線上上真正運作時的執行效果，這樣對于應用問題的排查也會起到非常大的幫助。對于淘寶和天貓而言，都會有非常成熟的資料庫執行頻率和執行時間的監控，是以建議大家在開發自己的應用時也設計實作這樣的子產品，并且目前也已經出現了很多比較成熟的第三方庫能夠實作這些功能。
上圖所展示的是dns通路登到ecs上，ecs通過虛拟ip連接配接到資料庫的一個資料鍊路。這是通常情況下的資料鍊路，除此之外還有一種proxy鍊路，也叫作高安全鍊路，也就是在slb後面會架設一個中間層proxy。
<b>報警配置</b>
對于報警配置而言，其實雲監控已經能夠設定很多的報警了，但是通過資料統計發現通常情況下大家都不太關心這部分，這是不應該的。無論使用的是哪一個雲資料庫都應該在雲監控上設定自己的報警，因為有一些閥值是根據應用的壓力進行調節的，比如通常情況下，資料庫伺服器的壓力是cpu可以跑到50%，那麼可以設定閥值為70%，如果在某一次應用釋出之後cpu的占用率一下子就大幅度上升了，此時給開發人員發一條短信或者報警就能夠幫助開發人員及時發現線上資料庫存在的潛在問題。
報警和監控其實分為兩部分，一部分監控的資料采集包括了很多名額，比如cpu、記憶體、磁盤io以及各種資料庫引擎特殊的屬性，這些名額希望大家都能夠關注，因為監控已經将這些名額從曲線上拉取出來了，如果在名額的監控曲線上看到存在巨幅波動，一定是出現了應用系統的變更或者資料庫的配置有所變更，這樣大家就能夠對于資料庫性能上的名額有所了解。另外一個就是報警，當資料庫存在問題的時候，可能最多是性能或者故障問題，大家可以及時收到報警的資訊，不至于造成很大的損失。
除了上面所說的，還應該設定日志的管理，這裡面包含了sql日志和慢日志。sql日志就是通常在資料庫上執行的增删改查的sql，如果開啟了sql審計就會将這些資料都統計下來；慢日志則是将應用連接配接上去之後根據大家設定的慢sql的閥值而統計出來的運作稍慢的sql，對于這些運作稍慢的sql都是需要進行優化的。一些sql需要運作數分鐘甚至一個小時，這樣的sql對于資料庫而言不是正常的，除非開發同學認為這條sql是分析性的sql，但是對于通常的oltp的應用，是不應該出現需要運作數分鐘甚至數小時的sql的。除了之前所提到的診斷工具之外，阿裡雲還提供了執行個體診斷報告、資源分析以及sql分析的服務。執行個體診斷報告其實是非常有用的，建議開發同學能夠進行診斷，這樣就能在診斷報告中展現出應用釋出之後的全部影響，而且診斷報告中會對于重點的一些問題進行标記，比如cpu、記憶體以及io等等，如果判定為不正常就會标紅來提醒開發人員，減少了開發過程中的診斷工作。
<b>可維護時間</b>
剛剛接觸資料庫的同學可能不太了解可維護時間這個概念，其實可維護時間和之前提到的鍊路是緊密相關的，通常情況下即使自己搭建資料庫，也會出現資料庫損壞、更新、重新開機或者網絡需要進行變更的時候，這個時候連接配接一定會斷開。後端像阿裡雲這樣的雲廠商進行運維性工作的時候往往可能會導緻資料庫出現閃斷，這個閃斷的時間不可能是随時的，因為這樣對于應用的影響會比較大，是以就需要設定一個可維護時間，當客戶設定好可維護時間之後，阿裡雲就能夠保證所有的運維出現對使用者造成影響的階段都發生在可維護時間内，這樣就可以盡量降低維護對于應用的影響。
這裡介紹一下哪些任務可能會受到可維護時間的影響，比如：
1）核心小版本更新
2）機器損壞遷移
3）主庫不可用主備切換
4）網絡切割，變更
其實這裡面最主要影響到了vip，也就是lvs到後端的rs也就是實體機的ip之間的對應關系，而且更換vip時也需要在可維護時間内執行。
<b>慢sql監控以及優化</b>
對于慢sql而言，應該如何進行分析和優化呢？其實可以從這樣的幾個角度進行考慮。
目前使用量最大的是mysql資料庫，mysql的引擎有innodb和myisam，建議使用innodb引擎，一方面，這是因為myisam殷勤在進行主備複制時無法保證事務，這樣就有可能導緻中斷；除此之外，myisam在主庫進行備份的時候會進行鎖表，這樣就會影響使用者應用的通路。另一方面，阿裡雲對于innodb的核心也進行了更新，并且增加了自增主鍵id，也就是将一個隐式列當做主鍵，當開發的同學不去設定這個主鍵時就會增加一個隐式的主鍵。建議大家對于每一張表都建立一個合理的索引和主鍵，這裡面就會涉及到大家需要做執行計劃，當拿到一條sql語句後，大家可以解釋一下看看其執行計劃是什麼。如上圖所示的是一條pg的執行計劃，在其中可以清楚地看到這條sql中使用了哪些操作，從其中可以看到這條sql到底壞在哪裡。當然大家也可以購買雲服務來實作這樣的分析。
<b>賬戶管理和鍊路安全</b>
隻要是涉及到鍊路的内容都是非常重要的，當使用者購買完阿裡雲的資料庫服務之後，所有的白名單都是禁止通路的，希望大家能夠自定義地設定ip的白名單。隻有在設定了白名單之後才能繼續使用服務，不建議大家一律都設定成為可通過，因為這樣是極其不安全的。
除此之外，當大家使用了ecs去連接配接資料庫，這裡面就會存在一個ecs安全組的概念，當将一些ecs劃歸到安全組裡面之後，後面如果在資料庫中設定了安全組就會把ecs的ip同步到資料庫中來。目前ecs安全組同步到雲資料庫這樣的功能也即将上線，這樣就能夠解決每次購買ecs之後加減ip達到麻煩。
其實最推薦大家使用vpc網絡，因為使用了vpc網絡就可以與其他的所有使用者的服務從網絡上隔離開來。第三點建議就是對于賬戶數量以及資料庫的數量進行控制，很多雲使用者使用了很多的賬戶和資料庫，而這樣的做法不是一種很好的做法，因為當賬戶很多之後，一個資料的權限就會呈指數地向上增長，因為每個賬戶或者每個db都能有權限，并且權限還可能各不相同。當執行刷權限操作時就會消耗很長的時間，這樣對整個資料庫的使用而言是非常不利的，這裡推薦大家更新到mysql 5.6版本，當然目前絕大多數使用者也都是使用的mysql 5.6了，如果還沒有更新的話希望大家盡快完成資料庫更新，這樣就可以享受到超級權限賬戶的功能了，這樣其餘的子賬戶都可以由這個超級賬戶派生出來，而不需要走api的方式。另外還建議每個業務應用都擁有自己的連接配接資料庫的賬戶，為什麼要有這個限制呢，其實是希望通過這樣做，讓大家在分析資料庫上的連接配接和sql的時候能夠知道這條sql來自哪個賬戶和應用，而不是隻能夠知道這條sql來自的ip位址。
<b>資料備份，日志備份</b>
資料和日志的備份都是非常重要的，因為給線上資料庫提供服務就是上述提到的與鍊路相關的事情，而其實在一種比較極端的情況下，比如購買了兩節點或者三節點的資料庫後，如果真的發生了災難性故障的時候還會有一份離線的資料，那麼通過離線的資料就能夠恢複到日志已經上傳到oss上的最近的時間點，是以需要及時檢查雲資料庫上的資料備份和日志備份是否有效，還可以适時地執行一次資料恢複來試一下資料能否正常地恢複回來，這無論是對于一個應用還是對于一家企業而言，都是非常核心的任務。
除了定期檢視備份是否正常，還需要關注備份檔案的大小。當資料庫存儲的資料量非常大的時候，比如單機資料量達到幾個t之後，進行一次資料備份的時間就會非常的漫長，很有可能出現備份逾時或者出現了其他的問題，是以對于資料量特别大的應用一定要經常檢查自己的資料備份是否是正常的，而當阿裡雲發現一些使用者的資料備份不正常時也會及時提醒使用者。這裡的一個關鍵點就是防止binlog重新整理過快，線上的一些binlog重新整理是很快的，比如1分鐘一個500m的binlog，對于這樣的應用就應該反思使用的資料庫是否合适了。因為對于oltp這樣的應用而言，不應該存在大量的插入操作，如果存在大量的插入操作而查詢和更新操作很少，這樣的應用應該使用像hbase這樣的資料庫，而不應該使用事務型的資料庫。如果存在大量的資料更新就應該考慮是不是應該使用緩存、緩沖或者異步系統等，在應用級别想辦法而不是把所有的資料更新都塞到資料庫裡讓資料庫承擔。因為每個更新都會産生binlog，如果在短時間内産生大量的binlog就會造成應用的不穩定，一旦主庫宕掉，就可能有大量的binlog積攢在本地沒有得到及時上傳，這樣在災難恢複或者主備複制時都會造成障礙，比如主庫産生了大量的binlog，備庫不能及時消費就會造成延遲，這樣當主庫故障切換到備庫上時等待恢複的時間就會非常長。這一系列都是相關聯的，是以大家應該及時檢查binlog的運作狀況。
<b>參數設定及複制方式設定</b>
對于資料庫的參數而言，比如像典型的mysql、sql server往往都有幾十個參數，而常用的參數并不多，是以建議開發同學能夠檢查自己的資料庫配置是否正确。
通常情況下，大家購買阿裡雲的資料庫服務的時候都會設定了推薦的參數，這些參數都是經過阿裡雲的精挑細選推薦給大家使用的比較合理的值。但是實際上對于雲資料庫而言，阿裡雲并不知道大家的應用對資料庫有什麼樣的特殊要求，是以不同的應用對于資料庫的參數可能有不同的影響，比如表的大小寫、某些cache的大小等都有可能影響到資料庫的性能以及使用。還有就是複制方式的選擇，現在預設都是開啟了半同步的，但是對于有些雲資料庫大家往往又會降回異步。其實對于半同步而言，其隻是将日志傳到備庫來然後給用戶端進行傳回，這樣就能夠幫助用戶端将資料的可靠性做到最好。如果使用異步，當備庫有一定延遲的時候，日志無法及時地傳到備庫中去，這樣就會少一部分的binlog。希望大家平時多注意這一點，如果一直使用異步這樣高性能的方式，在主庫挂掉之後，資料的一緻性是可能會丢失的，是以盡管絕大多數情況下都是使用的半同步，如果大家将其改成異步那麼對于這一點就一定要注意。除非對于日志類型的應用需要盡可能保證其可用性，并且要求資料能夠盡快地插入下去，而且對于資料的一緻性要求不高的情況下是可以采用異步的方式的。還有一點就是對于多可用區和單可用區的選擇，通常建議大家使用多可用區，多可用區實際上為大家做了機房級别的容災，當使用像a + b這樣的多可用區時，如果a可用區的機房挂掉了，b可用區還可以單獨提供服務，這樣就不僅僅是主機級别的故障容災了，也做到了可用區或者機房級别的故障容災，這一點使用自建資料庫的方式是很難做到的。
<b>四、雲資料庫的未來</b>
未來，阿裡雲等各大雲廠商一定會開發出更多的産品供大家進行選擇，所能夠提供的資料庫不僅僅是以前的事務型或者非事務型資料庫，未來的資料庫産品可能是五花八門的，越來越多樣化的。而雲資料庫也會變得更加易用、安全、穩定，雲資料庫的性能也會越來越高，并且将進一步提升産品的成熟度，進而為各行各業乃至全社會提供更好的資料服務。