一、傳統DB的瓶頸及問題
1.1、傳統數據庫的創建主要分以下幾步：
業務方&用戶和DBA申請，並附上業務量和需要的資源等信息
DBA根據需求，選擇相應的物理資源，並安裝數據庫
DBA交付數據庫，並提供數據庫連接信息如：IP、端口等
業務方&用戶初始化數據庫，導入業務數據，然後找DBA建立訪問指定庫或者表的讀寫、只讀等權限的連接賬號
如下圖：
可以看出幾乎每一步都需要DBA的參與，在業務量小的情況下，並沒有什麼問題。但是當業務增量越來越大，每天有幾十個甚至上百個數據庫申請時，DBA的負擔就會很大，而且影響業務上線速度。
1.2、數據庫爲什麼要平臺化
DBA每天都會遇到各個業務線的種種需求，每個業務線都會認爲自己的需求重要，總會催DBA儘快完成。而DBA也是人，需要時間一個個的去完成這些需求。而這些需求其實90%以上都是重複性操作，很需要一個平臺來把這些90%的重複任務用邏輯代碼來實現，讓用戶或者DBA只需要點一點按鈕就可以完成。
二、RDS發展
隨着IaaS、PaaS平臺的流行，數據庫也從傳統數據庫服務逐漸轉向了雲平臺數據庫服務化，在私有云+公有云模式下，越來越多新技術力量革新產生了更多優質化的服務。RDS做爲典型的在線數據庫雲服務，具有資源彈性伸縮，穩定性，易用性等特點。多重安全防護措施和完善的性能監控體系，並提供專業的數據庫備份、恢復及優化方案，使企業用戶能更加專注於應用開發和業務發展。爲企業帶來了成本覈算上的收益，降低綜合成本（硬件成本+管理成本）。
易用性
通過web方式管理數據庫，能夠短時間進行數據庫的快速部署，將完整的數據庫方案提供給用戶的同時，解決繁雜的數據庫維護成本，使得業務線能更高效的解決費時費力的重複性維護管理工作。
靈活性
RDS服務與用戶自身搭建的數據庫使用方式相同，對外IP+端口方式提供鏈接，能夠與雲服務內ECS、SLB、GCE等服務結合提供更好的服務。
水平擴展能力
RDS應對業務量大規模變化時，節點內能夠快速進行硬件資源調整，節點間集羣內也能快速的進行容量伸縮。有效的解決設備利用率偏低的問題，在不影響業務情況下進行動態遷移。
高可用性
RDS服務對外提供不同架構的可用性保障，在主業數據務節點失去響應能力的時候，能有相應的其他集羣節點或從節點進行業務快速切換，防止因單點造成的業務損失。
雲化
RDS服務是在原有傳統關係型數據庫服務發展的基礎上，結合目前主流的雲計算虛擬化等技術，將數據庫管理實現成一鍵式、自動化、 資源池、在線集中管理等方式，減少很多繁雜管理操作，同時能夠快速更加便捷的操作和使用數據庫。
三、樂視RDS
3.1、誕生
3.1.1、爲什麼會有樂視RDS
在日常管理傳統數據庫的時候我們遇到了很多問題，比如：
樂視這幾年快速發展的同時，業務對數據庫的需求量也是越來越大，最開始的時候業務庫還是人工或者人工+腳本的方式創建。業務緊急上線，數據庫的搭建時間就是個瓶頸。
由於安全原因或者權限問題，用戶需要緊急修改數據庫賬號密碼，但由於聯繫不到DBA，不能及時修改，可能造成數據泄露、丟失。
用戶想知道當前的數據庫狀態或者一些性能指標，而此時DBA在忙着處理線上問題，不能及時提供等等。
我們就開始思考，是不是需要作出一套樂視RDS，在業務方或者用戶需要數據庫資源的時候，只要登錄平臺輕輕一點數據庫創建按鈕，即刻使用。我們只提供基礎的數據庫服務平臺，並負責其穩定性和可靠性。而用戶有自己數據庫大部分管理權限，讓用戶對數據庫的操作脫離DBA，並且瞭解自己數據庫的實時狀態。這樣既減輕了DBA的壓力，又帶來了更高的效率。
最終樂視RDS的雛形就建立了起來，樂視RDS基於docker虛擬化可以限制硬件層（CPU、內存、磁盤io）等資源，將同屬於一個物理集羣之間資源進行隔離。有效控制資源環境穩定性並提高資源利用率。
從2014年開始我們就嘗試使用Docker容器技術，把容器作爲RDS數據庫集羣各個節點運行的基礎環境，這在國內可以說是比較早使用此種架構的互聯網公司。
3.1.2、爲什麼會選用Docker技術
我們使用Docker主要的原因有：
開源程序，可定製開發
快速部署
靈活
豐富可定製的鏡像資源
資源隔離
輕量，滿足數據庫運行環境即可，不會佔用多餘的系統資源
3.1.3、優勢何在
對應雲端的數據庫來說，其實用戶最想看到的就是，在申請完數據庫後，立刻就能使用，並自主管理，而樂視RDS完全可以滿足：
快速
穩定
可控
SSD的加入，IO不再是數據庫瓶頸
無需熱備，所有節點都在激活狀態，都爲多主結構
應用可以從集羣中任意節點進行讀寫
讀寫可水平擴展
可線上動態添加、刪除數據節點
擴展，縮減數據節點對客戶端透明
3.1.4、遇到的問題
在樂視RDS這幾年的發展過程中，其實遇到了很多的困難和問題，下面大概說幾點：
數據庫的版本和架構選型
根據雲平臺的特性，我們最終選擇了基於Percona Xtradb Cluster的數據庫集羣架構，並對其進行了一系列優化，使其在容器環境下更穩定的運行，我們內部命名爲Mcluster。
數據庫賬號權限的管控
對數據庫賬號的管控很重要，我們嚴格控制數據庫賬號的權限，使之只能在指定的權限下，幹相應的事。
數據庫物理資源隔離限制
因爲我們的數據庫基於Docker技術，所以物理資源的隔離變得尤其重要，其中也遇到了很多問題。現在我們已經可以隔離包括CPU、內存、磁盤IO等物理資源
使用入門
能更好的把用戶瞭解並熟練使用樂視RDS這其實是很難的一件事，因爲內部用戶的觀念裏還是認爲數據庫要DBA管理，不關他們什麼事。
我們經常和用戶進行交流，收集他們初次使用樂視RDS中遇到的各種問題，並完善我們的幫助中心和Web頁面使用嚮導。
備份恢復
數據庫備份重要性不言而喻，在硬件損壞、數據丟失、誤刪除等等的很多災難性的時刻，如果做了充分的備份都可以保證數據的全量恢復，最大限度的挽救丟失的數據。
由於數據庫集羣的特性，數據是冗餘三份或者更多的，備份功能我們也是經過了幾個版本的迭代，正常業務每天都會有備份，在部分重要業務上可以開啓實時備份功能。
全局數據庫性能狀態掌控
隨着數據庫的總量越來越大，對所有數據庫性能的掌控變得尤其重要，爲了實時瞭解數據庫運行狀態，我們定製了一系列的指標來完成此目的。
預警維度制定
預警維度的制定這個環節是我們最頭痛的，由於前期定製的告警維度過於敏感，導致告警量很大，對於相關運維人員來說是個噩夢。
最終經過多次討論，修改了很多不必要的預警維度，使現在的樂視RDS預警精確性大大提高。
經歷了上面的種種問題和阻礙，樂視RDS終於橫空出世。
3.2、發展和現有規模
3.2.1、樂視RDS主要發展大事記如下
樂視RDS現在主要還是給樂視集團內部各個子生態提供數據庫服務，線上已經爲900+的業務線提供數據庫服務，3000+的容器規模，樂視RDS在集團內部數據庫使用率已經達到60%以上。
3.2.2、RDS主要架構發展歷史
RDS架構1.x：單實例多Database+LVS（ 起步 ）
RDS架構2.x：PXC+Docker+Gbalancer （ 發展 ）
RDS架構3.x：(PXC or PostgreSql or MariaDB or otherDB)+Docker+Gbalancer（多元化 ）
1.x主要是 起步 階段，我們選擇在每個物理機上安裝單實例庫，並在上面創建多個database，通過LVS進行負載，但使用中發現這種架構並不適合雲平臺的理念。
2.x主要是 發展 階段，我們選擇了PXC（Perconal Xtradb Cluster）數據庫集羣，運行在Docker上，並使用Gbalancer做數據庫代理。
3.x主要是 多元化 階段，經過前面兩階段大的架構演變，我們最終的目的是把平臺當成插槽（既提供各種通用的接口）。不限於MySQL，任何數據庫都可以插到平臺上，進行創建、管理等一些列操作，爲用戶提供穩定、快捷、易維護的數據庫服務。如下圖：
3.2.3、樂視RDS爲各個子生態提供數據庫服務
樂視RDS現在已經爲樂視各個子生態提供穩定、高效的數據庫服務，並根據業務方使用中反饋的各種需求和問題，完善着樂視RDS。
3.3、樂視RDS整體構架圖
樂視RDS整體架構主要分爲以下幾大部分：
1） Database層爲具體的數據庫業務，和MySQL選擇存儲引擎一樣，Database層也秉承着可插拔特性。既可以是MySQL，也可以是PostgreSQL等任何數據庫（我們現在使用的爲MySQL）
2） Matrix層負責前端數據庫創建、管理、監控、維護和相關資源調度
3） Data Analysis層主要負責數據庫日誌的分析還有用戶行爲分析
4） BeeHive層負責組件服務的調度管理
3.4、樂視RDS基本使用示意圖
業務用戶：可以通過Matrix雲平臺對數據庫，進行創建、擴容縮絨、權限配置、性能查看、用戶資源管理等等的一系列操作。
DBA&平臺管理員：有更高的權限管理所有數據庫集羣，並可以根據收集過來的日誌分析數據庫性能、用戶行爲等等。
業務服務器：會通過本地安裝的Gbalancer中間件，來訪問相應的數據庫。
ES集羣：會收集Mcluster日誌數據、容器裏的相關日誌，以供進行業務分析。
物理資源池：根據Mcluster的配置需求，在物理資源池裏獲取相應的資源，而且當物理資源不足的時候，可以動態的添加物理服務器到物理資源池裏，來擴充整個物理資源池。
3.5、彈性伸縮
樂視RDS的彈性伸縮是基於 “大資源池的概念” ，所有物理服務器資源在整體看來其實一個大資源池，數據庫可以在這個池子裏自由的擴容、縮容、遷移。
3.5.1、彈性伸縮的主要特點
擴容&縮容
樂視RDS可以隨着業務的瞬時增長，在業務高峯時自動擴容（包括節點數量、CPU、內存、IOPS等），當度過業務高峯後，在閒時自動縮容，在保證業務穩定的同時最大限度的節省硬件資源。
平滑遷移
隨着業務量的的線性增長一定階段後，出現物理資源瓶頸，樂視RDS能在可以實現不停業務或者說用戶無感知的情況下，平滑的遷移數據庫到更高配的物理服務器上，同時保證業務的不間斷性。
3.5.2、使用場景介紹
1） 三節點的數據庫集羣已經不能滿足用戶大量併發查詢的需求，需要彈性添加數據庫節點
2） 由於物理服務器損壞，需要把物理服務器上的數據庫放到健康的服務器上
3） 單個業務量增長巨大，之前使用的數據庫集羣所在的物理機資源（比如：CPU、內存、磁盤IO等）已經不能滿足業務的要求，此時樂視RDS可以實現不停業務或者說用戶無感知的情況下，平滑的遷移數據庫到更高配的物理服務器上。
3.6、數據庫預警
數據庫預警對於提供平臺服務的我們來說，其實是很重要的一塊，如何保證數據庫出問題的時候，第一時間通知相關責任人解決故障，這是我們提供更好服務的關鍵。
目前主要使用雲平臺的RDS預警功能模塊進行數據庫預警：
3.6.1、普通級別告警
數據庫集羣未出現明顯異常，也沒有對業務造成影響，但已經超過了平臺預設的最低穩定指標，比如：數據庫讀寫超時、集羣節點間同步數據延遲等等。通過短息、微信、郵件的方式通知相關責任人，提前分析原因，並進行相應的處理措施。保證在未出現問題之前，就已經及時發現並把問題解決。
3.6.2、嚴重級別告警
數據庫集羣已經出現了明顯異常，而且對業務操作了一定的影響，比如：嚴重超時、數據庫節點或整個集羣故障等。通過電話、短息、微信、郵件所有通知途徑，告知相關責任人，及時上線解決問題，儘可能的減少因爲數據庫問題對業務造成的損失。
3.7、數據庫監控
監控系統在雲平臺RDS服務中處於舉足輕重的地位，監控系統的好壞直接決定了，RDS服務出現問題之前預測性能瓶頸，是RDS服務提供穩定服務的有利保障。
監控系統我們已經完全實現平臺化收集並查看，監控指標包括容器的各類性能指標、數據庫各種性能指標、數據庫集羣各個節點間同步狀態的監控等等。
下面大概介紹一下：
3.7.1、容器的性能監控
因爲我們是基於容器運行數據庫服務，所以容器的性能監控至關重要。通過安裝在各個物理集羣裏的agent程序，收集相關數據到Matrix平臺，收集的信息包括所有數據庫容器的CPU、內存、磁盤IO、網絡等等的使用情況，DBA會通過平臺多種維度的展現，來及時發現出現性能瓶頸數據庫容器，並優化相關數據庫服務。
下面爲Matrix平臺展現的，某個物理集羣中，讀寫消耗Top3的容器相關指標曲線圖：
3.7.2、數據庫性能監控
包括數據集羣的TPS、QPS、Innodb相關資源使用情況監控等等。下面爲平臺的部分截圖：
1) 數據庫基本運行指標
2）數據庫集羣實際read行數情況統計
3.7.3、集羣數據同步監控
根據數據庫集羣同步參數，來收集集羣各個節點間的同步狀態。下面爲平臺的部分截圖：
3.8、Gbalancer數據庫中間件
爲了保證數據庫的高可用性，雖然基於Percona Xtradb Cluster的Mcluster數據庫集羣架構可以接受多節點寫，但是在我們的實際使用中發現其在大量併發寫的情況下，會出現各種問題。
而在2014年的時候，大多數中間件不能滿足我們的需求，最終我們決定自己開發一款符合我們要求的數據庫集羣中間件。
我們開發了一款內部命名爲Gbalancer的數據庫中間件產品，Gbalancer的主要特點是輕便、高效、部署簡單，並且充分利用了Mcluster數據庫集羣特性。
通過和業務代碼的配合，其可以實現數據庫級別的高可用、負載、讀寫分離等功能。
Gbalancer的幾種主要運行模式有：
1） 輪詢訪問模式：把數據請求輪詢轉發到後端Mcluster數據庫集羣的所有節點
2） 單節點訪問模式：把數據請求只轉發到數據庫集羣中的一個節點上，只有當前數據庫節點有問題的時候，纔會切換到另外一個數據庫節點上
3） 隧道模式：通過和數據庫節點建立持久隧道連接，所有數據連接都通過隧道來訪問數據庫（適用於短連接）
不同模式有各自的特點和業務使用場景。
在實際線上應用中，通過在本地業務服務器上安裝Gbalancer，根據需求配置Gbalancer連接數據庫的模式，並和業務代碼相結合，最終可以實現數據庫級別的高可用、負載、讀寫分離等功能。如下圖：
注：Gbalancer目前已經開源，項目地址爲 https://github.com/zhgwenming/gbalancer
3.9、日誌收集和分析
由於RDS數據庫集羣的數量激增，我們最頭痛的就是數據庫集羣批量報錯、單個業務線出現大量的低效的SQL語句等問題的及時發現和後期的分析工作，這些問題雖然短時間內也許不會造成致命問題。但如果不及時發現問題進行處理，後期很可能是致命性的。
目前通過ES，我們把所有日誌進行統一的存儲、管理和分析。其中對於數據庫來說，最主要的日誌還是錯誤日誌和慢查詢日誌。
我們把收集過來的MySQL（錯誤、慢查詢）日誌、容器日誌按各個關鍵指標和維度進行劃分，在Matrix雲平臺上以圖表的形式展現出來，可以宏觀的查看所有的日誌信息，這樣保證了：
1） 出現數據庫集羣報錯的時候我們能捕獲報錯並查看其規模、分類和具體信息
2） 如果批量出現大量慢SQL時，我們也能按照時間、數量、來源IP等一些列維度，來發現有問題的SQL語句，並對相關業務方提供優化建議
3） 數據庫容器報錯後，能捕獲並及時發現問題、解決問題，還可以供後期分析問題原因，防範再次出現
如下圖：
3.10、踩過的坑
1） 在線修改大表，會對整個集羣造成影響
2） 多節點寫，產生大量死鎖
3） 大批量DML，整個集羣pause
4） 導致數據庫集羣間不同步的場景
5） 集羣級別從庫壞了後的自動切換
6） 創建表爲MyISAM引擎後的數據恢復步驟
四、展望
樂視RDS發展到現在，已經逐漸趨於成熟，但還有很多功能需要完善，在今年我們會繼續發力樂視RDS。使其在功能和穩定性方面更上一層樓，並在不久的將來和大家見面。
VSDL（Virtual SQL Data Layer）構建
全球化分佈式數據庫
五、關於我們
Q&A
Q1：你們的RDS有用Zabbix進行集中監控管理嗎
A1：我們監控中有zabbix進行監控，zabbix通過調用我們自行開發的接口監控數據庫狀態，進行數據庫容器集羣事實監控。
Q2：請問運維標準化怎麼定義的，怎麼實施的
A2：運維標準化的範疇還是挺大的，比如服務器標準化，IDC標準化，網絡標準化，架構設計標準化，容器標準化等等。就不一一列舉了，我們通過規範與宣講，起到了一定的效果，但是隨着樂視集團與雲公司的發展，已經趕不上變化，只有平臺化，將各種標準系統化管控起來，才能將我們的標準與想法一一實現。這也是現在業界的一個普遍共識。
Q3：運維自動化用的什麼平臺
A3：運維自動化我們使用的是自主開發的Matrix管理平臺
Q4：怎麼快速擴容，快速部署
A4：依賴於Docker的先天特性，我們通過部署在物理機上的beehive程序，來快速部署容器。而容器裏的mcluster-manager來進行數據庫集羣的擴容。
Q5：發佈系統怎麼做的
A5：目前我們發佈系統是自行研發的系統，根據集羣容器級別進行升級，以python +saltstack方式實現快速容器集羣組件升級。
Q6：filebeat在使用過程中是否遇到發送重複數據，或者說超時重發導致日誌大量重複，是否遇到過？怎麼解決的
A6：我們使用filebeat中，並未發現發送重複數據，超時的話會有，我們通過date插件來把時間鎖定在實際的日誌記錄時間。
Q7：集羣日誌會不會出現時間差異
A7：如果不用date插件的話，會出現。我們現在用date插件來獲取日誌實際的記錄時間，並錄入ES集羣，可以避免日誌記錄時間和ES存儲時間的差異。
Q8：後端存儲用的是什麼 是開源的分佈式存儲嗎
A8:目前我們根據不同的業務線有不同的存儲方案，一般RDS這邊採用的存儲相對比較傳統，SAS、SSD，備份盤採用Gluster分佈式系統。
Q9：請問你們對不對log做解析，把字符串解析成對應的參數值。如果是用logstash做，是否遇到解析速率的瓶頸，如何優化的
A9：我們會對log進行解析的，只會截取取關鍵數據指標錄入ES集羣。logstash我們也有在使用，通過把數據放到MQ裏，然後用多個logstash解析MQ裏的日誌數據，加快解析速度。
Q10：關於Gbalancer中第三種方式隧道，這個主要解決的什麼問題？是基於什麼應用場景產生的？比另外兩種的優勢在哪
A10：主要解決短連接過多消耗數據庫資源，通過和數據庫節點建立持久隧道連接，所有數據連接都通過隧道來訪問數據庫，進而減小對數據庫服務器資源的消耗。另外兩種輪詢和單節點訪問，是不會建立持久連接（除非所用的編程程序支持）
Q11：能否將踩過坑中的解決方案例如多節點寫產生死鎖問題解決方案介紹下
A11：我們通過在業務端安裝gbalancer，用端口區分，分別使用gbalancer輪詢和單節點模式。然後在業務代碼裏把讀和寫用不同的gbalancer代理端口來訪問數據庫。
Q12：你們使用docker是如何進行編排的
A12：matrix+beehive，matrix是編排器，beehive是容器管理系統。請參考我們上次分享的一篇文章： http://mp.weixin.qq.com/s?__biz=MzA4Nzg5Nzc5OA==&mid=403162298&idx=1&sn=e1ccd26c4bd5619d30ad11d90a0cbc20&scene=1&srcid=0408CPAdONg0R3njhuaBvK7k#rd
Q13：在寫入數據之後進行集羣間同步的時候，是最終一致性還是實時一致性？設計時時如何考慮的
A13：Mcluster底層採用的是開源Percona Xtradb Cluster 進行封裝，PXC集羣數據爲強一致性，架構設計之初考慮到互聯網應用讀寫比例，讀較爲大的情景。PXC多節點數據一致性的同時，多節點讀也帶來讀性能的提高。
Q14：您好老師，請教一下，當數據庫鏈接突然斷掉，數據需要回滾的時候，這個時候集羣是如何做的
A14：PXC集羣特點，在每一次數據庫會話連接時候，保證多節點一致性，數據庫會話提交都需要在多節點進行驗證，驗證通過後纔會提交執行。這裏所提到的當數據庫會話連接突然斷掉的場景，應該屬於應用於數據庫連接沒有進行commit確認操作，會進行回滾。
Q15：請教下您這邊，剛纔講到了數據庫集羣的擴容，請問下擴容之後，新的庫是否要全量複製所有數據？還是增量保存
A15：擴容是會讀取共享磁盤上備份數據，在擴容節點進行恢復，然後選擇壓力最小的作爲donor，進行增量恢復。根據場景不同也有可能做SST全量複製，進行動態擴容。