892
什麼樣的雲數據庫架構選型才能做到安全，穩定又可靠？
摘要：從傳統IT部署到雲，人肉運維已經是過去式，雲上運維該怎麼開展？人工智能對於運維“威脅論”也隨之襲來，如何去做更智能的活，當下很多運維人在不斷思考和探尋答案。在2017雲棲社區運維/DevOps在線技術峰會上，阿裏雲數據庫技術專家喜樂就為大家分享了對於雲數據庫的選型的考量和雲數據庫的使用經驗以及對於雲數據庫未來的展望，精彩不容錯過。以下內容根據演講視頻以及PPT整理而成。
演講者簡介：
喜樂，阿裏雲數據庫技術專家，2010年加入阿裏巴巴，最近四年時間一直在數據庫技術組，專注於雲數據庫的業務和架構。
本次分享主要分為以下四個部分：
一、背景
二、雲數據庫架構選型
三、雲數據庫的使用經驗談
四、展望未來
一、背景
近幾年，DevOps一直都是一個特別火的話題，DevOps旨在將開發、線上部署、運維、質量控製以及技術運營等全部工作都整合在一個團隊裏，通過團隊成員之間的緊密配合實現產品的快速迭代。曾經有的技術團隊做到了在一天之內發布產品10次以上，如果技術團隊擁有了DevOps的能力之後，這個團隊的產品就能夠實現在線上進行快速迭代，也就能夠適應互聯網飛速發展環境下的業務需求。
本次分享的主題主要與數據庫相關，將主要為大家介紹作為一名開發人員需要掌握哪些最關鍵的數據庫技術點，希望本次的分享能夠為大家在架構的設計、線上運維以及問題的排查等方麵提供一些幫助和指導，也希望大家能夠通過學習數據庫技術進一步提升自己的DevOps能力。
二、雲數據庫架構選型
如今包括企業級產品在內的互聯網產品越來越豐富，傳統的數據庫產品隻有OLTP和OLAP的，但是在未來數據庫產品會越來越多樣化。目前的阿裏雲的數據庫產品也已經非常豐富了，可以提供比如像傳統的MySQL、SQL Server、PG、HBASE、Redis以及MongoDB等數據庫產品，而且如果單機無法存儲全部數據還會提供數據庫分片技術。目前，數據庫的形態越來越多，所以大家可能在數據庫的選型上會產生一些困惑，本次分享會為大家介紹一些與數據庫選型相關的知識，鏈路的形態、安全性、可靠性、易用性、還有應用的架構和業務的類型，這些方麵都會影響大家對於數據庫選型的考量。
上圖中的第三種形態是一種共享存儲的數據庫架構，通常情況下隻存在一個主數據庫，後麵存在多個備庫，但是中間的存儲卻隻有一份，主備數據庫都將數據寫到共享存儲上。當然對於共享存儲而言，一般也會存儲三份。這種架構和前麵提到的第二種架構的差別在於：在第二種架構方式中，當切換到備庫之後，就直接基於備庫本地存儲的數據對外提供服務，而第三種架構則是使用原來的共享存儲，實際上還是原來那份存儲提供服務，這就會涉及到對於日誌進行應用，所以會需要多花費一些時間，但是上麵Master和Slave節點的服務器實際上是無狀態的，這樣的架構下所能提供的數據可靠性就會更強一些。這三種架構目前已經應用於MySQL、SQL Server、PG、Redis、MongoDB這幾種基礎的數據庫中了。
下圖的架構就是Redis Sharding的結構，顧名思義其就是一種分片的結構。大家可以看到圖中存在Proxy節點也就是mongos中間節點，其下麵則是剛才提到的主備的結構。所有的數據都會按照一種分片的規則路由到下麵的某一個分片上來提供服務，而路由的規則則會存儲在一個組件上，這就是一種典型的分片結構。這裏的結構在前麵隻加了一個LVS，所以整個Sharding隻有一個VIP。
三、雲數據庫使用經驗談
接下來就為大家分享關於雲數據庫使用方麵的經驗之談。對於雲數據庫的使用而言，如果想要做到安全，穩定又可靠，其實存在很多關鍵點，其中比較重要的就如同下圖中所列舉出來的這些點：應用數據源配置、報警配置、可運維時間選擇、慢SQL監控及優化、參數選擇、主備數據庫之間的同步方式、數據備份、日誌備份、賬戶管理、存儲架構、網絡安全以及架構安全等，在後麵將會為大家進行更加詳細的介紹。下圖中左邊的是整個係統從底層的硬件和操作係統一直到最上麵的應用係統的分層結構。今天主要分享的就是數據庫的服務，相應的就是紅框裏這部分，也就是應用架構到數據庫服務這兩層之間的部分，這裏就涉及到設計、優化以及配置。
應用數據源配置
關於應用數據源配置，首先建議所有應用係統在使用雲數據庫時要使用長連接，這樣應用程序就能夠使用連接池，使用長連接的消耗最小並且不必每次都建立連接。其次就是應用程序應該能夠自動進行重連，也就是說當網絡發生變更的時候或者當數據庫的主庫發生故障發生自動切換的時候，如果應用程序具有自動重連的機製就可以做到在幾秒之內自動重新連接到新的數據庫上，這樣對於應用程序的影響也會是最小的，所以應用程序一定要能夠進行自動重連。第三個建議就是對於連接池超時的配置，這部分至少需要連接超時、socket超時這兩個配置，鏈接超時指的是判斷首次進行TCP三次握手的時候發出ACK包的回包有沒有超時；socket超時是指在建立連接之後，在向雲數據庫發送數據之後超時了，沒有得到任何的回包，這有可能是在數據包發送的途中連接斷開了，也有可能是數據包已經到達Server了，但是Server回包時超時了，這兩種情況都可能造成socket超時。其實對於像Java這樣比較成熟的語言而言，會具有像JDBC這樣的驅動，還可能存在SQL Statement超時。SQL Statement超時不是數據庫本身提供的，一般情況下是由客戶端自己完成的，因為數據庫采用的都是停等協議，當客戶端給數據庫發送一個SQL之後就會阻塞在這裏，如果當SQL發出去了，到一定時間還沒有返回SQL的查詢結果，客戶端就會再啟動一個線程向數據庫發送一個Kill的命令將之前的那個連接殺死，中間的這段時間就需要通過SQL Statement超時來進行設置。
另外，所有應用客戶端連接池的最大連接數總和應小於數據庫的最大連接數。通常情況下，可能會存在很多個應用連接數據庫，這些應用去連接數據庫時都會設置自己連接池的最大連接數，如果當所有的應用所設置的鏈接總數大於數據庫所設置的最大連接數，就會發生將數據庫的連接撐爆的情況。超過最大連接數之後再請求的連接就會被數據庫服務器拒絕，這就會對於應用造成很大的傷害，所以推薦在實現客戶端時或者開發同學在配置連接池時一定要保證客戶端連接池的最大連接數總和小於數據庫最大連接數。有的雲數據庫可以將連接數作為購買項進行設置的，也有的需要通過對於數據庫參數的調整進行設置，大家需要根據自己所使用的數據庫進行設置。
除此之外，如果應用能統計業務SQL的執行頻率及執行時間的監控數據那就最好不過了。通常情況下按照三層設計的DAO層就是專門負責連接數據庫的，希望大家能夠對於這一層的代碼進行切麵，無論使用單個數據源還是多個數據源，都應該對於所有關於數據庫的操作都要統計SQL執行頻率和執行時間的監控數據，這樣當每次進行應用發布的時候，如果增加或者修改了SQL就可以及時得到該條SQL在線上真正運行時的執行效果，這樣對於應用問題的排查也會起到非常大的幫助。對於淘寶和天貓而言，都會有非常成熟的數據庫執行頻率和執行時間的監控，所以建議大家在開發自己的應用時也設計實現這樣的模塊，並且目前也已經出現了很多比較成熟的第三方庫能夠實現這些功能。
報警配置
對於報警配置而言，其實雲監控已經能夠設置很多的報警了，但是通過數據統計發現通常情況下大家都不太關心這部分，這是不應該的。無論使用的是哪一個雲數據庫都應該在雲監控上設置自己的報警，因為有一些閥值是根據應用的壓力進行調節的，比如通常情況下，數據庫服務器的壓力是CPU可以跑到50%，那麼可以設置閥值為70%，如果在某一次應用發布之後CPU的占用率一下子就大幅度上升了，此時給開發人員發一條短信或者報警就能夠幫助開發人員及時發現線上數據庫存在的潛在問題。
報警和監控其實分為兩部分，一部分監控的數據采集包括了很多指標，比如CPU、內存、磁盤IO以及各種數據庫引擎特殊的屬性，這些指標希望大家都能夠關注，因為監控已經將這些指標從曲線上拉取出來了，如果在指標的監控曲線上看到存在巨幅波動，一定是出現了應用係統的變更或者數據庫的配置有所變更，這樣大家就能夠對於數據庫性能上的指標有所了解。另外一個就是報警，當數據庫存在問題的時候，可能最多是性能或者故障問題，大家可以及時收到報警的信息，不至於造成很大的損失。
可維護時間
剛剛接觸數據庫的同學可能不太了解可維護時間這個概念，其實可維護時間和之前提到的鏈路是緊密相關的，通常情況下即使自己搭建數據庫，也會出現數據庫損壞、升級、重啟或者網絡需要進行變更的時候，這個時候連接一定會斷開。後端像阿裏雲這樣的雲廠商進行運維性工作的時候往往可能會導致數據庫出現閃斷，這個閃斷的時間不可能是隨時的，因為這樣對於應用的影響會比較大，所以就需要設置一個可維護時間，當客戶設置好可維護時間之後，阿裏雲就能夠保證所有的運維出現對用戶造成影響的階段都發生在可維護時間內，這樣就可以盡量降低維護對於應用的影響。
1）內核小版本升級
2）機器損壞遷移
3）主庫不可用主備切換
4）網絡切割，變更
其實這裏麵最主要影響到了VIP，也就是LVS到後端的RS也就是物理機的IP之間的對應關係，而且更換VIP時也需要在可維護時間內執行。
慢SQL監控以及優化
對於慢SQL而言，應該如何進行分析和優化呢？其實可以從這樣的幾個角度進行考慮。
賬戶管理和鏈路安全
隻要是涉及到鏈路的內容都是非常重要的，當用戶購買完阿裏雲的數據庫服務之後，所有的白名單都是禁止訪問的，希望大家能夠自定義地設置IP的白名單。隻有在設置了白名單之後才能繼續使用服務，不建議大家一律都設置成為可通過，因為這樣是極其不安全的。
其實最推薦大家使用VPC網絡，因為使用了VPC網絡就可以與其他的所有用戶的服務從網絡上隔離開來。第三點建議就是對於賬戶數量以及數據庫的數量進行控製，很多雲用戶使用了很多的賬戶和數據庫，而這樣的做法不是一種很好的做法，因為當賬戶很多之後，一個數據的權限就會呈指數地向上增長，因為每個賬戶或者每個DB都能有權限，並且權限還可能各不相同。當執行刷權限操作時就會消耗很長的時間，這樣對整個數據庫的使用而言是非常不利的，這裏推薦大家升級到MySQL 5.6版本，當然目前絕大多數用戶也都是使用的MySQL 5.6了，如果還沒有升級的話希望大家盡快完成數據庫升級，這樣就可以享受到超級權限賬戶的功能了，這樣其餘的子賬戶都可以由這個超級賬戶派生出來，而不需要走API的方式。另外還建議每個業務應用都擁有自己的連接數據庫的賬戶，為什麼要有這個限製呢，其實是希望通過這樣做，讓大家在分析數據庫上的連接和SQL的時候能夠知道這條SQL來自哪個賬戶和應用，而不是隻能夠知道這條SQL來自的IP地址。
數據備份，日誌備份
數據和日誌的備份都是非常重要的，因為給在線數據庫提供服務就是上述提到的與鏈路相關的事情，而其實在一種比較極端的情況下，比如購買了兩節點或者三節點的數據庫後，如果真的發生了災難性故障的時候還會有一份離線的數據，那麼通過離線的數據就能夠恢複到日誌已經上傳到OSS上的最近的時間點，所以需要及時檢查雲數據庫上的數據備份和日誌備份是否有效，還可以適時地執行一次數據恢複來試一下數據能否正常地恢複回來，這無論是對於一個應用還是對於一家企業而言，都是非常核心的任務。
除了定期查看備份是否正常，還需要關注備份文件的大小。當數據庫存儲的數據量非常大的時候，比如單機數據量達到幾個T之後，進行一次數據備份的時間就會非常的漫長，很有可能出現備份超時或者出現了其他的問題，所以對於數據量特別大的應用一定要經常檢查自己的數據備份是否是正常的，而當阿裏雲發現一些用戶的數據備份不正常時也會及時提醒用戶。這裏的一個關鍵點就是防止binlog刷新過快，線上的一些binlog刷新是很快的，比如1分鍾一個500M的binlog，對於這樣的應用就應該反思使用的數據庫是否合適了。因為對於OLTP這樣的應用而言，不應該存在大量的插入操作，如果存在大量的插入操作而查詢和更新操作很少，這樣的應用應該使用像HBASE這樣的數據庫，而不應該使用事務型的數據庫。如果存在大量的數據更新就應該考慮是不是應該使用緩存、緩衝或者異步係統等，在應用級別想辦法而不是把所有的數據更新都塞到數據庫裏讓數據庫承擔。因為每個更新都會產生binlog，如果在短時間內產生大量的binlog就會造成應用的不穩定，一旦主庫宕掉，就可能有大量的binlog積攢在本地沒有得到及時上傳，這樣在災難恢複或者主備複製時都會造成障礙，比如主庫產生了大量的binlog，備庫不能及時消費就會造成延遲，這樣當主庫故障切換到備庫上時等待恢複的時間就會非常長。這一係列都是相關聯的，所以大家應該及時檢查binlog的運行狀況。
對於數據庫的參數而言，比如像典型的MySQL、SQL Server往往都有幾十個參數，而常用的參數並不多，所以建議開發同學能夠檢查自己的數據庫配置是否正確。
四、雲數據庫的未來
最後更新：2017-05-19 14:33:20